Backend for Frontend (BFF) Architecture 번역

Backend for Frontend (BFF) Architecture 를 읽고 정리한 내용입니다.

결론부터 말하자면 BFF는 사용자 경험을 개선할 수 있습니다. 서로 다른 클라이언트마다 사용자 인터페이스에 데이터를 정확하게 제공하도록 도와주고, 다소 복잡성이 늘더라도 성능의 개선과 유연성은 그만큼의 가치가 있습니다. 만약 서비스를 웹 앱, 모바일 앱, IoT 디바이스로 서비스를 확장한다면 BFF 를 고려해볼 수 있다고 합니다.

 

BFF (https://levelup.gitconnected.com/backend-for-frontend-bff-architecture-64fa9f316a5a

 

BFF(Backend for Frontend) 아키텍처 등장 배경

- 애플리케이션이 점점 더 분산됨

- 각 클라이언트 요구에 맞춘 백엔드 서비스를 제공이 필요해짐(유지 보수의 편의성과 안전한 사용자 경험 제공을 위해)

 

BFF(Backend for Frontend) 아키텍처란?

각 프론트엔드 인터페이스에 전용 백엔드 레이어를 제공하는 아키택처 패턴

각 프론트엔드(ex. 모바일 앱, 웹 앱, 디바이스 ..) 서로 다른 성능, 데이터, 인터랙션 요구사항을 가질 수 있음

=> 특정 프론트엔드의 요구에 맞춘 백엔드를 제공

• 다양한 서비스 호출을 통합하거나 조정
• 클라이언트 친화적으로 데이터를 준비
• 프론트엔드와 관련된 특정 로직 처리

=> 관심사를 분리하고 각 클라이언트에 적합하게 백엔드를 최적화

 

BFF의 작동 방식

 

• 클라이언트 요청: 클라이언트(모바일, 웹 등)는 해당하는 BFF에 요청을 보냄.
• BFF 레이어: BFF는 여러 마이크로서비스로부터 데이터를 통합하고, 필요한 변환이나 최적화를 수행한 뒤, 맞춤형 응답을 제공
• 마이크로서비스: BFF는 하위 서비스(예: 사용자 서비스, 주문 서비스 등)와 상호작용합니다.

전통적인 아키텍처 vs BFF

Traditional vs BFF (https://levelup.gitconnected.com/backend-for-frontend-bff-architecture-64fa9f316a5a)

전통적인 아키텍처

• 단일 API 게이트웨이가  웹, 모바일, IoT 등 여러 클라이언트로부터 요청을 처리
• 클라이언트별 요구를 처리하는 유연성은 부족. 예) 서로 다른 클라이언트 앱에 맞춘 데이터 모델, 특정 프론트엔드를 위한 복잡한 서비스 관리 등..
• 백엔드를 분리하여 각 클라이언트가 필요한 데이터를 정확하게 제공받도록 보장

BFF가 현대 아키텍쳐에서 인기를 끄는 이유

 

• 맞춤형 사용자 경험: 모바일 앱이든 데스크탑이든 웨어러블 디바이스이든, 각 프론트엔드는 필요 없는 데이터를 제외하고 정확히 필요한 데이터만 받음
• 복잡성 감소: BFF는 각 백엔드를 맞춤화하여 플랫폼 간 매끄러운 경험을 보장하며 시스템을 단순화
• 성능 향상: 불필요한 API 호출을 줄여 응답 속도 및 사용자 만족도를 향상
• 빠른 개발: 팀이 각 프론트엔드에 맞는 BFF를 따로 작업할 수 있어 서로 간섭하지 않고 더 빠르게 개발 가능
• 강화된 보안: BFF는 백엔드와의 모든 상호작용을 제어하기 때문에 엄격한 보안 조치를 실행할 수 있음. 예) 토큰 검증, 입력 검증, 속도 제한

 

BFF를 언제 사용해야 할까

 

• 다중 플랫폼 애플리케이션: 웹, 모바일, 스마트 디바이스 등 다양한 플랫폼을 위한 애플리케이션을 구축하는 경우, BFF는 각 플랫폼에 맞춤형 경험을 제공할 수 있음.
• 마이크로서비스 오케스트레이션: 마이크로서비스 아키텍처에서 클라이언트가 여러 서비스(예: 사용자 서비스, 주문 서비스, 재고 서비스)로부터 데이터를 가져와야 할 때, BFF는 필요한 데이터를 통합하여 클라이언트에 일관된 응답 제공 가능
• 레거시 API 최적화: 마이크로서비스로 마이그레이션하거나 레거시 시스템을 사용하는 경우, BFF는 복잡한 기존 아키텍처를 감추고 프론트엔드에 현대적인 인터페이스를 제공할 수 있음.

도전과 고려 사항

 

• 유지 관리 오버헤드 증가: 각 프론트엔드마다 별도의 백엔드를 유지해야 하므로 복잡성 증가할 수 있음. 추가 모니터링, 확장성 관리, 보안 조치가 필요
• 일관성 문제: 신중하게 설계하지 않으면 클라이언트마다 반환되는 데이터의 일관성이 떨어질 수 있음.
• 성능 병목: BFF 레이어가 최적화되지 않으면 많은 요청을 처리하거나 복잡한 연산을 수행할 때 성능 병목이 발생할 수 있음.

구현 Best Practice

BFF 아키텍처 구현시 다음 내용을 고려하자

 

• BFF 내 비즈니스 로직 제한: BFF는 주로 프론트엔드를 위한 데이터 오케스트레이션 및 포맷팅에 집중해야 하며, 복잡한 비즈니스 로직을 구현해서는 안 됨.
• 캐싱 사용: 특히 모바일 클라이언트를 위해 성능을 향상시키려면 BFF 레이어에서 자주 사용하는 응답을 캐싱
• 에러 처리: 에러 처리와 로깅을 중앙 집중화하여 클라이언트가 직면하는 문제를 방지
• 보안: 인증, 권한 부여, 속도 제한 등을 통해 BFF 레벨에서 보안을 강화하여 백엔드 서비스를 보호하기

실제 BFF 성공 사례

 

• 넷플릭스: BFF 아키텍처는 넷플릭스의 원활한 크로스 디바이스 경험을 제공. 모바일 앱은 가벼운 데이터를 가져오고, 데스크탑 앱은 더 풍부한 기능을 위해 더 많은 정보를 가져온다.
• 스포티파이: 휴대폰이든 태블릿이든 스마트 스피커든, 스포티파이의 BFF는 각 디바이스에 최적화된 데이터를 제공하여 빠르고 매끄러운 음악 경험을 보장

결론: BFF는 완벽한 사용자 경험을 제공!

개발자들이 각 사용자 인터페이스에 필요한 데이터를 정확히 제공하도록 도와줌

복잡성을 더할 수 있지만 성능 개선과 유연성은 그만큼의 가치가 있음.

웹 앱, 모바일 앱, IoT 디바이스로 서비스를 확장한다면 BFF 를 고려해볼 수 있다.