카카오페이지는 BFF(Backend For Frontend)를 어떻게 적용했을까?
아키텍처
카카오페이지는 BFF(Backend For Frontend)를 어떻게 적용했을까?
두줄요약
카카오페이지 Web은 GraphQL 기반 BFF로 다중 API 응답을 화면 모델에 맞게 통합했습니다. Apollo 캐시 문제를 피해 Urql과 Redux로 데이터 조회·상태 관리를 분리했습니다.
문제 상황
- 다중 플랫폼 공통 API의 불필요한 데이터와 화면별 복수 API 호출
- 프론트엔드의 응답 가공·비즈니스 로직 집중에 따른 코드 복잡도와 렌더링 경합
- MSA 엔드포인트 분리, CORS, 인증 방식, 플랫폼별 스펙 조율 부담
구조와 흐름
- Web 전용 BFF에서 백엔드 API 응답을 화면 모델로 통합·변환
- Next.js·Apollo Server 기반 GraphQL Resolver에서 프로필·캐시 데이터 병합
- Urql의 데이터 fetch와 Redux store의 비동기 UI 상태 관리 분리
선택 이유
- 필요한 필드만 제공하는 partial response와 프론트엔드·백엔드 관심사 분리
- BFF 단의 camelCase 변환, 날짜 포맷 변경, 커스텀 에러 래핑
- Apollo Client 대신 document 방식 캐싱 Urql 선택
트레이드오프
- 다중 플랫폼 지원이 없으면 플랫폼별 BFF의 효용 감소
- Apollo Client의 id 기반 정규화 캐시에서 필터별 하위 데이터 참조가 덮어써지는 문제
- keyFields·별도 식별자로 해결 가능하지만 Urql 전환 선택
