요즘 사용하는 App 에서는 클라이언트 - 서버 통신에 REST API 를 사용합니다.
하지만 API 가 데이터를 오버패치/언더패치 하는 등 속도 저하를 야기할 수 있습니다.
이를 방지하고자 BFF ( Backend for Frontend ) 패턴에 대해 알아보겠습니다.
다이어그램을 보면,
1. 클라이언트는 BFF 요청을 보냅니다.
2. BFF 는 내부 서비스들과 필요한 데이터를 수집합니다.
3. 데이터를 클라이언트에게 반환합니다.
대충 이런 데이터 흐름관계가 생김을 우선 이해하자.
이런 데이터흐름에 BFF를 통해 데이터 가공 등을 통해 클라이언트에게 유의미한 데이터만 전송해주는 등
데이터 간소화로 속도향상을 얻을 수 있다.
그렇다면 BFF는 무조건 사용하는 것이 유리할까?
그렇지 않다. BFF 를 사용하는 것은 아키텍처에 따라 변화가 있다.
단순한 구조를 따른다면 BFF는 유의미하지 않기 떄문에 사용하지 않는 것이 좋으며,
외부 API 나 다른 많은 서비스 들을 동시에 사용해야 한다면, 데이터 흐름을 간소화하고,
어플리케이션에 효율성이 있기때문에 BFF를 사용하는게 좋습니다.
여러개의 BFF 를 가질 수 있나?
결론부터 말하면 여러개의 BFF 를 가질 수 있습니다.
이것이 BFF를 사용하는 이유이다.
사용자들 별로 BFF 를 만들어 필요한 데이터만 효율적으로 내려줍니다.
이를 수행하고자 GraphQL 을 사용해보는 것을 추천한다.
GraphQL 은 서버에서 클라이언트로 데이터를 효율적으로 로드가 가능합니다.
기존 REST API 와 다른점은 클라이언트가 응답 형태를 정의해서 필요없는 데이터는 내려주지 않고,
필요한 데이터만 지정해서 더 효율적으로 쿼리를 만들 수 있습니다.
GraphQL 에 대한 부분은 다른 글에서 다시 다뤄보겠다.
* 참고자료
How to use GraphQL to build Backend-For-Frontends (BFFs)
Step by step guide to implementing a GraphQL Backend-For-Frontend
blog.bitsrc.io