왜 Graph를 사용하는가?
페이스북이나 인스타 같은 곳에서도 팔로잉 팔로워 관계는 그래프 자료구조로 활용된다고 한다.
query getMovie($id: Int!) {
movie(id: $id) {
id
title
medium_cover_image
language
rating
description_intro
isLiked @client
}이렇게 query를 날리면 트리 구조의 JSON 형태로 응답을 받을 수 있다.
REST API의 문제점
GraphQL이 등장하기 전까지는 거의 REST로 개발할 수 밖에 없었다.
만약 /api/korea/students 이런식으로 엔드포인트가 지정됐다고 했을 때
이후 변경되어야 할 사항이 있을 경우 프론트랑 백에다 다 바꿔줘야 하는 불편함이 있다.
그리고 또 다른 단점이 있는데 한번 API를 호출했을 때 필요없는 정보까지 다 날아오게 된다.
이를 Over-Fetching이라 한다.
그리고 원하는 정보를 충분히 받지 못했을 경우를 Under-Fetching이라 하는데,
Underfetching generally means that a specific endpoint doesn’t provide enough of the required information.
공식문서에서도 이렇게 설명하고 있다. 간략하게 번역해보자면, 특정 엔드포인트가 요구 정보를 충분히 제공하지 못하는 경우이다.
GraphQL이 위 2가지 경우를 해결해주기는 하지만, 분명히 단점은 존재한다.
- 러닝커브가 높음
- 캐싱 작업이 REST API보다 복잡함
- 고정된 요청과 응답만 필요할 경우에는 REST API보다 크기가 커진다.
음...첫번째는 내가 GraphQL을 어느정도 다뤄본 결과 그리 쉽지만은 않았던 거 같고 2,3번째는 솔직히 잘 안 와닿는다...팀프로젝트에 써먹어봐야 알려나 싶기도 하다.
구조
GraphQL 구조에서는 Query, Mutation, Subscription 키워드가 존재한다.
Query
DB 안에 저장된 데이터를 가져오는 작업으로 REST에서 GET과 비슷하다.
Mutation
데이터를 추가,삭제,수정 등을 하는 작업으로 로그인,회원 가입,블로그 포스팅 등의 경우가 다 Mutation이다.
Subscription
WebSocket과 비슷한 느낌으로, 서버에서 이벤트가 발생할 때마다 그것을 실시간으로 읽어들인다.
그래서 Subscription이라는 단어를 쓴 거 같다.
그리고 Subscription을 할 때 필요 조건 중 하나는 PubSub(publish-subscribe engine) class가 있어야 한다.
하지만 실제 배포 환경에서는 권장되지 않는다고 한다. 대신에 PubSub libraries를 사용하라고 권장한다.
참고자료
https://uzihoon.com/post/82746960-ed3c-11eb-a1b6-81da1e62e780
https://www.howtographql.com/basics/1-graphql-is-the-better-rest/
https://www.apollographql.com/docs/apollo-server/data/subscriptions/
https://www.apollographql.com/docs/apollo-server/data/subscriptions/#production-pubsub-libraries
