[번역] The BFF Pattern: An Introduction

The BFF Pattern (Backend for Frontend): An Introduction

 

 

마이크로 서비스를 사용하여 전자상거래 애플리케이션을 구축해야 하는 시나리오를 상상해보세요. 고객, 주문, 제품, 장바구니등을 위한 마이크로 서비스가 있을 수 있습니다. 마이크로 서비스는 프론트엔드에서 사용할 API를 노출합니다. 그러나 마이크로 서비스가 프론트엔드로 반환하는 데이터는 프론트엔드에서 표현해야 하는 정확한 방식에 따라 형식이 지정되거나 필터링되지 않았을 수 있습니다. 

 

이 경우 프론트엔드에 자체적으로 이러한 데이터의 형식을 다시 지정하는 로직이 있어야 합니다. 프론트엔드에 이러한 로직이 있으면 브라우저 리소스를 더 많이 사용하게 됩니다.

 

이런 상황에서는 이 프론트엔드 로직의 일부를 중간 계층으로 이동하기 위해 BFF를 사용할 수 있습니다. 중간 계층이 바로 BFF입니다. 프론트엔드에서 일부 데이터를 요청하면 BFF에서 API를 호출합니다.

 

BFF는 다음을 수행합니다.

 

- 관련 마이크로 서비스 API를 호출하여 필요한 데이터를 가져옵니다.

- 프론트엔드 표현에 따라 데이터를 포맷합니다.

- 포맷된 데이터를 프론트엔드로 전송합니다. 

 

결과적으로 프론트엔드에 최소한의 로직만 남게 됩니다. 따라서 BFF는 데이터 표현을 간소화하는데 도움이 되며, 프론트엔드에 집중된 인터페이스를 제공하는 역할을 담당합니다. 

 

백엔드-프론트엔드 관계를 단순화하는 또 다른 좋은 방법은 백엔드 프론트엔드 간에 유형을 공유하는 것입니다.

 

eCommerce 예시에는 어떻게 적용되나요?

다음 다이어그램은 각 마이크로서비스가 BFF를 통해 프론트엔드와 연결되는 방식을 보여줍니다.

The role of a BFF

이미 살펴본 것처럼 BFF는 프론트엔드와 마이크로서비스 사이의 간단한 인터페이스 역할을 합니다. 이상적으로는 프론트엔드 팀이 BFF를 관리할 책임이 있습니다.

 

단일 BFF는 단일 UI에만 집중하고 그 UI는 하나뿐입니다. 결과적으로 프론트엔드를 단순하게 유지하고 백엔드를 통해 데이터에 대한 통합된 뷰를 볼 수 있습니다.

 

다음 질문이 생깁니다. 여러 UI에 대해 여러개의 BFF를 사용할 수 있을까요? 이 글의 후반부에 대해서 이 질문에 대한 답을 찾아보겠습니다. 

Will this increase latency?

BFF는 클라이언트와 다른 외부 API, 서비스 등 사이의 프록시 서버와 유사하다는 것을 알고 있습니다. 요청이 다른 컴포넌트를 거쳐야 하는 경우 지연시간이 확실히 증가합니다. 그러나 프론트엔드에서 최적화되지 않은 여러 서비스와 함께 작동해야 하는 경우 브라우저의 높은 리소스 사용량에 비하면 BFF 지연 시간은 무시할 수 있는 수준입니다. 

 

BFF를 구축하면 다른 백엔드/마이크로서비스에 일괄호출하여 데이터를 한 번에 반환하거나, 데이터를 변환하고 서식을 지정하여 보다 편리한 표현으로 반환할 수 있습니다.

 

이 기능은 연결을 설정하는데 몇 초(또는 그 이상)가 걸릴 수 있는 2G 또는 3G 네트워크의 모바일 클라이언트에게 매우 유용할 수 있습니다. 

When to use a BFF for your applications

다른 많은 패턴과 마찬가지로 애플리케이션에서 BFF를 사용하는 것은 컨텍스트와 따르려는 아키텍처에 따라 달라집니다. 예를 들어 애플리케이션이 단순한 모놀리식 앱인 경우 BFF는 불필요합니다.

 

그러나 애플리케이션이 마이크로서비스에 의존하고 외부 API 및 기타 서비스를 많이 사용하는 경우, 데이터 흐름을 간소화하고 애플리케이션에 많은 효율성을 도입하기 위해 BFF를 사용하는 것이 좋습니다.

 

또한 애플리케이션이 특정 프론트엔드 인터페이스에 최적화된 백엔드를 개발해야 하거나 클라이언트가 백엔드에서 상당한 양의 집계가 필요한 데이터를 사용해야 하는 경우 BFF가 적합한 옵션입니다. 

Can we have multiple BFFs?

물론 가능합니다! 이것이 바로 BFF라는 친구를 사귀는 이유입니다.

기존 접근 방식(BFF가 없는 애플리케이션)에는 모든 클라이언트에 대해 하나의 API 게이트웨이만 있습니다. 다음과 같이 보일 것입니다.

 

 

 

 

하지만 BFF를 사용하는 목적은 클라이언트가 연결할 수 있는 집중적인 인텊이스를 제공하는 것입니다. 예를 들어 모바일 UI의 데이터 소비는 브라우저의 데이터 소비와 다를 수 있습니다. 이 경우 더 나은 데이터 표현을 위해 두 개의 BFF를 사용할 수 있습니다. 여러 개의 BFF가 있는 애플리케이션 다이어그램을 살펴보겠습니다. 

 

 

보시다시피 각 클라이언트에는 BFF가 있씁니다. 서비스별 응답을 최적화하는데 도움이 됩니다.

Advantages of having a BFF

BFF를 통해 얻을 수 있는 몇가지 이점은 다음과 같습니다.

 

- Seperation of concerns: 프론트엔드 요구사항이 백엔드 우려사항과 분리됩니다. 이렇게 하면 유지 관리가 더 쉬워집니다.

- API 유지 관리 및 수정이 더 쉬움: 클라이언트 애플리케이션이 API의 구조에 대해 더 적게 알게되므로 해당 API의 변경에 더 탄력적으로 대응할 수 있습니다.

- 프론트엔드에서의 오류 처리 개선: 서버 오류는 대부분의 경우 프론트엔드 사용자에게는 의미가 없습니다. 서버가 전송하는 오류를 직접 반환하는 대신 BFF는 사용자에게 표시해야하는 오류를 매핑할 수 있습니다. 이렇게하면 사용자 경험이 개선됩니다. 

- 여러 기기 유형이 백엔드를 병렬로 호출할 수 있음: 브라우저가 브라우저 BFF에 요청하는 동안 모바일 기기에서도 동일한 요청을 할 수 있습니다. 서비스에서 더 빠르게 응답을 받는데 도움이 됩니다. 

- 보안 강화: 특정 민감한 정보를 숨길 수 있으며, 프론트엔드에 응답을 보낼 때 프론트엔드에 불필요한 데이터를 생략할 수 있습니다. 추상화는 공격자가 애플리케이션을 표적으로 삼기 어렵게 만듭니다. 

- 컴포넌트에 대한 팀 소유권 공유: 애플리케이션의 여러 부분을 여러 팀에서 매우 쉽게 처리할 수 있습니다. 프론트엔드 팀은 클라이언트 애플리케이션과 기본 리소스 소비 계층을 모두 소유할 수 있으므로 개발 속도가 빨라집니다. 아래 다이어그램은 BFF와 함께 이러한 팀의 분리의 예를 보여줍니다.

 

 

Best Practices to follow in practice

지금까지 살펴본 것은 정말 놀라웠습니다! 하지만 BFF는 결함이 없는 걸까요? 정답은 '아니오'입니다. 다른 모든 기술이나 패턴과 마찬가지로 BFF에도 함정이 있습니다. 이러한 함정을 피하기 위해서는 모범 사례를 따라야 합니다.

 

- 자체 포함된 포괄적인 API를 BFF로 구현하지 마세요: 자체 포함된 API는 마이크로 서비스 계층에 있어야 합니다. 대부분의 개발자는 이를 잊고 서비스 수준 API를 BFF에서도 구현하기 시작합니다. BFF는 클라이언트와 서비스 사이의 번역 계층이라는 점을 명심해야 합니다. 서비스 API에서 데이터가 반환될 때 그 목적은 클라이언트 애플리케이션에서 지정한 데이터 유형으로 변환하는 것입니다. 

- BFF 로직 중복 방지: 중요한 점은 단일 BFF 디바이스 유형이 아닌 특정 사용자 경험에 맞춰야 한다는 것입니다. 예를 들어, 대부분의 경우 모든 모바일 디바이스(iOS, Android등)는 동일한 사용자 경험을 공유합니다. 이 경우 모든 운영체제에 대해 하나의 BFF로 충분합니다. iOS용과 Android용 BFF를 따로 만들 필요가 없습니다. 

- BFF에 지나치게 의존하지 마세요: BFF는 단지 번역 레이어일 뿐입니다. 애플리케이션에 일중 수준의 보안을 제공하기도 합니다. 하지만 필요 이상으로 의존해서는 안 됩니다. API 계층과 프론트엔드 계층은 BFF의 존재 여부에 관계없이 모든 기능과 보안 측면을 처리해야 합니다. BFF는 애플리케이션에 기능이나 서비스를 추가하는 것이 아니라 부족한 부분을 채워주는 역할을 해야하기 때문입니다.

- 마이크로서비스에 대해 보다 관리하기 쉬운 BFF 패턴을 구현하려면 각 컴포넌트를 컴포넌트로 간주한 다음 모듈식, 재사용가능, 공유 가능한 접근 방식을 사용하는 것이 좋습니다. 

Summary

BFF 패턴은 개발에 도움이 될 뿐만 아니라 사용자 경험을 크게 개선하는 데도 도움이 됩니다. 따라서 BFF를 프론트엔드에 집중하면서 데이터 최적화 및 집계를 고려하는 것이 필수적입니다. 게다가 이전에 BFF 패턴을 사용해본적이 없다면 지금 바로 시작해보세요.