[GraphQL]GraphQL VS REST API

January 30, 2023

REST API의 한계

블로그 앱 구현 가정

Overfetch - 필요 없는 데이터까지 제공

유저 이름만 필요한 상황에서 REST API를 사용하면 불필요한 정보 포함 가능

Underfetch - endpoint 가 필요한 정보를 충분히 제공하지 못함

클라이언트 구조 변경 시 엔드포인트 변경 또는 데이터 수정이 필요

REST API는 Resource에 대한 형태 정의와 데이터 요청 방법이 연결, GraphQL에서는 Resource에 대한 형태 정의와 데이터 요청이 완전히 분리
REST API는 Resource의 크기와 형태를 서버에서 결정, GraphQL에서는 Resource에 대한 정보만 정의, 필요한 크기와 형태는 클라이언트 단에서 요청 시 결정.
REST API는 URI가 Resource를 나타내고 Method가 작업의 유형을 나타냄, GraphQL에서는 GraphQL Schema가 Resource를 나타내고 Query, Mutation 타입이 작업의 유형을 나타냄.
REST API는 여러 Resource에 접근하고자 할 때 여러 번의 요청이 필요, GraphQL에서는 한번의 요청에서 여러 Resource에 접근 가능.
REST API에서 각 요청은 해당 엔드포인트에 정의된 핸들링 함수를 호출하여 작업 처리, GraphQL에서는 요청 받은 각 필드에 대한 resolver 호출, 작업 처리.

하나의 endpoint 요청
- /graphql이라는 하나의 endpoint 로 요청을 받고 그 요청에 따라 query , mutation을 resolver 함수로 전달해서 요청에 응답. 모든 클라이언트 요청은 POST 메소드 사용.
No! under & overfetching
- 하나의 endpoint에서 쿼리를 이용해 원하는 데이터를 정확하게 API에 요청하고 응답으로 받을 수 있음.
강력한 playground
- graphql 서버를 실행하면 playground라는 GUI를 이용해 resolver 와 schema 를 한 눈에 보고 테스트 해 볼 수 있음. (POSTMAN과 비슷)
클라이언트 구조 변경에도 지장이 없음
- 클라이언트 구조가 바뀌어도 필요한 데이터를 결정하고 받는 주체가 클라이언트이기 때문에 서버 지장 없음. 클라이언트에서는 무슨 데이터가 필요한 지에 대해서만 요구사항을 쿼리로 작성하면 됨.

GraphQL를 학습하는 데 시간이 필요
캐싱이 REST보다 훨씬 복잡
- HTTP에선 각 메소드에 따라 캐싱이 구현되어 있음. 하지만 GraphQL에선 POST 메소드만을 이용해 요청을 보내기 때문에 각 메소드에 따른 캐싱을 지원받을 수 없음. 이를 보완하기 위해 Apollo 엔진의 캐싱과 영속 쿼리 등 등장.
고정된 요청과 응답만 필요할 경우에는 Query 로 인해 요청의 크기가 더 커짐.