GraphQL이란?

GraphQL은 API 용 쿼리 언어입니다.
프레임워크나 특정 기술을 가리키는 대신 데이터에 대한 쿼리 언어 사양

웹 버전 SQL = GraphQL

REST와 무엇이 다른가?

REST

RESTful API는 URL과 메소드로 리소스를 표현합니다.

GraphQL

단일 엔드포인트. 원하는 리소스를 HTTP POST의 body에 명시 적으로 기재하여 요청

장점

1. 자원을 정리할 수 있다

REST에서는 URL이 하나의 자원을 나타내기 때문에, 복수의 자원이 필요한 복잡한 화면에서는 복수회의 API 요구가 필요하게 된다.

결과적으로 깨끗하게 설계된 RESTful API만큼 여러 번의 요청이 필요하게 되어 성능이 떨어지거나 코드의 복잡성이 늘어나는 단점이 있었다.

GraphQL에서는 필요한 자원만을 명시적으로 기재해 요구해, 필요한 자원을 낭비 없이 1발로 취득 가능.

2. 중간층으로서도 활약한다

마이크로서비스의 Gateway(중간층)로서도 양근이라고 생각된다.

스키마를 정의함으로써 GraphQL에 대응하고 있는 데이터 소스를 취득할 수 있다.
DB를 직접 취득할 수도 있고, 기존의 REST API를 내부적으로 두드려 취득시킬 수도 있다.

REST API와 마음이 다른 곳

리소스 제한 관점

API에 이용 제한을 마련하는 경우, REST에서는 1시간에 x회 마데 등의 횟수 기반의 제한을 마련하는 예가 자주 있지만,

GraphQL은 당기는 자원수(=부하)는 클라이언트가 임의로 결정되기 때문에, 부하의 계산 방법을 생각할 필요가 있다.

github의 GraphQL API v4는 핥는 객체의 수를 score로 해, 그것을 1시간에 넘지 않는 범위에서 리퀘스트 가능하게 하고 있다.

캐시 효율

GraphQL은 단일 엔드 포인트이므로 HTTP의 Cache-Controll과 같은 URL 기반 캐시 메커니즘과 CDN 캐시는 그대로 사용할 수 없습니다.

캐시를 사용할 수 없는 것이 아니라 서버, CDN, 클라이언트의 각 계층에서 캐싱의 현실적인 구현이 준비되어 있기 때문에
별도 필요한 것을 구현해야 한다.

오류 처리

REST에서 오류는 HTTP 상태 코드로 표현됩니다.

GraphQL에서는 리퀘스트가 통과하면 200으로 돌려주고, 무언가 에러가 발생했을 때는 에러 오브젝트에 표현된다.

요약

다양한 데이터 소스를 다룰 수 있기 때문에 Good

Web판 SQL이 발행할 수 있어 이이네!

REST API 개발에서 API가 너무 많아서 유지보수가 힘들다는 것은 GraphQL이 아니게 될 것 같다.

리소스 제한, 캐시 효율성, 오류 처리 방법 등 REST API와는 다른 노하우가 필요합니다.

앞으로의 주류가 되어 갈 것 같기 때문에, 열심히 습득하고 싶다.

참조 URL