안녕하세요. BFF 사용 이유 관련되서 질문이 있습니다.

안녕하세요. NEXTSTEP에서 뵈었다면, 이런저런 이야기를 직접 나눌 수 있었는데, 인강은 이런 부분이 좀 아쉽긴 한거 같아요.

우선, 첫번째 질문은 BFF 패턴의 이점으로 보이는데요.
"트래픽 대응, 크롤링, 시스템 점검과 같은 클라이언트 접근 제어와 관련된 정책을 한곳에서 관리 가능 및 보안성 수준 제공 가능"

즉, 클라이언트와 연결을 수립하는 역할을 가장 앞단의 서버(예제 코드로는 front 모듈)가 수행합니다.

이에 트래픽 대응, 크롤링 대응, 시스템 점검과 같은 책임이 부여되는데요.
이 때 크롤링은 front 모듈에서 수행하는 것이 아니라, 외부의 악의적인 의도를 가진 유저가 우리 시스템으로 수행하는 것을 의미해요. (지금 보니, 크롤링 "대응"이라고 표현했으면 헷갈리지 않으셨을거 같단 생각도 드네요 😅) Public Call이 edge server인 front 모듈만 가능하니 그 서버에만 크롤링이 가능한 것이죠.

여기서 악의적인 의도란, 시스템의 입장에서 의미예요. 가령, 홈택스 서비스 입장에선 크롤링이 의도치 않은 요청이지만, 크롤링해서 웹 컴포넌트를 이해하고 자동으로 로그인 후 여러 복잡한 세무처리를 해주는 서비스가 있다면 사용자 입장에선 그저 편리한 서비스일 수 있죠. 그래서 원천 데이터를 가진 서비스와 크롤링해서 서비스를 제공하는 업체간에 여러 공격과 방어가 이뤄지기도 하고, 경우에 따라선 정식으로 계약하고 (지금 예시에선 세무처리 서비스를 위한) 별도 API를 제공하기도 합니다. 이럴 때는 업체에 인증키를 전달하거나 해당 서비스 대역 IP만을 허용하는 형태로 구성합니다. (두가지 방법 모두 장,단점이 있을텐데요. 어떤게 있을지 한번 고민해보셔도 좋을거 같아요 😅)

두번째 질문은 내부적으로 사용하는 API와 public call을 위한 api 역할을 하는 모듈이 무엇인가로 보이는데요. 둘 다 예시 기준으로, conference, analysis 모듈입니다. (글을 다시 읽다보니.. Public Call이란 인터넷망에서 우리 시스템으로 들어오는 요청이라고 이해하시면 되어요.)

예를 들어, GET /conferences/{id} 이란 요청이 있고 그 응답값으로 id, 컨퍼런스 이름, 일정, 작성자, 컨퍼런스 장소, 컨퍼런스 내용, 컨퍼런스 타입, 컨퍼런스 등급, 작성시간, 수정시간 등이 포함되어 있다고 가정해볼게요. 그리고 실제 웹 페이지에서는 컨퍼런스 타입, 컨퍼런스 등급, 작성시간이나 수정시간이 사용되지 않을 경우, 이를 응답으로 내려줄 필요는 없을거에요. 하지만 내부의 다른 시스템에선 이 정보들이 필요할 수 있죠. 가령 batch에서 컨퍼런스 타입이나 등급에 따라 일괄적으로 알림을 보내는 기능이 있다던가, 최종 수정시간 기준으로 2년이 지난 컨퍼런스 정보는 아카이빙 한다던가 하는 규칙이 있을수도 있을거에요.

이에 front 모듈이 없다면, conference 모듈에선 Public Call을 위한 API와 내부적으로 사용하는 API를 나눠서 구성하게 되니 유지보수 비용도 커지고, 그럼 사람이 하는 일이다보니 휴먼에러가 발생할 수 있다는 의미였어요.

혹시 답변이 되었을까요? 추가로 궁금한 점이 있다면 답변 남겨주세요~

좋은 밤 보내세요.