pile·
백엔드·카카오 스타일 (지그재그)카카오 스타일 (지그재그)·

GraphQL 이해하기: (4) 리졸버 인자 - 4. info

GraphQL.js 리졸버의 네 번째 인자인 info에 무엇이 들어 있고 어디에 쓰는지 정리한 연재 글이다. 보통은 리졸버 구현에 필요 없지만 쿼리 최적화나 복잡한 연결에는 info의 내용이 필요하다는 전제로 속성별로 짚는다. 카카오스타일이 만든 자체 유틸리티 라이브러리 사용례도 함께 나온다.

핵심 포인트
  • variableValues에는 실행 시 넘긴 변수만 담겨, 쿼리 안에 리터럴로 준 필드 인자는 들어오지 않아 쓸 곳이 생각보다 적다.
  • path로 현재 리졸버가 어떤 경로로 실행됐는지 추적할 수 있고 목록이면 인덱스도 키로 들어간다.
  • fieldNodes에는 지금 리졸버가 반환해야 할 필드 정보가 담겨 쿼리 최적화에 가장 많이 쓴다.
  • fieldNodes는 내부 구조체를 그대로 주기 때문에 다루기 어려워 자체 라이브러리로 감싸 쓴다.
  • getFieldList로 요청된 필드 목록을 받아 ORM의 select 인자로 넘기면 요청한 컬럼만 조회하는 쿼리가 된다.
  • API gateway에서 클라이언트 요청을 변형해 마이크로서비스로 넘기려고 info에 인자를 추가하는 유틸리티도 만들었다.
상세 정리
  • info의 위치: 리졸버의 마지막 인자로 현재 처리 중인 질의에 대한 정보가 들어 있다.
  • variableValues: 실행 시 준 변수 값이 담기는데 쿼리 안에서 직접 준 필드 인자는 포함되지 않는다. GraphQL Java에서는 DataFetchingEnvironment의 getVariables로 얻는다.
  • path의 구조: 이전 경로를 prev로 체인처럼 물고 있으며 key와 typename을 갖는다. 목록 필드라면 중간에 인덱스가 키로 끼어든다.
  • 함께 오는 정보: fieldName, parentType, returnType에 스키마상의 필드명과 부모 타입, 반환 타입이 담긴다.
  • Java 대응: 같은 값을 getExecutionStepInfo의 getPath와 getType, getField의 getName, getParentType으로 얻을 수 있다.
  • fieldNodes의 쓰임: 각 리졸버에 자신이 반환해야 할 하위 선택 집합이 들어온다. 최적화에 가장 많이 쓰지만 내부 구조체를 그대로 주기 때문에 직접 쓰기는 어렵다.
  • 자체 라이브러리: 그래서 crary-graphql이라는 유틸리티를 만들어 쓰고 있다.
  • getFieldList: 반환해야 할 필드 목록을 준다. 중첩 필드는 점으로 이어 1차원 배열로 돌려준다.
  • ORM 연계: 그 형태가 자사 ORM인 CORMO의 select 인자와 그대로 맞아떨어져, 일부 필드만 요청한 쿼리는 해당 컬럼만 가져오는 SQL로 변환된다.
  • getFieldList1st: 첫 번째 깊이의 필드만 돌려준다. 목록과 총 개수를 함께 반환하는 응답에서 목록을 요청했을 때만 DB를 조회하는 식의 최적화에 쓴다.
  • info 변형 유틸: 필드와 인자를 추가하거나 제거하는 함수들을 갖췄다.
  • 변형이 필요한 이유: API gateway가 GraphQL을 마이크로서비스로 분배하는데, 클라이언트 요청을 그대로 넘기지 않고 일부 바꿔야 하는 경우가 있다.
  • 구체 사례: 마이크로서비스는 id를 받는 user API를 제공하지만 gateway는 로그인한 사용자 정보를 주는 형태로 노출한다. gateway가 아는 로그인 사용자 id를 호출 시 인자에 끼워 넣어야 한다.
  • 구현 방식: 기존 리졸버 앞뒤에 동작을 덧붙이는 hookResolver 안에서 세션의 사용자 id를 꺼내 addArgumentToInfo로 info에 넣은 뒤 원래 resolve를 부른다.
왜 읽나GraphQL 리졸버가 클라이언트가 요청하지도 않은 컬럼까지 전부 조회하고 있다면, info에서 필드 목록을 뽑아 select에 넘기는 최적화 패턴이 바로 적용 가능하다.
카카오 스타일 (지그재그)
카카오 스타일 (지그재그) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 백엔드·twilio-engTwilio Engineering·

    Programmable Messaging에서 Verify API로 마이그레이션하기

    Twilio의 Programmable Messaging API로 자체 OTP 솔루션을 운영하던 서비스가 Verify API로 전환하는 방법을 코드 예시와 함께 설명한다. Verify는 OTP 전송·검증을 위한 전용 API로, 전화번호 구매, 토큰 생성, DB 저장·만료 관리를 내부에서 처리해 개발자가 직접 구현할 코드를 크게 줄인다.

    요약 이어보기
    #authentication#twilio#sms+2
  2. 백엔드·포스타입포스타입·

    포스타입이 개인화 추천을 하는 방법 2부

    포스타입 백엔드 엔지니어가 벡터 기반 개인화 추천 시스템을 실제 운영하며 맞닥뜨린 성능 장애와 용량 문제를 해결한 과정을 담은 2부다. 수백만 개의 벡터 KNN 검색이 피크 시간대에 전체 Elasticsearch 검색 성능을 흔드는 문제부터 클러스터 OOM 사태까지, 쿼리 최적화와 인프라 분리 두 가지 경로로 근본 해결에 이른다.

    요약 이어보기
    #elasticsearch#vector-search#recommendation-system+2
  3. 백엔드·포스타입포스타입·

    포스타입이 개인화 추천을 하는 방법 1부

    포스타입이 태그 기반 추천의 한계를 극복하고 벡터 임베딩 기반 개인화 추천 시스템을 구축한 과정을 담은 1부다. 유사한 콘텐츠가 다른 용어를 쓰거나 동일한 태그가 전혀 다른 톤의 콘텐츠를 가리키는 문제를 임베딩 벡터로 해결하고, OpenSearch의 HNSW ANN 검색으로 수백만 벡터를 실시간 검색하는 시스템을 구축해 구매율 15% 향상을 달성했다.

    요약 이어보기
    #opensearch#vector-search#recommendation-system+2