BFF 서버에 SSE를 도입한 이유: 전시 서버의 통신 구조 재설계
아키텍처
BFF 서버에 SSE를 도입한 이유: 전시 서버의 통신 구조 재설계
두줄요약
가게목록 전시 구조를 1지면 1API와 BFF 기반 SSE 스트리밍으로 재설계했습니다. 첫 응답을 앞당기고 클라이언트 통신 복잡성을 줄이는 방향을 소개했습니다.
핵심 내용
- 가게목록 지면이 여러 구좌와 서버가 얽힌 통합 전시 지면으로 커지면서, 클라이언트가 다수 서버를 직접 호출하는 구조의 복잡성이 누적됨
- 이를 해결하기 위해 BFF 전시 서버를 두고 1지면 1API로 통합하며, 응답은 SSE 스트리밍으로 점진 전송하는 구조로 재설계
- SSE는 초기 렌더링을 앞당기고, 서버의 지면 컨트롤과 클라이언트의 렌더링 집중을 동시에 가능하게 함
선택 이유
- 단일 REST 응답은 데이터 비대화와 느린 작업 기준의 하향 평준화를 유발할 수 있음
- EventSource 대신 fetch 기반 스트리밍을 택해 인증 헤더, 취소, 기존 REST 검증 흐름을 유지
- 전시 조회 시나리오에서 양방향성보다 안정적인 단방향 점진 전송과 표준 메시지 포맷을 우선
주의할 점
- 모든 API를 SSE로 바꾸지 않고, 나눠 보낼 이유가 없는 단순 응답은 REST 유지
- EventSource 제약으로 커스텀 헤더를 못 붙이는 문제를 구현 방식으로 보완
- nginx 버퍼링 이슈는 설정 관성보다 실제 스트리밍 동작과 문서, 실험으로 확인할 필요
적용해볼 점
- 화면 단위 통합이 커질수록 클라이언트 직접 조립 대신 BFF로 책임을 모으는 방식 검토
- 첫 화면 반응성과 점진 렌더링이 중요한 조회 지면에 SSE 적용 검토
- 캐시를 통해 재방문 시 스트림을 생략하고, 최초 진입과 갱신 시에만 단일 커넥션 사용
