[MSA] BFF 패턴: 프론트엔드를 위한 백엔드

⭐️ 틀리거나 모호한 부분은 알려주시면 감사하겠습니다.

BFF 배경과 개념

사용자 인터페이스(ios, android, desktop 등)가 다양해짐에 따라 기존의 방식대로 프론트엔드 요청 <-> 백엔드 응답 방식을 이용하게 된다면 병목현상이나 구현해야 할 api들이 훨씬 많아질 수 있다("code bloating"). 그래서 화면을 위한 백엔드를 프론트엔드 단과 백엔드 단 사이에 두어 데이터 수집 및 처리를 용이하게 해주는 BFF 패턴 방식이 등장하였다. 다음의 두 가지 예를 들어 bff 개념을 이해할 수 있다. (첫번째는 일반적인 예시고, 두번째는 개인적으로 bff를 공부하게 된 배경이 포함된 예시..)

예를 들어, 네이버에서 어떤 상품을 검색하는 경우, 최소 1) 상품에 관한 정보 와 2)리뷰가 화면에 보이게 될 것이다. 아마도(당연히) 상품 db와 리뷰 db는 다르게 관리하고 있을 것이기 때문에 1)상품 정보를 받아오는 API, 2)리뷰를 받아오는 API 각각 호출이 필요하다.

• 이 때 모바일 환경과 데스크톱에 따라 추가적으로 받아오는 정보가 다르다면?
• 또한 상품 api와 리뷰 api를 호출하는 팀은 따로 두어야 하는걸까

BFF, back-end for frontend를 두어 (상품 화면) <-> (모바일 bff),(데스크톱 bff) <-> (상품 public API), (리뷰 public API) 방식으로 서비스를 제공하면 효율적으로 관리할 수 있게 된다.

또 다른 예로는, 토이 프로젝트를 진행하면서 다른 팀원이 든 궁금점에 대한 방안으로 사용한 BFF 방식이다. 카페에서 음료를 주문하기 위해 여러 사람들의 주문을 취합하여 주문서를 만드는 어플이다. Firebase로 db를 구현했으며, events 는 각 주문서이고, 이벤트 문서 내 orders 컬렉션에 사용자 별 주문 정보가 담겨있다. 주문 음료는 beverageId를 통해 구분하도록 설계되어 있다.

• beverageId가 아닌 beverageName으로 주문에 포함되는 필드를 바꾸고 싶거나 beverageName이 필요하다면?

MySQL과 같은 rdbms를 사용하는 방식이라면 order의 beverageId를 통해 join을 해서 이름을 얻는 것이 가능하지만, firebase는 join이 불가능하기에 order에 대해 매칭하는 음료를 찾는 것이 어렵다. 그렇기에 이번 프로젝트에서는 orders, beverage 중 필요한 데이터의 전체를 받아와 조합하는 과정에서 필요한 데이터를 뽑아 쓰는 방식으로 진행하고 있다. 이런 식으로 데이터를 취합하는 전처리단계를 하나 더 두어서 화면에 정보를 전달하기 위한 백엔드를 두는 방식이 BFF이다. 그래서 internal API에서는 db에 직접 액세스 하여 관리하고, BFF는 이 데이터들을 처리한다. Beverage 데이터 양이 많지 않아서 이러한 방식이 가능한 것일 수도 있지만, 이렇게 된다면 아무래도 제공하는 정보를 유연하게 변경할 수 있지 않을까 싶다.

개인적으로 디자인 패턴이나 아키텍처를 공부할 때 활용 예시나 썼을 때의 장점들을 읽으면 잘 와닿는 것 같다.
참고한 기술 블로그의 댓글에 달린 어느 개발자의 BFF 경험:

• 비즈니스 로직이 바뀌더라도 새로운 버전을 자주 출시하지 않아도 됨. 업데이트를 받지 않은 고객과 업데이트 한 고객을 일관되게 관리 가능.
• 민감한 정보는 백엔드에 두고 화면에 실제 필요한 정보만 전달해서 보안을 높일 수 있음.
• 백엔드 팀은 기존의 legacy sw나 monolith를 다루더라도 mobile과 같은 bff 단의 팀들이 "killer app" 구현에 힘 쓸 수 있음.

...
It's been over a little more than a year since we took that route and the advantages stack up. The one I like best is that we rarely need to release a new APP version when we change a business rules. Because our BFF works as a BLL, a customer who hasn't updated for some time has business rules consistent with someone who just downloaded the app. I also love the security we get from keeping the sensible data on the server side, handing out to the APP almost only the info needed to be displayed on screen, or very simple booleans with the chewed up results of complex logic.

I find important to point out that not everyone is blessed with ultra modern architechture with microservices exposed via RESTFUL API. Our backend team has to deal with legacy software and monoliths while the mobile devs focus on what they thrive at, which is building a killer app.
...