BFF가 뭐예요?

업무 관계상 여러 백엔드부터 한 고객과 소통할 가능성이 있어 BFF를 사용할 수 있는지 조사했다.
대상

BFF(backend for fronted)의 개요를 알고 싶은 사람

장점과 단점을 정리하고 싶은 사람

개요
BFF(backend for fronted)는 간단하게 말하면 클라이언트와 백엔드 사이에 위치하고 쌍방의 복잡성을 흡수하는 서버이다.지저분하게 쓰면 이런 느낌.

이것은 필요한 것이다. 배경은 고객 단말기의 종류가 증가함에 따라 증가하는 논리이다.
예를 들어 웹, 스마트폰 버전인 웹, 스마트폰 애플리케이션, 데스크톱 앱 등 여러 클라이언트가 등장해 각각 정보와 내용을 제출하려면 클라이언트 측 코드가 복잡해져 여분의 코드만 쓸 수 있다.
이러한 배경에서 여러 개의 백엔드에서 정보를 얻고 적당한 성형을 하는 등 논리를 가진 서버를 도입하자 클라이언트가 UI/UX를 중시하기 시작했는데 이것이 바로 BFF가 등장한 과정이다.
BFF의 장점
API 집계
간단하게 말하면 고객은 BFF에 API를 던지기만 하면 되고 고객측은 여러 개의 백엔드에 대한 대응과 가공 등에 신경 쓰지 않아도 된다.또한 백엔드에서 온 여러 응답을 고객이 요구하는 형식으로 적절하게 가공한 후에 되돌릴 수 있기 때문에 고객의 처리를 줄일 수 있다.
백엔드 차이 흡수
예를 들어 백엔드의 일부는 gRPC, 다른 부분은 REST, 다른 부분은 웹소켓 등 백엔드의 규격과 차이 등을 흡수해 다양한 백엔드에 대응할 수 있다.
프런트엔드와 백엔드의 분리
백엔드가 고객과 직접 통신할 경우 이 프로토콜이 일치하지 않을 수 없지만 BFF 사이에 끼면 BFF<-> 고객과 BFF<-> 백엔드가 완전히 다르기 때문에 BFF<-> 고객만 GraphiQL 아래에서 BFF<-> 백엔드와 REST를 유연하게 조정할 수 있다.
여러 취미를 뛰어넘는 이별
어설픈 표현이지만 BFF에 인증, 권한, 캐시 등의 처리를 설정하면 클라이언트와 백엔드의 교차 처리를 제거하고 간단한 형식을 유지할 수 있다.
BFF의 단점
서버 개발 및 유지 관리
BFF도 소스 코드가 있기 때문에 실제 움직이는 서버는 그런 감시와 depro 등에 대한 노력이 당연히 늘어난다.
디버깅 시기
BFF는 백엔드와 긴밀한 대화를 하기 때문에 예를 들어 백엔드 API의 규격이 변경되면 BFF도 변경되고 디버깅을 동시에 하지 않으면 고장이 발생할 수 있기 때문이다.그런 절차에 대한 고려가 늘다.
통신량의 증가와 지연
커뮤니케이션 증가, 커뮤니케이션 증가로 데이터 액세스에 필요한 경로가 증가하므로 데이터 액세스에 필요한 시간은 당연히 늘어납니다.따라서 그에 상응하는 강화와 대응이 필요하다.
코드 이중화
만약 BFF의 API와 백엔드의 API 기능이 기본적으로 일치한다. 예를 들어 사용자 목록의 API 획득 등 기능과 취미가 일치한다면, 거의 같은 코드를 써야 하기 때문에 코드가 중복될 것이다.
설치 방법
백엔드가 REST라고 가정하면 BFF가 루팅과 HTTP Request 기능만 있으면 BFF를 실현할 수 있다.고객과 백엔드의 소통 조건에 따라 다르지만 실장만 하면 난이도가 높지 않다.
여러 프로토콜 대응과 클라이언트 사이에 그래픽 QL을 만들려면 Envoy와 Apollo 등 서버를 적절히 고려해야 한다.