BFF (Backend For Front. aka Aggregator)

BFF는 왜 사용할까?

마이크로 서비스 아키텍처로 구현된 이커머스는 여러 도메인 앱으로 구성되어 있다. 도메인의 예로는 회원, 장바구니, 주문, 상품, 쿠폰 등이 있다. 그리고 각 MSA는 프론트엔드에서 사용할 수 있도록 API를 제공한다.

그런데 이 API는 화면에 노출되어야하는 데이터에 최적화되어있지 않은 경우가 많다. 불필요한 데이터를 내려주거나, 원하는 형식이 아닐 수 있다. 그래서 클라이언트(ex. 브라우저, 앱)에서는 원하는 형식으로 데이터를 재가공하는 절차가 필요하다. 이 경우, 데이터 가공 절차가 많아질수록 클라이언트의 리소스를 많이 사용하게 된다는 단점이 있다.

BFF는 프론트엔드 화면을 위한 데이터 가공 로직을 담당하는 서버를 의미한다. Backend for Front의 약자이다. 클라이언트는 BFF 서버를 호출하고, BFF 서버는 다시 각 MSA 서버를 호출한다.

BFF는 어떤 역할을 담당할까?

BFF는 세가지 처리를 한다.

MSA API를 호출하여 데이터를 가져온다.
클라이언트를 위한 형식으로 데이터를 재가공한다.
데이터를 클라이언트에 반환한다.

이렇게 하면 클라이언트에는 최소한의 논리 로직만 지니게 된다. 그래서 클라이언트는 화면을 구성하는 데에 집중할 수 있다.

앞서 살펴본 것처럼 BFF는 MSA와 클라이언트 사이에서 간단한 인터페이스 역할을 한다. 이상적인 경우, 프론트엔드 팀에서 BFF 서버를 직접 개발하기도 한다.

BFF를 사용하면 더 느려지지 않을까?

BFF를 사용하는 경우, 통신해야하는 서버 레이어가 추가되는 것이기 때문에 응답시간 지연이 우려될 수 있다. (Proxy Server, 외부 API 호출 추가 등등..) 그러나 프론트엔드를 그리기에 최적화되지 않은 여러 API를 클라이언트에서 가공해야 하는 경우, 클라이언트에서 많은 리소스를 사용하게 된다. 이러한 상황인 경우, BFF 추가로 인한 API 응답 시간 지연은 감수할만 하다. 그리고 리액티브 프로그래밍 방법을 사용하여, 여러개의 API를 동시에 호출한 후 조합하는 방법 등을 사용하면, API 응답 시간을 최적화할 수 있다. 혹은 클라이언트에서 다루기 편한 구조로 데이터를 변환하여, 클라이언트의 리소스를 줄여 속도를 높일 수도 있다. 네트워크 연결이 몇초 이상 소요되는 2G 혹은 3G 환경에서는 BFF 방법이 더 유용할 수 있다.

어떤 경우에 BFF를 사용할까?

단순한 모놀리틱 애플리케이션에서는 BFF가 필요하지 않다. 그러나 애플리케이션이 여러 MSA에 의존하는 경우, BFF를 사용하여 데이터의 흐름을 간소화할 수 있다. 그리고 인터페이스에 최적화된 백엔드 애플리케이션을 만들어야하거나, 프론트엔드를 위해 가공해야하는 데이터 크기가 큰 경우, BFF가 유용하다.

BFF가 여러개인 것도 가능할까?

당연히 가능하다. 전통적인 애플리케이션에서는 게이트웨이가 하나인 경우가 많다.

그런데 BFF는 클라이언트에서 손쉽게 사용할 수 있는 API를 제공하는 것이 목적이다. 예를 들어, 브라우저/모바일앱/써드파티 API에 제공해야하는 인터페이스는 각각 다를 수 있다. 이러한 상황이라면 각각의 디바이스 유형에 맞는 BFF를 제공할 수 있다.

BFF의 이점은?

프론트엔드와 백엔드의 관심사를 분리할 수 있다.
클라이언트에서는 API 구조를 모르기 때문에, API를 변경하기 수월하다. (앱 버전 호환 문제를 줄일 수 있다.)
오류 처리 방법을 개선할 수 있다. 오류는 대부분의 사용자에게는 의미가 없다. 때문에 오류가 발생하면 BFF에서는 사용자에게 보여줘야하는 오류 핸들링 방법을 알려줌으로써 오류 처리를 단순하게 만들 수 있다.
보안을 강화하기 편하다. 불필요한 값은 BFF 서버에서 숨김처리함으로써, 불필요한 데이터가 노출될 리스크를 줄일 수 있다.
클라이언트 팀에서 BFF를 소유함으로써, 개발 속도가 빨라질 수 있다.
- 원하는 형태의 데이터가 있다면, 직접 가공해서 쓰면 된다.