GraphQL 공부해보기

배경

애플리케이션의 규모가 커질 수록 모던 웹 프론트에서는 다양한 진보된 접근법을 사용해서 서버로부터 데이터를 가져올 수 있다.

그 중 사용자가 정의한 데이터 타입 시스템을 사용하여 쿼리를 실행하는 서버측 런타임이자, API를 위한 쿼리 언어인 GrpahQL에 대해서 알아보자.

왜 나왔을까?

기존의 웹은 REST API를 호출하여 데이터를 가져오지만 이는 쿼리 내에 불필요한 데이터를 함께 가져와야 하고 더불어 필요한 데이터만 가져올 수 없는 단점이 존재 했다 이를 보완 하기 위해 facebook에서 개발 하였다.

왜 주로 POST요청을 사용할까?

복잡한 쿼리 구조

GrpahQL 쿼리는 문자열 형태로 복잡하고, GET방식의 URL 길이 제한 (대략, 2000자 내외)를 넘는 경우가 많다.

변수 및 인증 정보 포함

POST는 요청 바디에 query, variables, operationName 등을 포함할 수 있어서 복잡한 요청을 깔끔하게 처리할 수 있다.

Mutation은 반드시 POST

데이터 변경은 mutation을 사용하고, 이는 HTTP 명세상 안전하지 않은 작업이므로 GET이 아닌 POST로 사용해야 한다.

GET방식도 사용 가능!

단순한 쿼리를 처리 할 때 허용

캐싱이 필요한 경우 허용

하지만 위의 POST요청을 사용하는 이유로 일반적으로 POST 선호

왜 단일 엔드포인트를 사용할까?

리소스 중심이 아닌 쿼리 중심

어떤 데이터 조각이 필요한지를 쿼리 언어로 명시하기 때문에 API구조가 아닌 쿼리 자체가 중요한 구조

버전 관리가 필요 없음

REST는 종종 /v1/,/v2/ 등 엔드포인트 버전을 가져가지만,
GraphQL은 쿼리에서 어떤 필드를 가져올지 명시하므로 버전 없이도 유연한 확장이 가능

Ex : )
주소+전화번호를 받는 API가 있는데 나중에 어떠한 규정이나 요구사항에 의해
주소+전화번호+수령인 까지 받아야 한다면 이는 버전별로 관리 해야 한다.

구형 애플리케이션은 주소+전화번호를 그대로 사용하고
최신 애플리케이션은 주소+전화번호+수령인 을 사용할 수 있기 때문에
GraphQL은 새 필드를 추가만 해도 기존 쿼리는 그대로 동작한다.
(스키마 변경이 호환되도록 설계)

클라이언트 유연성

클라이언트가 원하는 데이터만 선택해서 요청할 수 있으므로, 서버는 하나의 진입점만 제공해도 충분

적용 예제 프로젝트

현재 운영하는 블로그 소스를 GraphQL ,Apollo Client 조합으로 적용해봄 ( 적용 예제 프로젝트 )

적용 후 문제점 및 느낀점 🤔

Apollo서버를 api router를 이용해서 구현했으나 빌드시 Apollo서버가 먼저 존재하지않아 빌드가 되지 않은 문제점
스키마쪽 적응이 쉽지 않았다. ( 많은 에러 경험 )
확실히 REST와 다르게 필요한 데이터만 요청하므로써 불필요한 네트워크 요청을 줄일 수 있다. ( 특히 더 큰 규모의 프로젝트라고 생각하면 많은 사용자가 api를 요청하면 부하가 더 클텐데 이를 생각하면 훨씬 효율적일것 같음 )
백엔드가 따로 존재한다고 했을 때 백엔드 개발자없이 나 자신이 스스로 처리할 수 있다는 점?
각 아티클에 tag 값이 있는데 이를 모든 아티클 정보를 가져올때 커스텀 해서 가져와야 좋을지 아니면 tag 전용 쿼리를 만들어서 따로 가져올지에 대한 고민?