GraphQL? better than REST?

GraphQL 강좌 1편: GraphQL이 무엇인가? | VELOPERT.LOG

GraphQL 이란 ( + 장점)

페이스북에서 만든 application layer 쿼리 언어이다.

기존에 RESTAPI 는 서버가 특정 데이터를 쿼리해서 얻은 결과를 반환하는 각각의 엔드포인트에
(예를들어 baseURL/user/get/ - 특정 유저 정보 쿼리)

요청을 던져 해당 데이터를 불러오는거라면

GraphQL은 필요한 정보를 쿼리문으로 만들어 하나의 엔드포인트에 던지면

해당 쿼리에 맞는 결과를 반환해 주는 방식으로 동작한다.
(baseURL+쿼리)

이 방식의 장점은 쿼리를 직접 작성하여 클라이언트가 딱 필요로 하는 정보만 받아 볼 수 있기 때문에

overfetch 나 underfetch (서버 개발자가 에라 모르겠다 SELECT * FROM TABLE 해서 넘기는 경우) 를 걱정할 필요가 없어진다.

어떤 데이터베이스를 사용하던 상관이 없다.

REST 같은 API 디자인에 관한 새로운 관점이다.

리소스를 url이 아니라 Query를 통해 표현한다는 것 이다.

Advantages and Disadvantages of GraphQL | Stable Kernel

단점

GraphQL 은 항상 HTTP 상태코드 200을 반환한다.
쿼리가 성공하면 결과 JSON 데이터는 error key 의 최상단에 위치한다.  (error key 는 error message 와 stacktrace 내용)
이 부분은 error handling 하고 monitoring 하는데 어려움을 줄 수 있다.

lack of built-in-caching support. 
REST APIs 는 여러개의 endpoint 가 있어 native HTTP caching 을 통해 refetching resources 를 leverage 할 수 있다.
GraphQL 에서는 본인만의 caching support 를 해야한다. 

complexity. 간단한 Rest API 와 어느정도 일관되는 데이터를 다룬다면 그냥 RESTAPI를 사용하는게 나을 수 있다. 
빠르게 데이터가 변하는 부분에서는 GraphQL을 쓰면 API platform 을 설계하는데 있어 장점이 될 수 있다. 

https://goodapi.co/blog/rest-vs-graphql

https://goodapi.co/blog/rest-vs-graphql

성능상 문제

GraphQL Query framework 오버헤드 문제

1. Parse: 쿼리를 abstract syntax tree (AST)로 파싱
2. Validate : AST 검사, 조회한 필드 있는지 검사
3. Execute : invoke resolvers, collects result, emit JSON

이 세가지 작업이 API framework 머리에 달려있다. 

쿼리를 parsing 하는 작업과 execution 하는 작업은 쿼리 사이즈에 따라 memory + CPU intensive 한 작업이다.

HTTP REST 쿼리와 GraphQL 의 차이는 GraphQL payload 는 데이터 + 메타데이터를 가지고 있다는 것 이다. 메타데이터는 데이터 쿼리보다 크고 서버는 이 메타 데이터를 이해하기 위해 파싱해야 한다. 그래서 메타데이터를 GraphQL AST 로 파싱하는 작업은 expensive 하지만개발자가 쿼리의 set 를 제한함으로써 피해갈 수 있다.

GraphQL + RDB vs GraphQL + NoSQL

GraphQL 에서는 DB 성능에 중요한 키가 되는 JOIN 명령어를 쓰지 않아서 성능상 이득이 없다고 한다. 그래서 MongoDB와 같은 NoSQL이 더 어울릴 거라고 생각하는데 결론은 둘다 또이또이하다고 한다.

GraphQL의 장점은 클라이언트가 요청하는 데이터를 결정하기 때문에 고민의 주체가 서버가 아닌 클라이언트로 넘어가게 된다.

요청하는 데이터의 depth가 깊어지면 GraphQL의 성능에 대한 고민을 해야하는 데 쿼리의 maxDepth를 설정해 요청을 제한하는 방식을 주로 사용한다고 한다.

GraphQL을 오해하다

쓸까 쓰지말까?

1. REST 도 엔드포인트 많은 것 빼고는 GraphQL 에게 꿀리지 않는다.
2. GraphQL 은 간단한 작업을 복잡하게 처리해야 할 수 도 있다.
3. web cache 를 쓰는데 REST 가 더 좋다.
4. GraphQL queries 에 성능 이슈가 있을 수 있다.
5. GraphQL schemas 가 동작하는 방식이 문제가 될 수 있다.
6. REST 구조를 완벽하게 이해하지 못하고 HTTP protocol 도 모르고 이해할 시간도 없다면 GraphQL을 써라

5 reasons you shouldn’t be using GraphQL - LogRocket Blog

 

정리

REST 장점

• 무한정의 확장성
• 높은 성능( 특히 HTTP2)
• 몇십년 동안 검증됨
• 경제성 중심
• server-driven app state
• decoupling client and server

REST 특징 (중립)

• 먼저 구조를 디자인 하고 개발해야함
• 특정 요구에 대한 다수의 API들
• reference 문서 필요없음

REST 단점

• 완전히 이해하고 학습하기 힘듬
• client 를 위한 tool 이 없음
• 정확하게 하려면 REST 전문가 여야함
• 잘 모르고 REST 로 덤비면 GraphQL보다 못한 결과를 얻을 수 있음
• 일관성 유지하기 어려움

GraphQL 장점

• 시작하기 쉬움
• 만들고 소비하기 쉬움
• Contract driven by nature
• built in introspection
• 일관성 유지하기 쉬움

GraphQL 특징(중립)

• 구현 먼저 하고 나중에 query optimize
• API 하나로 완성
• reference documentation needed

GraphQL 단점

• distributed system 의 문제점을 무시함
• client programming time 에 server 와 client 가 coupled 됨
• query optimization 필요
• Bikeshedding (사소한 문제들, network error, caching 등)
• scaling 과 performance 직접 담당
• HTTP 의 17년 짬을 다 버림
• JSON 만 가능함
• 지원하는 vender 가 적음

REST vs. GraphQL: A Critical Review

 

Using GraphQL in iOS using Swift