백엔드
Lunit CARE는 왜 GraphQL을 선택했는가?
두줄요약
Lunit CARE는 문서화, 타입 검증, 다중 API 호출 문제를 줄이기 위해 GraphQL과 Relay를 선택했습니다. gqlgen 자동 생성의 이점과 POST 캐시 제한·복잡한 리졸버 구현의 트레이드오프를 함께 설명합니다.
문제 상황
- RESTful API 문서와 구현 간 불일치로 인한 프론트엔드·백엔드 협업 비용
- 요청 데이터 정합성 검증의 수동 구현과 비즈니스 로직·DB 단계의 늦은 오류 검출
- 단일 페이지의 다수 API 호출에 따른 네트워크 부담과 응답 조합 복잡도
구조와 흐름
- GraphQL DSL 기반 스키마 정의와 gqlgen 코드 생성·Playground 문서화 연계
- query·subscription의 조회 대상 명사화와 mutation의 행위 중심 함수형 모델링
- 단일 POST 내 복수 query 처리 후 하나의 응답으로 집계하는 호출 구조
선택 이유
- 스키마 수정과 서버 생성 코드 갱신의 결합으로 문서 최신성 확보
- gqlgen과 Relay Compiler 기반의 서버 런타임·프론트엔드 컴파일 타임 타입 검증
- Relay 규격 지원을 통한 React 프론트엔드의 API 사용성 향상
트레이드오프
- 모든 요청의 POST 처리로 브라우저 GET 캐시 활용 제한
- 깊이 제한 없는 graph 요청과 데이터 처리 구현 복잡도 관리 필요
- 변경 빈도 대비 트래픽 비용이 높은 query의 REST API 전환 검토
