582
3
부
사람
BFF
를 두는 것은 언뜻 보기에 합리적으로 보인다. 필자와 이야기한 사운드클라우드 엔지니어
가 안드로이드 및
iOS
청취자 애플리케이션에 대해 하나의
BFF
를 갖는 것이 재고할 점이라고
제안한 사실은 주목할 만하다. 그들에게는 하나의 모바일 팀이 있었지만, 실제로는 안드로이드
전문가와
iOS
전문가가 섞여 있고 대부분 둘 중 하나의 애플리케이션에서 작업했다. 이는 실제
로는 두 팀이라는 것을 의미한다.
종종 적은 수의
BFF
를 유지하려는 것은 너무 많은 중복을 피하려고 서버 측 기능을 재사용하
는 데 목적이 있다. 하지만 이를 처리하는 다른 방법이 있으며 다음 절에서 살펴본다.
14.10.214.10.2
재사용과 재사용과
BFFBFF
사용자 인터페이스당 하나의
BFF
를 갖는 것에 대한 우려 중 하나는 결과적으로
BFF
사이에
많은 중복이 발생할 수 있다는 점이다. 예를 들어 동일한 집계 타입에 하위 서비스와 인터페이
스하기 위해 동일하거나 유사한 코드가 사용될 수 있다. 공통 기능을 추출하려는 경우 그 기능
을 찾는 것이 종종 어려운 점 중 하나다. 이러한 중복은
BFF
자체에서 발생할 수 있지만, 결국
다른 클라이언트에도 발생할 수 있다. 이 클라이언트들은 매우 다른 기술 스택을 사용하므로
중복이 발생하고 있다는 사실을 알아채기 힘들지도 모른다. 서버 측 컴포넌트에 대한 공통 기
술 스택을 사용하는 경향이 있는 조직에서는 중복된 여러
BFF
를 발견하고 제거하기가 더 쉬울
것이다.
어떤 사람들은
BFF
를 다시 합치길 ...