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

크로키의 스택 - GraphQL

크로키닷컴이 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 기능 하나로 검증하는 접근과 스키마 정의 방식의 시행착오를 보여준다.
카카오 스타일 (지그재그)
카카오 스타일 (지그재그) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (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