BFF가 필요한 이유

• 여러 플랫폼(Web, Android, iOS …)을 지원하게 되면서 각각 특정 데이터가 필요한 상황
• 원하는 데이터 형태에 도달하기 위해 여러 API 호출의 응답을 조작, 혼합, 일치시키는 상황
• 이런 상황들이 겹쳐 프론트엔드에서 복잡한 계산이나 비즈니스 로직을 작성하는 상황

코드 베이스가 커지고 복잡해짐에 따라 정리하기가 어려워지고 복잡한 계산을 수행하는 경우 UI 스레드에서 렌더링과 비즈니스 로직 수행이 경합을 벌이기 때문에 렌더링이 느려질 수 있다.

하나의 view(기능)를 완성하기 위해 여러 도메인의 API 응답값을 조작해야 하는 경우

데이터를 전송하는 과정에서 불필요한 데이터를 숨겨야 하는 경우

BFF 구조

: 여러 서비스에 분산되어 있는 데이터를 가져와서 적절히 합쳐야 하는 경우

• BFF에서는 프론트엔드 생선성을 더욱 높이기 위해, 데이터를 통합하는 처리를 담당

React에서 이야기하는 BFF는 생각해보면 BFF가 직면하는 문제들과 조금 다른 것 같다. 기본적으로 BFF는 MSA 패턴으로 흩어져있는 API를 하나로 모아서 조합하는 것에 집중하는것처럼 느껴졌고, React가 원하는 BFF는 React에서 사용할 사용할 RSC(리액트 서버 컴포넌트)를 서버에서 만들어서 클라이언트로 보내는 역할을 원하고 있다. MSA 패턴의 API 조합의 결과물로 React 컴포넌트를 만들려면 둘 다 한 서버를 이용해야 할 것이다.

Next.js를 온전히 사용하려면 Next.js에 BFF 로직인 API조합을 해야하지 않을까 라는 생각이 들었고, 같은 한 컴퓨터에 두 대 이상의 서버가 돌아가는 것보다 통합하는게 더 이상적이지 않은가 생각이 들었다.

그러나 관리하는 입장에서 BFF를 따로 두어서 관심사를 분리하면 유지보수하기 쉽다는 장점이 있고, BFF를 하나로 합치면 서버나 비용적인 측면에서 줄어들 수 있지 않나 생각이 들게 되었다.