Home API 게이트웨이
Post
Cancel

API 게이트웨이

사이드 프로젝트를 프론트 프로젝트 하나 + 백엔드 프로젝트 세 개로 구성하려고 한다. 하지만 이렇게 구성하게 되면, 프론트가 request를 보낼시 어떻게 백엔드의 알맞은 백엔드 프로젝트로 가는건지 궁금해서 찾아보게 되었다.


Api Gateway, 왜 나온거야?

  • 최근 마이크로 서비스 아키텍처 형태로 프로젝트들을 구성하면서 많은 프로젝트들의 엔드포인트를 관리하기 힘들어졌다.
  • 분리된 서비스들 간에 공통적으로 필요한 기능(인증, 로깅) 등을 중복으로 개발해야하는 문제점이 발생했다.

사용하는 이유

1. 여러 백엔드 서비스를 호출하고 결과를 집계할 수 있다.

클라이언트가 API Gateway에 request를 보내고 API Gateway는 해당 request를 관련된 서비스 프로젝트로 보낸다.

  • 게이트웨이는 요청에 대한 단일진입점이다.

API Gateway

2. 인증을 한 번만 해도 된다.

API Gateway가 인증을 처리하면 인증로직과 서비스 로직간의 의존성이 줄어든다. 또한 모든 요청은 API Gateway를 통해서 이루어지는데 거기서 검증을 마쳤다면 추후 다른 로직에서는 인증을 고려할 필요가 없다.

3. 정보 수집에 용이하다.

모든 요청은 API Gateway를 통해서 이루어지기 때문에 어떤 요청이 많은지 등 데이터를 수집하기에 좋은 환경이다.

4. 입력된 정보의 유효성을 검사한다.

API Gateway는 필요한 필수 정보가 포함되어있는지 올바른 형식으로 제공되는지 확인한다.

This post is licensed under CC BY 4.0 by the author.

Docker 기본

OpenFeign으로 인한 순환참조 에러