BFF : Backend for Frontend

마이크로 서비스 아키텍쳐(MSA)의 패턴 중 하나!

최근에는 다양한 모바일 기기가 많아지면서 다양한 클라이언트(웹 사이트, 모바일 어플리케이션, 스마트 기기 등)들이 존재하고 있다. 클라이언트들이 요구하는 API가 다 같다면 고민이 없었겠지만, 클라이언트마다 요구하는 API가 많아져서 개별로 관리하기도 힘들어졌다.

이를 해결하기 위한 방법이 BFF(Backend for Frontend) 패턴으로, API Gateway와 같은 진입점을 하나로 두지 않고 프론트엔드 유형에 따라 각각 두는 패턴이다. 프론트엔드를 위한 백엔드라는 의미로 BFF라고 부른다.

이걸 사용해야 하는 경우가 있어? 🙄

백엔드가 하나일 때,

유저의 전체 프로필 세부 정보를 반환하는 백엔드 서비스가 있고, 다른 양의 정보를 표시할 3개의 클라이언트가 있다고 가정해보자. 웹에서는 이름, 생년월일, 주소, 전화번호, 이메일 정보를 받길 원하고 모바일에서는 이름, 생년월일, 전화번호 정보와 스마트 기기에서는 이름만 받길 원하고 있다. 각 클라이언트들이 요구하는 API의 양과 내용이 조금씩 다르다.
그렇지만 모든 클라이언트가 하나의 백엔드 서비스에 의존하고 있기 때문에,
만약에 이 중 하나의 클라이언트를 다른 걸로 변경하기로 했다면 또 다른 클라이언트에 혼란을 줄 수도 있다.

이 문제를 해결할 수 있는 BFF 패턴!

각 클라이언트마다 요구사항을 충족할 수 있는 백엔드 서비스를 따로 두고, 공통되는 API 모듈만 전체 백엔드 서비스에서 가져다 쓰는 패턴이다. 클라이언트에서 여러 엔드포인트를 동시에 호출하는 대신 필요한 모든 리소스를 단일 엔드포인트로 요청할 수 있다.

BFF 패턴의 장점 🙂

1. 클라이언트당 하나의 백엔드 서비스를 만들게 되니까, 서비스의 동작과 기능에 맞는 요구사항을 잘 수용할 수 있다.
2. 다른 클라이언트 환경에 영향을 줄 염려가 없다.
3. 범용적인 백엔드 서비스보다 더 작고, 덜 복잡하고, 더 빠른 서비스를 제공할 수 있다.
4. 일정 및 작업 우선 순위, 기능 통합, 이슈 등에 있어 유연한 처리가 가능하다.

BFF 패턴의 단점 ☹️

1. 관리해야하는 백엔드 서비스 수가 증가한다.
2. 여러 클라이언트가 동일한 요청을 수행하는 경우, 단일 백엔드 서비스로 충분한지 BFF 구현이 정말 필요한지 충분한 고려가 필요하다.
3. 해당 패턴을 구현할 때 서비스 간의 코드가 중복될 가능성이 높다.
4. 패턴을 구현하는 데 걸리는 시간을 고려해야 한다.

✨ 정리

마이크로 서비스로 전환이 이루어지고 있는 요즘, BFF 패턴은 응용 가능성이 무궁무진한 것 같다!

참고 내용

BFF Pattern by Hussein Awad

블로그 포스팅 by Hayden

블로그 포스팅 by 삵