드디어 관심을 가지고 있던 GraphQL 부분에 대한 학습을 진행했습니다. 앞으로 GraphQL을 활용한 프로젝트도 직접 구성해보고 싶은 마음이 있어 최대한 꼼꼼하게 학습해보려고 했습니다.
해당 포스팅은 6월 초에 예정된 React 심화 강의 후에 보충할 계획입니다.
GraphQL의 개념
GraphQL 소개
GraphQL은 페이스북에서 만든 쿼리 언어입니다. 쿼리 언어이기 때문에, gql은 sql과 유사한 점도 있지만, gql과 sql의 언어적 구조 차이는 매우 큽니다.
그로 인해 gql과 sql이 실전에서 쓰이는 방식의 차이도 매우 큽니다. sql은 데이터베이스 시스템에 저장된 데이터를 효율적으로 가져오는 것이 목적이고, gql은 웹 클라이언트가 데이터를 서버로 부터 효율적으로 가져오는 것이 목적입니다.
sql의 문장(statement)은 주로 백앤드 시스템에서 작성하고 호출 하는 반면, gql의 문장은 주로 클라이언트 시스템에서 작성하고 호출 합니다.
gql은 곧 API를 위한 쿼리 언어이며, 타입 시스템을 사용하여 쿼리를 실행하는 서버사이드 런타임입니다.
즉, 프론트엔드 단에서 매우 빈번하게 사용할 가능성이 높은 쿼리 언어라고 볼 수 있습니다.
HTTP API 자체가 특정 데이터베이스나 플렛폼에 종속적이지 않은 것 처럼 마찬가지로 GQL 역시 어떠한 특정 데이터베이스나 플렛폼에 종속적이지 않습니다.
GraphQL의 장점
gql의 장점은 기존의 RESTful API와의 비교를 하면서 이해하는 것이 효과적입니다.
1. HTTP 요청의 횟수를 줄일 수 있습니다.
RESTful API는 각 리소스 종류 별로 요청을 해야하고, 따라서 요청 횟수가 필요한 리소스의 종류에 비례합니다.
하지만 gql 은 원하는 정보를 하나의 Query 에 모두 담아 요청하는 것이 가능하기 때문에, HTTP 통신 요청이 과도하게 발생하지 않습니다.
2. HTTP 응답의 크기를 줄일 수 있습니다.
RESTful API는 응답의 형태가 정해져있고, 따라서 필요한 정보만 부분적으로 요청하는 것이 힘듭니다.
반면 gql은 원하는 대로 정보를 요청하는 것이 가능합니다.
GraphQL의 단점
1. File 전송 등 Text 만으로 하기 힘든 내용들을 처리하기 복잡합니다.
고정된 요청과 응답만 필요할 경우에는 Query 로 인해 요청의 크기가 RESTful API 의 경우보다 더 커지는 경우도 발생합니다.
- 재귀적인 형태의 Query가 불가능합니다.
결과에 따라 응답의 깊이가 가변적으로 깊어지는 API를 만드는 데 한계가 있습니다.
GraphQL을 사용하는 경우
1. 서로 다른 모양의 다양한 요청들에 대해 응답할 수 있어야 할 때
2. 대부분의 요청이 CRUD(Create-Read-Update-Delete) 에 해당할 때
3. File 전송 등 단순한 Text 로 처리되지 않는 요청들이 있을 때
4. 요청의 구조가 정해져 있을 때
기본적으로 gql이 더 적합한 상황이 있고, RESTful API가 더 적합한 상황이 있으므로 반드시 하나를 선택할 필요는 없겠습니다.
물론 하나의 Endpoint를 gql 용으로 만들고, 다른 RESTful endpoint를 만드는 것도 가능합니다.
다만, 두 API structure 를 섞어놓는 것은 결과적으로 API의 품질을 떨어트릴 수 있다는 것입니다.
