This message was deleted.

relay 와 apollo client 를 보고 있고요. 관련 문서들은 이것저것 읽어 보았는데 실무적인 입장에서의 pros/cons 를 적어주시면 감사하겠습니다.

서버같은 경우에는 기존 엔드포인트 그대로 유지하면서, 신규

/graphql

엔드포인트를 통해 만들고자 하시는 GraphQL 서비스를 노출하면 될거같구요. GraphQL 서비스 내 리졸버에서 각 마이크로서비스에 grpc 콜하는 형태로 만들면 되고, 실제로 그렇게 많이들 사용하곤해요! (DataLoader를 통해 Batching을 하는게 필수적이라 마이크로서비스에서 Batching하는 기능을 무조건 제공해야합니다) 결국 클라이언트가 문제일거같은데요. 일단 기본적으로 마이그레이션 하는것을 1단계로 하신다면, API 호출하는 부분을

POST /graphql

+

{ query: ..., variables: ...}

로만 단순하게 바꾸시면 될꺼같고, 여기서 조금 더 GraphQL 스럽게 하시려면, Apollo Client, 더 나아가면 Relay를 떠올리시면 될꺼같아요. 클라이언트에서 GraphQL을 도입한다고 하는것은 단순하게 네트워크 요청을 줄인다, 필요한 필드만 가져올수있다. 이런 장단점을 나열해서 설명하는건 좀 부적절한거 같구요. 새로운 멘탈모델, Opinionated Web Framework을 도입한다고 받아들이시는게 더 좋다고 생각해요. GraphQL이 이야기하는 장점에 팀분들이 얼마나 공감하고 계시고, 넘어가고 싶으신지에 따라서, (1) 일반 HTTP Client, (2) Apollo Client (3) Relay를 선택하시면 좋을것 같습니다. 아래 문서 읽어보시면 도움이 되지 않을까… 싶어요. https://relay.dev/docs/en/thinking-in-graphql https://relay.dev/docs/en/thinking-in-relay 여기서 질문하셨던 실무적인 Pros/Cons를 구체적으로 말씀드려보면…

좋은 답변 감사합니다~!

@Seung-gi Lim 조금 더 첨언을 드리면 결국에 클라이언트분들 의견이 제일 중요한데요. 그래서 클라이언트 개발자분들께서 동의하신다면, 1. 클라이언트 스키마를 도입해서, 클라이언트 내에서 REST를 GraphQL로 래핑해서 사용 2. 어느정도 성숙했다면, 해당 Graph를 서버로 옮김 으로 마이그레이션하면 깔끔하게 가능합니다 ㅎㅎ 클라이언트 스키마 관련해서 제 발표 첨부드려요.

좋아보이네요. 결국 마이그레이션과 러닝커브가 장벽이니까요. 저 세션은 예전에 라이브로 봤었습니다. 감사합니다~