-
서비스를 분리하면, API를 여러번 다르게 호출해야 한다. 이렇게 되면
- 클라이언트가 요청을 여러 번 전송하기 때문에 UX가 나빠짐
- 캡슐화가 되지 않아, 프론트 <> 백엔드 변경사항이 서로에게 영향을 미침. 커뮤니케이션 오버헤드가 커짐.
- 각 서버가 같은 IPC를 사용하리라는 보장이 없다
-
클라이언트별로도 다른 문제가 있다
- 서버 렌더링 웹 어플리케이션은 대부분 서버랑 긴밀한 연관관계를 지니므로 괜찮음
- 브라우저 기반 SPA: 복잡한 데이터의 구성은 어려울 것임
- 서드파티 어플리케이션: 하위호환성 문제가 제일 크게 대두됨. 안정성 문제도 있고.
-
방화벽에 다 열어주는 것보다 적절한 게이트웨이를 하나 파서 통신하는게 더 안전하다
- 기본적으로 Reverse Proxy 역할을 하는 친구들도 API Gateway라 부를 수 있다
- 다만 더 많은 역할을 하도록 앞서 컴포넌트를 구성할 수도 있다. 예를 들어, 저성능 네트워크에서 데이터 조합을 내부 네트워크 내에서 통신하도록 놔두고 / 저성능 네트워크에선 호출만 하는거지
-
엣지에 필요한 기능들
- Authentication / Authorization
- Rate limit (특히 External API에서)
- Caching
- Metric Collection
- Logging
-
이렇게 했을 때, 각 API 사용자들이 API 게이트웨이를 소유하고 있으면 좋음
- 넷플릭스에서 이렇게 권장함
- 다만, 배포 파이프라인이 자동화되어야 가능함
- 그래서 BFF(Backends for Frontends) 패턴이 나옴
-
장단점
- 애플리케이션 내부 구조를 캡슐화하는 장점이 있음
- 다만 관리 포인트가 늘어난다는 단점이 있음