[번역] BFF(Backend for Frontend)란?

[sbyeol3]

부제 : Get to know the benefits of using the BFF pattern in practice
원문 : https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf

여러분이 마이크로서비스를 이용한 이커머스 어플리케이션을 만든다고 상상해보세요. 고객, 주문, 물건, 장바구니 등에 대한 마이크로서비스가 있을 것입니다. 마이크로서비스는 프론트엔드에서 사용하는 API를 노출합니다. 그러나 프론트엔드에 반환되는 데이터는 프론트엔드가 정확히 원하는 대로 포맷팅되거나 필터링 되어 있지 않을 겁니다.

이런 경우에 프론트엔드는 데이터를 다시 포맷팅할 수 있는 로직이 필요합니다. 프론트엔드에 이런 로직이 담기면 더 많은 브라우저 자원이 소모됩니다.

이와 같은 상황에서 우리는 프론트엔드 로직을 중간 레이어로 옮기고자 하는 목적으로 BFF를 사용합니다. 중간 층이 BFF인 것이죠. 프론트엔드가 특정 데이터를 요청하면 BFF에서 API를 호출합니다.

BFF는 아래와 같은 일을 할 것입니다.

• 관련된 마이크로서비스 API를 호출하고 필요한 데이터를 얻습니다.
• 프론트엔드가 원하는 대로 데이터를 포맷팅합니다.
• 포맷팅된 데이터를 프론트엔드로 보냅니다.

결과적으로 프론트엔드에는 더 적은 로직만이 남습니다. 그래서 BFF는 데이터를 표현하는 것을 능률적으로 해주고 프론트엔드에 초점을 맞춘 인터페이스 제공자의 역할을 합니다.

백엔드-프론트엔드 관계는 더 단순하게 해주는 다른 좋은 방법은 그들끼리 타입을 공유하는 것입니다. 결합되지 않은 프로젝트 사이에서 타입(또는 코드 조각)을 공유하기 위해 어떻게 Bit을 사용하는지 알아보세요.

어떻게 이커머스 예제에 적합한가?

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

BFF의 역할

이미 위에서 봤듯이, BFF는 프론트엔드와 마이크로서비스 사이에서 단순한 인터페이스 역할을 합니다. 이상적으로, 프론트엔드 팀은 BFF를 관리하는 책임을 가집니다.

하나의 BFF는 하나의 UI에 대해만 초점이 맞춰집니다. 결과적으로 프론트엔드를 단순하게 하고 백엔드를 통한 데이터에 대해 일관된 뷰를 볼 수 있게 합니다. 그러면 다음 질문이 나오겠죠. 여러 UI에 대해 여러 BFF를 가질 수 있는 걸까요? 이 질문에 대한 답은 이 아티클 마지막 섹션에서 답해드리고 합니다. 계속 읽어주세요. 😊

BFF는 latency(대기시간)를 증가시킬까?

BFF는 클라이언트와 다른 외부 API, 서비스 등 사이에서 하나의 프록시 서버의 역할을 한다는 것을 알고 있습니다. 요청이 다른 컴포넌트를 통해야 한다면 당연히 대기시간을 증가시킬 것입니다. 그러나 BFF의 대기시간은 프론트엔드에 최적화되지 않은 여러 서비스를 위해 브라우저의 많은 자원을 소비해야 하는 것에 비하면 충분히 무시할 만한 정도입니다.

BFF를 만드는 것은 다른 백엔드/마이크로서비스에 대해 지능적인 배치 호출을 가능하게 하고 한번에 데이터를 반환하거나 데이터를 변환하여 더 편리한 표현식의 데이터를 반환합니다.

이는 한 커넥션을 만드는데 수 초가 걸릴 수 있는 2G나 3G 네트워크의 모바일 클라이언트들에게 굉장히 유용합니다.

BFF 구조를 사용해야 할 때

다른 패턴들과 같이, 여러분의 어플리케이션에서 BFF를 사용하는 것은 컨텍스트와 여러분이 따르고자 하는 아키텍처에 따라 달라집니다. 예를 들어 여러분의 어플리케이션이 단순한 모놀리틱 구조를 따른다면 BFF는 필요하지 않습니다. 가치가 거의 없기 때문입니다.

그러나 마이크로서비스에 의존하고 많은 외부 API나 다른 서비스를 사용해야 한다면, 데이터 흐름을 간소화하고 어플리케이션에 많은 효율성을 제공하므로 BFF를 사용하는 것이 좋습니다.

더불어, 어플리케이션이 특정 프론트엔드 인터페이스에 대해 최적화된 백엔드를 개발해야 하거나 클라이언트가 굉장히 많은 양의 집합 연산을 요구하는 데이터를 사용해야 한다면 BFF는 꽤 적절한 선택지가 됩니다.

여러 개의 BFF를 가질 수 있을까?

그럼요! 그것이 바로 BFF를 선택하는 이유입니다. 전통적인 접근방식(BFF가 없는 어플리케이션)은 모든 클라이언트에 대해 단 하나의 API 게이트웨이만을 가집니다. 아래 그림과 같죠.

그러나 BFF를 만드는 목적은 여러분의 클라이언트에 더 맞춰진 인터페이스를 제공하는 것입니다. 예를 들어 모바일 UI에 의해 데이터를 사용하는 것과 웹 브라우저에서 데이터를 사용하는 것은 차이가 있을 수 있습니다. 이런 경우에서 더 나은 데이터 표현방식을 위해 두 개의 BFF를 가질 수 있습니다. 여러 BFF를 가지는 어플리케이션 다이어그램을 살펴봅시다.

여러분이 볼 수 있듯이, 각 클라이언트는 BFF를 가지고 있습니다. 이는 서비스에 대한 응답값들을 최적화합니다.

BFF의 장점

• 관심사 분리 - 프론트엔드 요구사항은 백엔드 관심사로부터 분리합니다. 유지보수하기가 쉽습니다.
• API 유지보수와 변경에 용이 - 클라이언트 어플리케이션은 API 구조에 대해 알아야 하는 것을 줄이므로 이는 API 변경사항에 대해 더 탄력성을 가집니다.
• 프론트엔드에서 더 나은 에러 핸들링 가능 - 대부분의 시간에서 서버 에러는 프론트엔드 유저에게 의미가 없습니다. 서버가 보내는 에러를 바로 반환하는 것보다는 BFF가 사용자에게 보여주어야 하는 에러와 매핑하는 것이 가능합니다. 이는 UX를 개선합니다.
• 병렬적으로 여러 디바이스 타입에서 백엔드 호출 - 브라우저가 브라우저 BFF에 요청을 보내는 동안 모바일 디바이스들은 동일한 것을 수행할 수 있습니다. 이는 서비스로부터 더 빨리 응답값을 얻도록 합니다.
• 더 나은 보안성 - 특정 민감한 정보는 숨기면서 동시에 프론트엔드에 응답값을 보낼 때 불필요한 정보는 생략됩니다. 이러한 추상화는 공격자들이 어플리케이션을 타겟팅하는 것을 어렵게 합니다.
• 컴포넌트의 소유권 공유 - 어플리케이션의 다양한 파트들이 쉽게 서로 다른 팀들에 의해 다뤄질 수 있습니다. 프론트엔드 팀은 클라이언트 어플리케이션과 이를 기반으로 하는 리소스 소비층에 대해 소유권을 가집니다. 이는 더 빠른 개발속도를 만듭니다. 아래 다이어그램은 BFF에 따라 팀이 분리되는 예제를 보여줍니다.

BFF에 대한 모범 사례

BFF에 대해 알아보는 동안 놀라운 것들이 많았습니다. 그러나 BFF는 모든 위험을 방지할 수 있을까요?
대답은 '아니오'입니다! 모든 다른 기술이나 패턴과 마찬가지로 BFF도 위험이 있습니다. 위험들을 피하기 위해 우리는 모범 사례들을 따라야 합니다.

• 자체적으로 포함하는 API로 BFF를 구현하는 것을 피하라 - 자체적으로 포함된 API는 마이크로서비스 층에 있어야만 합니다. 대부분의 개발자들은 이 점을 잊고 BFF에서 서비스 레벨의 API를 구현하곤 합니다. BFF는 클라이언트와 서비스 사이에서 번역의 역할을 한다는 것을 명심해야 합니다. 데이터가 서비스 API로부터 반환될 때 BFF의 목적은 해당 데이터를 클라이언트 어플리케이션에 맞는 데이터 타입으로 변환하는 것입니다.
• BFF 로직의 중복을 피하라 - 하나의 BFF는 디바이스 타입이 아니라 특정한 UX에 부합해야 한다는 점이 핵심입니다. 예를 들어 대부분에서 모든 모바일 디바이스는 동일한 UX를 공유합니다. 그런 경우라면 모든 동작 시스템에 대해서 하나의 BFF로 충분합니다. iOS와 Android에 대해 별도의 BFF가 있어야 할 필요가 없습니다.
• BFF에 대한 지나친 의존을 피하라 - BFF는 한낱 번역하는 레이어일뿐입니다. 일정 수준의 보안을 제공하기도 하죠. 그렇지만, 여러분이 의존해야 하는 것보다 더 많이 의존하지 마세요. 여러분의 API 레이어와 프론트엔드 레이어는 BFF 존재 여부와 무관하게 모든 기능과 보안을 처리해야 합니다. BFF는 틈을 메우는 용도이지 어플리케이션에 기능이나 서비스를 추가하는 용도가 아닙니다.

요약

BFF 패턴은 개발을 도울 뿐만 아니라 UX를 매우 향상시킵니다. 그래서 BFF는 프론트엔드에 집중하며 데이터 최적화와 집계를 고려하는 것이 필수적입니다. 이전에 BFF 패턴을 사용해본 적이 없다면 지금이 시작할 때입니다. 여러분의 경험과 의견을 나중에 저에게 공유해주세요. 😃

[wanderer-s]

좋은 글 잘 읽고갑니다 :)

[ironhee]

좋은 글 번역 감사합니다.

[Yoonlang]

좋은 내용 감사합니다

[woongjang]

잘 읽었습니다 감사합니다 :)

[daanta-real]

감사합니다. 예전에 다른 글을 읽고 "BFF도 서버니까 백엔드 담당자가 같이 만들면 되지 왜 프론트엔드가 직접 만들어야 하는가!" 하는 생각에 아리송했었는데 명쾌한 설명에 오늘 그 해답을 찾은 것 같습니다. 좋은 도움이 되었습니다!