BFF(Backend For Frontend)의 구조가 잘 이해가 되지 않습니다.

Question

안녕하세요회사에서 BFF Layer를 구축하려고 하는데 아래 그림이 잘 이해가 잘 안되어서 질문드립니다.BFF와 API Gateway를 같이 사용할 때 이러한 구조로 설계를 하던데 API Gateway 밖에 BFF Layer를 두는 이유가 무엇일까요?아무리 생각해봐도 API Gateway를 거친 뒤에 BFF Layer를 호출하는 것이 보안 상으로 안전할 것으로 보이는데, 왜 이렇게 설계하는지 모르겠습니다.이렇게 설계하면 BFF는단순 데이터 가공하거나 바이패스의 역할만 하는 것 아닐까요? BFF의 존재 이유를 잘 모르겠어서 질문드립니다.그리고 BFF가 API Gateway가 하는 역할을 완전히 대체하고 API Gateway가 아예 없는 방향에 대해서도 어떻게 생각하시는지도 궁금합니다.도움주시면 정말 감사하겠습니다^^

AskeTeddy · Answer

BFF와 API Gateway를 같이 사용할 때 이러한 구조로 설계를 하던데 API Gateway 밖에 BFF Layer를 두는 이유가 무엇일까요?api gateway의 aggregation 를 활용하려는 모습이 보이네요. 상품, 추천, 리뷰 서비스는 각각 web, mobile, 3rd party 에게 다른 문맥으로 보여질 수 있습니다.예를 들어서 web 의 경우는 동일한 url 을 볼때 모든 구성을 볼 수 있지만, ios 나 안드로이드 경우에는 보이지 않아도 될 수 있습니다.따라서 bff는 api gateway 에서 실제 필요한 데이터를 구분하기 위해 aggregation 를 대리 호출하도록 설정을 분리한것으로 보입니다.BFF가 API Gateway가 하는 역할을 완전히 대체하고 API Gateway가 아예 없는 방향에 대해서도 어떻게 생각하시는지도 궁금합니다.이렇게 나누는 이유는 책임을 분리하기 위함입니다.만약 api gateway 가 없어지면 각 bff 는 각 서비스의 domain model 이나 schema model 정보를 알아야하기 때문에 결합됩니다. 이렇게 되면 상품 서비스의 변화가 각 bff 의 변화를 만들기 때문에 해당 서비스의 semantic 이 다수 중복됩니다만약 bff 를 빼놓고 생각한다면, graphql 이더라도 프론트엔드에서는 변경되는 api 를 호출해야합니다. 당연히 msa 의 확장성은 크게 떨어집니다

wharup · Answer

BFF는 프론트엔드/디바이스 개발팀이 필요한 기능(API)이 있는데백엔드 개발팀에 요청하기 애매해서 프론트엔드 팀이 직접 자기들만의 API 서버를 만드는 패턴입니다.그림에서 포인트는 각 프론트엔드 디바이스와 BFF API 서버가 모여있고, REAL 백엔드 서비스와는 떨어져 있는 것 입니다.그래서 API Gateway 자체는 크게 중요한건 아니고 REAL 백엔드와 거리감을 보여주는 정도의 의미 같습니다.

BFF(Backend For Frontend)의 구조가 잘 이해가 되지 않습니다.

2개의 답변

#bff 목록