BFF(Backends for Frontends) Pattern

정의

특정 frontend 애플리케이션 또는 인터페이스에서 사용할 별도의 서비스를 만드는 패턴이다.

왜 필요한가?

애플리케이션 초기 개발할 때 데스크톱 Web UI를 대상으로 개발한다고 가정해보자.

사용자가 많아짐에 따라 서비스 확장이 필요하고 모바일 애플리케이션 개발이 필요하다.

이때, 데스크톱 Web UI와 모바일 애플리케이션의 인터페이스 요구 사항을 모두 만족하는 범용 backends 서비스를 구축했다고 가정해보자.

당장은 괜찮지만 모바일 디바이스의 기능은 화면 크기, 성능, 디스플레이 제한 측면에서 브라우저와 크게 다르다는 제약사항이 있다.

즉, 당장은 요구사항을 맞추더라도 계속해서 유지보수를 하는 데에 충돌이 발생할 수 있다. 

BFF를 사용하지 않는 경우

주기적 배포, 변화 등이 발생할 때마다 backends 서비스가 개발 프로세스의 병목 지점이 될 수 있다.

모바일, 웹 인터페이스 팀으로 나눠져 있을 때, 각각의 인터페이스 팀은 본인 팀의 역할뿐만 아니라 다른 팀의 영역에도 업데이트 시 문제가 발생하지 않는지 검토해야 한다.

해당 과정에서 다른 팀과의 충돌이 발생할 수도 있으며, 업데이트 과정에 대해 부담감을 느낄 수 있다.

BFF를 사용하는 경우

사용자 인터페이스당 하나의 backends 서비스를 만들게 된다.

각 서비스의 동작과 성능을 미세 조정하여 frontends 환경의 요구사항에 부합할 수 있도록 조정할 수 있다.

무엇보다 다른 frontends 환경에 영향을 줄 염려가 없다.

결과적으로 범용적인 backends 서비스보다 더 작고, 덜 복잡하고, 더 빠른 서비스를 제공할 수 있다.

또한 언어 선택, 릴리즈 일정, 작업 우선 순위, 기능 통합 등 문제에 있어서 유연하게 처리할 수 있다.

문제 및 고려사항

• 관리해야 할 backends 서비스 수가 증가한다.
• 여러 인터페이스가 동일한 요청을 수행하는 경우 구현이 정말 필요한지, 단일 backends로 충분한지 고려해야 한다.
• 해당 패턴을 구현할 시 서비스 간의 코드가 중복될 가능성이 높다.
• 구현 시 각 frontends 인터페이스의 논리 및 동작만 포함해야 한다. (다른 인터페이스 고려 x)
• 해당 패턴이 개발 팀의 업무에 어떻게 반영될 수 있는지 생각해봐야 한다.
• 패턴을 구현하는 데 걸리는 시간을 고려해야 한다. (기술적인 문제가 초래될 수 있는가)

해당 패턴을 사용해야 하는 경우

• 범용 backends 서비스를 유지 관리하는 데에 상당량의 오버헤드가 발생할 경우
• 특정 클라이언트 인터페이스 요구 사항에 맞게 최적화하려고 할 때
• 여러 인터페이스를 수용해야 할 때
• 기존과 다른 언어를 사용하고자 할 때

적합하지 않은 경우

• 인터페이스가 backends에 대해 동일하거나 유사한 요청을 수행하는 경우
• 상호 작용하는 인터페이스가 하나일 경우