GraphQL(Graph Query Language)

핫하다고 이야기만 들었던 GraphQL이 무엇인지 파악하기 위해 정리를 해보았다.

Query Language

Query Language 는 정보를 얻기 위해 보내는 질의문(Query)을 만들기 위해 사용되는
Computer 언어의 일종인데 GraphQL 은 이런 Query Language 중에서도 Server API 를 통해
정보를 주고받기 위해 사용하는 Query Language 이다.

Restful API 로는 다양한 기종에서 필요한 정보들을 일일히 구현하는 것과
다른 부분마다 API를 구현하는 것이 힘들다는 것이 GraphQL이 등장하게 된 계기이다.

---

GraphQL 구조

Query, Mutation, Subscription

Query 는 객체 구조로 표현한다.

Query: 읽기를 요청하는 구문이고 Mutation은 수정을 요청하는 구문이다.

Mutation: 쿼리들을 추가 할 수도 삭제 할 수도 있다.

subscription: 웹소켓을 사용해 실시간 양방향 통신을 구현할 때 사용한다.

Query는 REST API의 GET, Mutation은 POST,DELETE,PUT,PATCH의 느낌이었다

GraphQL 서버에서는 정적인 타입 시스템을 사용해
데이터를 표현하는 Schema가 존재하고 각 타입의 필드에 대한 함수로 구성된다.
그리고 하나의 EndPoint를 사용함으로써
RESTful API에서 생기는 많은 Enpoint의 복잡성을 줄여줄 수 있다.

---

REST API vs GraphQL

GraphQL API 는 주로 전체 API를 위해서 하나의 Endpoint 를 사용하는 데 반해

REST API 는 Resource 마다 하나의 Endpoint 를 가지고,

그 Endpoint 에서 그 Resource 에 대한 대부분의 것을 담당한다.

REST API

• URL, METHOD등을 조합하기 때문에 다양한 Endpoint가 존재한다

• 특정 기능을 위해 여러번 API가 호출

• 특정 요청에 fit한 응답을 돌려주기 위해서는 API를 새로 만들어야함

• API 유지보수의 어려움

GraphQL

• 단 하나의 Endpoint가 존재

• API에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정

• gql API를 사용하면 여러번 네트워크 호출을 할 필요 없이, 한번의 네트워크 호출로 처리 가능

---

REST API와 GraphQL의 장단점

GraphQL의 장점

1. 오버패치와 언더패치의 단점 해결

1) 원하는 정보에 대한 통제가 가능하다.(= Over-fetching)

2) 한 쿼리에 내가 정확하게 원하는 정보만 받을 수 있다.(= Under-fetching)

2. HTTP 요청의 횟수와 응답의 사이즈를 줄일 수 있다.

원하는 정보를 하나의 쿼리에 모두 담아 요청한다던지, 필요한 정보만 부분적으로 요청이 가능하다.

프론트 엔드 개발자인 나로서는 원하는 데이터만 정확하게 받아올 수 있기에 편하고

백엔드의 입장에서는 좀 더 수월하게 API를 만들 수 있어 보인다.

오버패치와 언더패치란

Over-fetching : 내가 요청한 영역의 정보보다 더 많은 정보를 서버에서 받는다.

즉, 쓸모없는 정보들도 받게된다. 이는 비효율적이고 개발자들이 뭘 받았는지 모르게 된다.

Under-fetching : 어떤 하나를 완성하기위해 다른 요청들을 해야할 때 발생한다.

예를들어 인스타를 만들면 페이지의 피드를 받고 알림도 받고 사용자 프로필도 받게된다.

앱을 처음 시작하려면 이 세가지 요청을 해야 함 ! 즉 3가지 요청이 3번 오고가야 앱이 시작된다는 것이다.

이처럼 REST에서 하나를 완성하려고 많은 소스를 요청하는 것이 Under-fetching이다.

GraphQL의 단점

재귀적인 쿼리가 불가능하다. 결과에 따라 응답의 깊이가 얼마든지 깊어질 수 있는 API를 만들 수 없음

고정된 요청과 응답만 필요한 경우 쿼리로 인해 요청의 크기가 REST API의 경우보다 더 커진다고 한다.

---

REST API의 장점

웹 리소스를 가지고 작업을 진행하는 리소스 중심 아키텍처이기에 웹의 장점을 최대한 활용 가능하다

• HTTP 프로토콜을 사용하므로 REST API 사용을 위한 인프라를 구축할 필요가 없다.
  

• HTTP 표준프로토콜을 따르는 모든 플랫폼에서 호환된다.
  

• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
  

• 서버와 클라이언트의 역할을 명확하게 분리한다.
  

REST API의 단점

• 특정 기능을 위해 여러번 API가 호출 됨
  

• 특정 요청에 fit한 응답을 돌려주기 위해서는 API를 새로 만들어야함
  

• API 유지보수의 어려움
  

---

그렇다면 GraphQL만이 최선인가

Redux는 REST API를 사용하기 때문에 리소스의 크기가 서버에서 결정된다.
데이터 교환이 복잡하게 이루어지고, 엔드포인트 증가 및 overfetching과
underfetching 등의 문제점을 가지고 있다.

반면에 Apollo Client는 GraphQL을 기반으로 한다.
서버에서는 어떠한 자원을 사용할 수 있는지 정의하고, 클라이언트에서
렌더링에 필요한 데이터를 요청하는 방식이다.
꼭 필요한 데이터 교환이 이루어지기 때문에 매우 깔끔하며 효과적이다.

하지만 두 방법 중 어느 것이 더 좋다고 단정 지어 말하기는 어렵다.
최신 기술을 적용하기 전에 서비스의 방향성 및
개발 환경에 따라 어느 한쪽 또는 양쪽 모두를 사용할 수 있기 때문이다.