안녕하세요 제가 뭔가 기본적인 부분을 모르고 있는 것 같아서 질문드려요. 현재 찾아보고 ...
# 질문
j
안녕하세요 제가 뭔가 기본적인 부분을 모르고 있는 것 같아서 질문드려요. 현재 찾아보고 있는 부분은 기존 REST API 구조에서 graphql 로 점차 바꿔가려고 조사 중 인데요. 그래서 제가 했던 일이 apollo-server 를 middleware 로 쓰고기존 API 하나의 반환 값을 그대로 schema.graphql 에 작성하고 호출하는 형식으로 만들어서 잘 실행이 됬습니다. 그런데 이전 모임에서 세미나를 듣고와서 보니 뭔가 제가 변경한 graphql 구조와는 뭔가 다르다는걸 느껴서요 해당 API 결과값은 사실 3개의 콜랙션(mongodb)과 2개의 캐시 데이터(redis)를 조합하여 만든 결과값인데요. 세미나에서 셜명하신 내용은 client 에서 query 할 경우 중간 가공작업을 거치지 않고 db에서 조회해오는 듯한 느낌이어서요. 해서 결론은 client 에서 해당 데이터를 각각 조회해오는게 올바른건지 아니면 결과값을 가공한 데이터를 불러오는게 올바른건지 궁금합니다..
h
당연히 요구사항에 따라 다르겠지만, 데이터 소스가 분산되는건 엄청 일반적인 유즈케이스니 별로 걱정하실 필요 없을 것 같습니다.
https://medium.com/brikl-engineering/graphql-schema-directives-as-orm-ec635fdc942d 맘편해지시라고 아주 극단적인 케이스 올려드려요 ㅋㅋ
👍 1
j
데이터 소스가 분산된다는게 client에서 하나의 쿼리 호출 시 resolver 에서 여러 데이터들을 분산해서 조회한다는 뜻인가요?
제가 이해력이 안좋아서..ㅜ
h
분산된 스키마를 클라이언트에서 하나로 합쳐서 요청할 수도, 합쳐주는 서버가 있을 수도, 애초에 스키마는 하나로 스토어만 나뉘어 있을 수도 있습니다. 그때그때 필요에 맞는 선택을 하되 최종 클라이언트에서 하나의 엔드포인트(데이터그래프) 를 보게끔만 하면 됩니다.
apollo federation 같은 주제는 microservice 식 접근이라 현재 구현이 monolith 하다면 별로 신경쓸 주제가 아니긴 합니다.
다만 리졸버 구현 디테일 수준에서 참조하는 서비스가 많을 수록 monolith 서비스의 장애 확률은 커지기에.. 적어도 폴백을 포함한 아키텍처를 구성하는 것을 권장드립니다.
👍 2
j
정말 감사합니다!