Unclebae
School Dev Ops Stubs
Learn Devops and Do Devops

REST, GRPC, GraphQL 비교

REST, GRPC, GraphQL 비교

REST

  • 오랜 히스토리를 가짐, 사실상 10년이상 웹 프로그래밍의 표준
  • 웹 어플리케이션 개발에서 대부분 이용, 모바일 앱의 엔드포인트, 다른 니즈에 의한 어플리케이션 통합에 이용

핵심

  • HTTP 프로토콜이용
  • HTTP Verb와 StatusCode 이용
  • JSON 을 페이로드로 사용
  • HATEOAS 사용
  • Stateless

이점

  • Easy to scale:
    • stateless 이므로 가능
    • REST 는 스케일링이 매우 쉽다.
    • 다른 인스턴스를 띄우는 것으로 스케일 아웃 가능
  • Easy to integrate:
    • HATEOAS 를 이용하면 클라이언트가 리소스를 어떻게 가져와야할지 바로 알 수 있다.
  • Performance:
    • HTTP 프로토콜을 이용하는데 생기는 이슈
    • 웹 서버와 클라이언트에 일반적인 방법을 이용하며, 캐싱등을 이용하여 성능 향상

단점

  • REST 는 hard 하다.
    • 많은 제약조건이 있음 (HATEOAS)
  • Overfetching
    • 보통 데이터를 뷰잉하기 위해서 패치하며, 하나 이상의 요청이 필요함
    • 가끔 서버 데이터 구조에 따라 필요할 데이터보다 더 많은 데이터를 반환한다.
  • No uniform style for documentation
    • 테스트를 위해서 Postman 을 이용하고, 다른 사람은 Blueprint 를 이용하거나, Swagger/OpenAPI, RAML 등을 이용
  • Versioning API
    • 필드가 디프리케이트 되면 많은 두통을 수반할 정도

유즈케이스

  • 커머셜 API:
    • 각 엔드포인트마다 다른 ACL 과 속데 제한이 있다.
    • 데이터가 자주 바뀌지 않은경우, 캐싱이 도움이 된다.
  • API 생성에서 가장 많이 사용되는 방법
  • 특정 회사는 자신의 데이터 제공을 이를 통해 수행, 이 의미는 현재까지도 가장 주요한 엔드포인트이다.

GRPC(gRPC Remote Procedure Calls)

  • 가볍꼬 빠른 접근 방법을 제공한다.
  • 제한된 시스템 리소스를 위해 주로 사용됨

핵심 기능

  • HTTP/2 와 Protobuf 에 의존한다.
  • 스트리밍 지원
  • 구글에 의해서 만들어짐

이점

  • 강력한 타입:
    • REST(JSON 으로 주로 사용), gRPC는 Protobuf 이용한다. 구조적 메시지
  • 내장된 코드 제너레이터:
    • SDK 생성을 위해 쓰고, 읽기가 쉽다.
  • HTTP2 이용하므로, HTTP 인증과, 요청 헤더와 같은 이점이 존재함
  • REST 서비스에 비해 매우 빠르다.
  • Proto file 은 일반적으로 문서 그 자체이다. 3파티 툴이 필요하지 않다.

단점

  • 디버깅/테스팅을 위한 내장 UI가 없다.
  • CURL 엔드포인트를 바로 이용할 수 없다.
  • 테스트용 Harness 가 필요하다.
  • HTTP 캐싱을 활용할 수 없다.
  • (각 gRPC는 POST 메소드 호출이다)
  • 오버 페칭

유즈케이스

  • 모바일 어플리케이션을 위한 SDK 생성시 필요
  • 클라이언트 코드 작성을 꺼리는 겅유 (gRPC는 자동으로 클라이언트 코드를 생성해준다. 내장 로드밸런싱을 가지며, 커넥션 풀이 있다.)
  • 스트리밍, RCP 스타일의 API 가 필요한경우, gRPC 는 좋은 선택이다.

GraphQL

  • 새로운 표준이며, 뒤늦게 인기가 있게됨
  • GraphQL 은 Facebook 에 의해서 릴리즈 되었음

핵심 기능

  • GraphQL 은 이미 존재하는 인프라를 버리지 않고, 최대한 활용하는 것
  • GraphQL은 정의를 하며, 사양은 아키텍처 스타일보다 더 엄격함 (REST에 비해서 엄격함)
  • JSON 타입 사용

이점

  • GraphQL은 GraphiQL 을 가지고 있음
    • 테스팅을 위한 UI, 엔드포인트를 위한 문서 브라우저
  • 클라이언트는 필요한 것을 정확하게 지시, 예측 가능한 방식으로 데이터 수신
    • 오버페칭, 데이터 regundancy 없음
  • 클라이언트 어플리케이션은 하나의 요청으로 다른 리소스들로 부터 많은 데이터를 페치할 수 있음
  • 강력한 타입 제공
  • 회고, API 구조 쿼리 기능 및 표시되는 데이터 제공

단점

  • 공식적인, 내장 캐시가 없음
  • 서큘라 쿼리는 매우 풀기 어려운 문제임
  • 복합 엔드포인트들은 작성이 어렵고, 성능 저하 (schema stitching 이라고 부름)
  • 잠재적으로 데이터 모델이 드러남

유즈케이스

  • 복잡한 객체를 가진경우 (복수의 레벨에 네스티드 리소스)
  • 데이터 모델이 빠르게 변화 발전 하는 경우
  • 안정적인 REST API, RPC 등을 가진경우, 그리고 단일 엔드포인트의 이점을 원하는 경우