IT 스터디/논리 구조 스터디

단일 API / 복수 API 어떻게 설계해야 최대의 효율을 낼까? [API Gateway Pattern]

솔파니 2024. 4. 4. 01:29
반응형

Q.

만약 프론트 한 페이지 내에서 주문 명세 API, 배송명세 API 등 여러 api 를 불러 와야 할 때,
API를 여러 개 선언해서 각 데이터를 불러오는 게 효율적일까?
아니면 백에서 API 하나로 여러 개를 불러오는 로직을 구현하는 게 효율적일까 ?
이유는 가져와야 하는 API 수가 많아질수록 코드가 지져분해지기도 하고
백에서 요청 받은 파라미터나 타입을 삼항연산자나 포문으로
한번 걸러서 요청타입에 맞는 데이터를 반환하게 하는게 클린 코드를 위한
더 나은 방법아닐까? 라는
의문이 갑자기 들었습니다.

 

 A.

이 질문은 프론트엔드와 백엔드 간의 API 호출 전략과 관련 있으며, 최적의 접근 방식은 애플리케이션의 요구사항, 성능, 유지보수성 및 확장성을 고려해 결정되어야 한다.
여러 개의 API를 선언해서 각 데이터를 불러오는 방법과 백엔드에서 단일 API로 여러 데이터를 묶어서 불러오는 방법에는 각각 장단점이 있다.

 

여러 개의 API를 사용하는 방식의 장단점


장점

  • 모듈성: 각 API가 특정 기능에 집중할 수 있어 백엔드 코드가 더 모듈화되고 관리하기 쉬워진다.
  • 유연성: 프론트엔드에서 필요한 데이터만 선택적으로 요청할 수 있어 네트워크 사용량을 최적화할 수 있다.
  • 병렬 처리: 여러 API 요청을 동시에 보내어 데이터를 병렬로 불러올 수 있어, 특정 상황에서는 더 빠른 로딩 시간을 달성할 수 있다.

단점

  • 관리 복잡도: API 수가 많아지면 관리해야 할 엔드포인트가 많아져 복잡도가 증가한다.
  • 프론트엔드 부담: 각각의 데이터를 불러오기 위해 별도의 API 호출을 관리해야 하므로 프론트엔드 코드가 복잡해질 수 있다.
  • 성능 문제: 여러 개의 API를 순차적으로 호출해야 하는 경우 전체 페이지 로딩 시간이 길어질 수 있다.

 

 

단일 API를 사용하는 방식의 장단점


장점

  • 통합된 요청 처리: 필요한 모든 데이터를 한 번의 요청으로 불러올 수 있어 네트워크 오버헤드가 감소한다.
  • 프론트엔드 간소화: 프론트엔드에서 하나의 API 호출만 관리하면 되므로 코드가 단순해진다.
  • 성능 최적화: 단일 요청은 여러 개의 순차적 요청보다 전체적인 응답 시간을 줄일 수 있다.

단점

  • 유연성 감소: 특정 데이터만 필요한 경우에도 전체 데이터 세트를 받아야 하므로, 데이터 효율성이 감소할 수 있다.
  • 백엔드 복잡도 증가: 백엔드에서 여러 데이터 소스를 통합해야 하므로 로직이 복잡해질 수 있다.
  • 확장성 문제: 애플리케이션의 기능이 확장됨에 따라 단일 API가 과부하될 수 있으며, 수정 시 다른 부분에 영향을 줄 수 있다

 

 

💡 Conclusion

선택은 프로젝트의 특정 요구에 따라 달라진다.
만약 프론트엔드가 동적으로 변화하는 데이터를 다루고 사용자 경험(UX)에 큰 영향을 미치는 애플리케이션이라면, 여러 개의 API를 사용하여 필요한 데이터만 불러오는 것이 좋을 수 있다.
반면, 데이터가 상호 의존적이고 페이지 로딩 시 모든 데이터가 거의 항상 필요한 경우,
단일 API 방식이 더 효율적일 수 있습니다.


개발 과정에서는 이 두 접근 방식의 장단점을 고려하여, 프로젝트의 유지보수성, 확장성,
성능 요구 사항을 충족하는 최적의 방법을 선택해야 한다.
때로는 두 방식을 적절히 혼합하는 것이 가장 이상적인 해결책이 될 수도 있다.

 

 

단일 API 디자인 패턴을 알아보자

API Gateway Pattern

API 게이트웨이 패턴은 클라이언트의 다양한 요청을 받아 적절한 마이크로서비스로 라우팅하는

중앙 집중식 진입점을 제공한다.

이 패턴은 단일 API 접근점을 제공하면서도, 내부적으로는 여러 서비스에 대한 요청을 처리할 수 있게한다.

 

 

API Gateway는 서비스로 전달되는 모든 API 요청의 관문 역할을 하는 서버 시스템의 아키텍처를 내부로 숨기고 외부의 요청에 대한 응답만을 적절한 형태로 응답한다

즉, 클라이언트는 내부 구조가 어떠한 아키텍쳐인지 알 필요 없이 서로 약속한 형태의 API 요청만을 서버로 보낸다. 

 

 

 

reference : https://kchanguk.tistory.com/156

반응형