This message was deleted.

저는 대부분의 경우 적절하지 않으며, 두 스키마를 분리하는 것이 대부분의 상황에서 좋은 결과를 낸다고 생각합니다.

진리의 케바케 아닐까요 ㅋㅋ 1-tier 아키텍처도 뭐 상황에 따라서는 아주 말도 안되는 얘기는 아닐 수 있고 DB 지원 범위에 따라 다르다고 생각해요. DB 자체가 애플리케이션 엔진일 수 있죠

근데 이 경우는 인터페이스가 해당 소프트웨어 외부로 노출되는 상황이다 보니 좀 더 레이어를 촘촘히 나누고 보수적으로 접근할 필요가 있죠

이 경우는 뭔가용

아 아뇽 스키마를 나눌 것인지 말 것인지요

대신 DB schema가 변경되는 일은 적으니, 1:1 매핑했을 때의 이점을 더 중시한다고 하더라구요

변경이 발생했을 때 드는 비용이랑 여기서 오는 이점을 비교해봐야겠네요. 그래도 레이어는 나누는게…ㅎㅎㅎ

케바케…. 무적의 단어.. 저는 그럼에도 나누는게….예를 들어, 저희도 1:1 매핑 된 레거시 코드가 있는데, graphql D.name값을 얻기 위해서 질의할 때 굳이 A -> B -> C -> D 타고 가야 하는 단점이 있더라구요. 클라이언트 입장에서는 ” 난 그냥 name이 필요한데 왜 DB 구조를 파악해가며 질의해야 하지?” 물론 A->B->B->D 이 구조가, GraphQL을 설계해서 나온 거라면 당연한 거지만, 그게 아니라 그냥 DB를 매핑해서 한게 문제더라구요.

저는 스키마 나누는 방식으로 하되, 완전 분리되는 건 아니고 타입 자체는 대략 1대1 매핑되는 편이에요

그냥 제가 말씀드리고 싶은 부분은

넹 뭐 프론트에서 Dgraph 같은 거 바로 붙여서 쓰는 상황이고 그러면 사실 나누고 말고를 논의할 필요도 없긴 하죠

GraphQL 스키마는 유즈케이스에 해당한다고 보는데요

애초에 디비가 얼마나 expressive 한 지가 중요하겠네요.

뒷북 쳐서 죄송합니다. 1:1 매핑하다보면 엔티티 간에 과도하게 조인되는 경우가 많지 않나요? 어쩔 수 없이 dto 객체를 만들면서 뭐가 맞는건지 궁금했었는데 좋은 의견을 나누고 있는 쓰레드라 참여해봅니다!

"과도하다" 기준이 다를 수 있겠지만 일반적으로 그 부분은 GraphQL이 해결하는 것 같아요. 서버에서 허용하는 + 클라이언트에서 요청한 만큼만 조인하겠죠.

@Hyeseong Kim 그렇군요. 지금까지 resolver로 서비스 매핑정도로만 사용하고 있었어서 쿼리를 위해선 풀 조인을 했었는데, 관련 방식에 대해서 좀 더 찾아봐야겠습니다