This message was deleted.

저는 적합하지 않다고 생각해요. 왜냐하면 대부분의 서버가 분리된 이유는 관심사의 분리와 추상화 때문인데요. GraphQL은 관계에 대한 정보를 드러내고, 해당 관계에 대한 이해가 다른 서버에서 사용된다면 그 두 서버는 서로 강하게 결합된 형태가 될거에요. 따라서 굳이 분리하지 않아도 될 서버였던거죠! ㅋㅋ GraphQL은 해당 스키마와 클라이언트를 강하게 결합하는데 최적화되어 있기 때문에, 다음과 같이 이해하는게 좋다고 생각해요.

클라이언트 <-강결합(GraphQL)-> BFF 서버 <-약결합(RPC)-> 마이크로서비스

사실 클라이언트와 BFF는 한 몸이지만... 인터넷이라는 비극으로 인해 찢어지게 된 거죠 ㅋㅋ (PHP 같은 친구들은 강결합 되어있죠 ㅋㅋ) 따라서 GraphQL은 클라이언트 상태와 리모트 데이터를 더 우아하게 강결합할 수 있는 방법에 가깝지 않나 하는 생각이에요.

아하 좋은 답변 정말 감사합니다! 먼저 이런 질문을 드리게 된 배경은 현재 팀의 상황이 MSA 환경에서도 중심에 가깝게 위치를 하고 있고, API가 굉장히 많은 상황인데, API 들 간에 중복도 많고, 오버페칭도 굉장히 많이 일어나고 있고 이러한 구조를 개선하고자, GraphQL을 도입해보면 어떨까하는 생각에 질문을 드려보았습니다! 말씀해주신 내용은 생각해보지 못한 내용이고 도움이 되었습니다. 그런데, 그런 점들을 제쳐두고 저희팀 같은 상황을 해소하고자 하는 용도로 사용하는 것에는 어떻게 생각하실까요??

MSA 환경에서도 중심에 가깝게 위치를 하고 있고,

요 이야기는 Aggregation을 담당하는 서비스를 만들고 계신다는 뜻일까요?

API가 굉장히 많은 상황인데, API 들 간에 중복도 많고, 오버페칭도 굉장히 많이 일어나고 있고

API가 파편화 된 상황에서 오버페칭은 피할수 없을거같아요 ㅎㅎ (조금 더 자세히 설명 주시면 의견 드릴 수 있을거같네요!) 만약 N+1 문제라면 batch get api를 통해서 최적화할 수 있을거같아요.

Aggregation이라기 보다는 저희팀 데이터(를 제공하는 API) 에 의존하는 타 시스템이 많다는 의미었습니다! 각 시스템에서 요구하는 API가 비슷하면서도 조금씩 다르기 때문에 각각의 요구사항을 다 들어주면서 API를 계속적으로 추가하다보니, 코드의 중복도 많고, 어떤 API가 여전히 쓰이고 있는지, 어떤 필드들이 쓰이고 있는지 이런것들이 시간이 지날수록 관리가 어려워지는 것 같아 GraphQL로 해소를 해보고자 생각을 해보았습니다!

아 그런거면 GraphQL 괜찮죠 ㅋㅋㅋ 필드별 Usage도 볼 수 있는 도구도 있구요

서버 입장에서는 스키마만 정의하면 되고, 타 시스템에서 필요한 필드들만 요구하게 되니 단점들이 많이 해소가 될거라고 생각했어요!

넵 그치만 오용되기 시작하면, 다른 단점들이 나올 수 있으니 주의하시는게 좋을거같아요 ㅎㅎ GraphQL이 꽤나 강력해서요. 이것저것 기능이 많을거고, 그 중에서 menmen님 문제를 해결하는 것만 취하시고 다른것들은 쓰지 않으시는걸 추천해요 ㅎㅎ

그런데, 회사분들과 의견을 주고 받는데 Server to server에는 적합하지 않다고 생각하시는 분들이 많더라구요! 명쾌한 이유는 없었고, GraphQL이라는 기술의 스펙이 그렇다~ 하는 이유로..

넵 GraphQL이 풀고자하는 문제에 대한 방향성은 안 맞긴합니다 ㅋㅋ GraphQL의 부수효과중에 원하시는것만 취하는 형태에 가까울거같아요.

아하, 그렇군요..! 저희 서버는 스프링여서 그런 부분은 문제가 덜 할 것 같긴하네요!

저희 회사 백엔드가 마이크로서비스 간 통신을 GraphQL로 하고 있는데, gRPC나 REST로 짤걸 그랬다고 많이 후회하고 있습니다 ㅠ

GraphQL이야기는 아니지만 저도 개인적인 의견하나 남겨요~

Aggregation이라기 보다는 저희팀 데이터(를 제공하는 API) 에 의존하는 타 시스템이 많다는 의미었습니다!

각 시스템에서 요구하는 API가 비슷하면서도 조금씩 다르기 때문에 각각의 요구사항을 다 들어주면서 API를 계속적으로 추가하다보니,

코드의 중복도 많고, 어떤 API가 여전히 쓰이고 있는지, 어떤 필드들이 쓰이고 있는지 이런것들이 시간이 지날수록 관리가 어려워지는 것 같아 GraphQL로 해소를 해보고자 생각을 해보았습니다!

이 부분에 대해서 두가지 측면으로 살펴봐야할거 같아요. • 사내에 플랫폼으로서 만드는 서비스 ◦ 제가 다니는 회사가 이런 접근을 많이 하는데요, 만약 채팅팀이 있다면 여기서는 하나의 서비스를 위해 fit하게 디자인 하지 않고 많은 서비스들을 위해 설계하고 있어요. 마치 제가 디스코드 API를 이용할때 디스코드 측에서 저한테 fit하게 api를 뚫어주지 않은것 처럼요. 다만 각 서비스들이 요구하는것을 사내서비스들이다보니 좀더 잘 들어주지만 결국

유저의 목소리에 대한 플랫폼으로서의 대응

을 하는거 같아요. 디스코드가 각각의 고객마다 API를 새로 파지 않고 각 고객이 만족할수 있게 기존 API에 기능이나 필드를 추가할거 같아요. • 다른 사내 제품들을 서포트하기 위한 서비스 ◦ 이러면 각 사내 서비스들에 하나 하나 fit하게 맞게 api를 만들어야해서 어떤식으로든 코드 중복은 피할수 없지 않을까 싶어요. 이게 서로 다른팀이 다른것을 요구하면 서로 다른 이유로 변경되기 때문에 중복으로서 추상화해야하는게 아니라 우발적 중복(우연히 비슷해보이는 중복)으로 봐야할거 같아요

@XiNiHa 좋은 답변 정말 감사합니다! 그렇다면 혹시, gRPC나 REST로 하시는걸 후회하는 것과 GraphQL 사용이 번잡해지는 이유를 간단하게 라도 말씀해주실 게 있으실까요~?

GraphQL 쪽은 요청 하나를 구성할 때마다 쿼리를 짜고, 이걸로 코드젠을 돌리고, 갖다쓰고 하는 플로우 자체가 gRPC에 비해 좀 번잡하다고 느껴진 것 같아요. __typename 가지고 에러 처리하고 하는 것도 프론트에 적합한 방식이지 RPC용으로는 영 번잡하다는 생각만 많이 들었어서요

쓰세요. 설명해주신 것들 보면 굉장히 적합한 유즈케이스 같은데요

음 그럼 그냥 제가 잘 못 써서 불편했던 걸로 (?)

그건 대안으로 제시하신 애들도 같은 문제를 겪어요. 그냥 어떻게 쓰냐 차이

아마 코드젠 프로세스가 언어 툴체인에 연동되어 있냐 차이가 제일 크게 느껴졌던 것 같네요

그건 GraphQL 논의에서 많이 벗어나는 얘기인듯

기술 자체랑은 연관성이 적었던 걸로....

@Hyeseong Kim 님 좋은 답변 감사합니다! 사례가 잘 없긴하던데, 직접 해봐야겠군요,,

조직간에 GraphQL 통신이 익숙치 않은경우 아예 노출을 안하는게 나을수도 있어요

네 그게 가장 큰 문제점인 것 같기는 합니다..!

아니면 플레이그라운드만 노출해주고 URL 매핑을 요청받아도 되고요

이 URL을 찌르면 이 GraphQL 오퍼레이션이 실행됩니다 식으로요

저도 Persisted Query 생각났어요 ㅎㅎ

그럼 클라 시스템은 GraphQL을 몰라도 되고 필요할 때 요청해서 엔드포인트를 생성하면 됩니다.

아? 제가 이해를 정확히 한게 맞나 싶은데요,, endpoint는 REST로 열어놓고, 내부적으로 한단계를 더 거쳐서 GraphQL 을 사용한다는 말씀이실까요~?

으음

아~ 네네 맞습니다!

엔드포인트 찍어내는데 GraphQL을 쓰시라는 얘깁니다. 손으로 해도 되고 자동으로 해도 되고

짱 좋은 접근이네요

자동으로 해주는 솔루션이 Sofa나 Hasura같은게 있는데 이상황에 딱 맞진 않는거같고 개발방식을 바꾸는것도 큰 변경이니까

아~~ 이제 이해가 좀 가는 것 같습니다! 이런식으로 접근할 수도 있군요,, 신기하네요! 감사합니다~~!

GraphQL을 사용해서 개발한다가 반드시 GraphQL 엔드포인트로만 서비스를 제공한다는 얘기가 되야하는건 아닙니다