12월 4일 TIL

💡 BFF패턴

• 요즘엔 PC뿐만 아니라 모바일 장비를 사용하기 때문에 다양한 클라이언트를 고려해야함
  • 다양한 클라이언트를 위해서는 특화된 처리를 위한 API조합이나 처리가 필요함
  • 이걸 해결하기 위한 방법으로 BFF패턴이 존재함
  • 조금 쉽게 설명하면 프론트엔드 애플리케이션이나 인터페이스에 단일 백엔드 서비스를 지정하지 않으려는 패턴이라고 생각하면 좋음
• API 게이트웨이와 같은 진입점을 하나로 두지않고 프론트엔드의 유형에 따라 각각두는 패턴임
  • 프론트엔드를 위한 백엔드라는 의미로 BFF라고 부름
    

예시

• 현실을 예로 들어보면 애플리케이션의 상호작용하는 플랫폼이 Web으로 유일하다 사용자 기반이 늘어남에 따라서 Mobile로도 확장 되었다고 한다면
  • 백엔드 서비스는 Web과 Mobile의 인터페이스 요구사항을 모두 충족하는 범용적인 백엔드 서비스가 될것
  • 하지만 요구사항이 Web과 Mobile은 다르기 때문에 백엔드는 이를 충족하기 위해서 Web에서는 필요없는 내용까지 구현하게 된다
• 즉 여러 요구사항 충족을 위해서 응답을 조작하고 혼합하고 일치시키는 상황이 발생하고 프론트엔드에서도 복잡한 계산이나 비즈니스 로직을 작성해야하는 경우가 생긴것임
  • 이런 문제를 해결하기위해 BFF 패턴이 등장하게됨
  • 말 그대로 프론트엔드 인터페이스당 하나의 백엔드 서비스를 만듬으로써 다른 인터페이스에 영향을 주거나 받는것 없이 각각의 요구사항을 충족 시키는것
    
• 각 백엔드는 하나의 인터페이스에 고유하기 때문에 해당 인터페이스에 최적화 할 수 있음
  • 이는 결과적으로 모든 인터페이스 요규사항을 충족하는 범용적인 백엔드보다 덜 작고 덜 복잡하며 빠를것임

주의 해야할점

• 인터페이스가 백엔드에 동일 혹은 유사한 요청을 하거나 백엔드와 상호작용 하는데 하나의 인터페이스만 사용되는 경우에는 BFF가 필요가 없을수 있음
  • 그렇기 때문에 구현하기에 앞서서 다른 인터페이스의 요청사항을 잘 분석해야할 필요가 있고 BFF간의 코드중복이 발생할 가능성이 높기 때문에 인터페이스별 논리와 동작만 포함시키고
  • 일반 비즈니스 로직이나 기타 전역적인 기능은 다른곳에서 관리 할 수 있도록 해야함