Kurly Improves Frontend Productivity and Reduces Backend Dependency by Adopting GraphQL-based BFF

Kurly's Fintech Group adopted a GraphQL-based BFF (Backend for Frontend) to solve the frontend's API management burden and duplicate per-platform implementation issues caused by MSA adoption. It adopted NestJS, Apollo, and Fastify as its stack to integrate data from multiple microservices into a single schema, operating it as a frontend-dedicated server layer.

Tech Stack and Architecture

NestJS secures maintainability through its modular structure, and GraphQL reduces unnecessary API calls by fetching only the needed data in a single query. Fastify, with its lightweight and fast runtime characteristics, is suited for handling frequent GraphQL requests, while Apollo Server and Client handle schema definition and client-side caching, respectively.

Adoption Effects and Resolving Caching Issues

By leveraging graphql-codegen to auto-generate TypeScript types, they secured static type safety and increased frontend development speed. In addition, when backend specs change, the BFF maps the response, securing flexibility so it works without frontend modifications.

On the caching side, Apollo Client's default cache key policy (__typename:id) caused merge errors for data with composite unique identifiers (e.g., a combination of id, idType, kycSeq). To resolve this, they explicitly specified keyFields in typePolicies to prevent cache conflicts per entity.

Considerations for Adopting a BFF

While a BFF provides frontend productivity and isolation from backend changes, the additional layer increases points of failure and operational complexity. Therefore, it is suited for large-scale projects with complex service domains, numerous microservices, and frequent backend spec changes. For personal projects or single-page-focused services, omitting the BFF can be considered to reduce implementation complexity.