크로키닷컴이 Thrift 를 1년 쓴 뒤 GraphQL 로 API 를 옮긴 현황을 정리한 글이다. 전면 전환이 아니라 N+1 문제를 가진 기능 하나를 골라 검증한 뒤 넓혀 간 방식과, 스키마 정의 방법이 세 단계로 바뀐 과정을 담았다.
핵심 포인트- Thrift 를 1년 정도 쓰면서 여러 불편을 느껴 대안을 찾다 GraphQL 을 골랐다. 생태계가 Node.js 중심으로 발전하고 있어 크게 망설이지 않았다.
- 전환은 조심스럽게 했다. 외부에 영향을 주지 않으면서 N+1 문제를 가진 기능 하나를 먼저 바꿔 봤다.
- 검증 기준이 명확하다. 기존 API 대비 성능이 떨어지지 않으면서 사용은 더 편해지는지를 확인하고 나서 확대했다.
- 스키마 정의는 `GraphQLObjectType` → 스키마 문자열 → 데코레이터 기반 순으로 바뀌었다. resolver 구현에도 타입 체킹이 되고 DB 모델과 통일하기 위해서다.
- 다만 그 방식에 퍼포먼스 이슈가 있어 수정한 버전을 쓰고 있다고 밝힌다.
상세 정리- 글의 성격을 먼저 못 박는다. 아직 많은 부분을 연구 중이라 현재 상황만 간단히 정리한다는 전제다.
- 1년 이상 진행하며 정리된 API 스펙은 스타일 가이드 저장소에 공개하고 있다.
- 스키마 정의 방식이 바뀐 이유가 구체적이다. 처음 방식은 타입이 많아지면 한눈에 보기 힘들었다.
- 클라이언트 호출 코드에 대한 설명으로 이어지며, 서버 정의와 클라이언트 사용이 어떻게 맞물리는지를 다룬다.
- 같은 팀의 «크로키의 스택» 시리즈 중 한 편으로, 마이크로서비스·Thrift 편과 이어 읽으면 API 계층의 변천이 드러난다.
왜 읽나RPC 프레임워크에서 GraphQL 로 넘어갈지 고민하는 팀에게, 전면 전환 대신 N+1 기능 하나로 검증하는 접근과 스키마 정의 방식의 시행착오를 보여준다.