GraphQL | A query language for your API
Evolve your APIwithout versions Add new fields and types to your GraphQL API without impacting existing queries. Aging fields can be deprecated and hidden from tools. By using a single evolving version, GraphQL APIs give apps continuous access to new featu
graphql.org
⭐ GraphQL을 시작하면서
처음에 GraphQL을 말로만 많이 들었지 잘 몰랐었는데 이번 사이드 프로젝트를 하면서 백엔드분이 GraphQL 도입하자고 하셔서 이 기회에 GraphQL에 대해서 공부해보았다. 원래는 FN 개발자 입장으로써 GraphQL에 API 연동해주는 Apollo만 사용해보려 했으나 API를 직접 만들어보는 것도 좋은 경험이니 도전해봤다. GraphQL을 단번에 이해시켜주는데 도움이 컸던 노마드코더 니꼴라스님의 영상을 보며 GraphQL API를 직접 따라 구현해보니 정말 매력적이라고 느꼈다. 👀
nomadcoders.co/graphql-for-beginners/lobby
이 영상보면서 영화 REST API를 GraphQL API로 감싸는 작업(Wrappering)까지 수월하게 할 수 있었다.
⭐ GraphQL이란 ?
GraphQL은 페이스북에서 만든 API를 위한 쿼리 언어이다. 그리고 GraphQL이 REST보다 API 만드는 것에 훨씬 더 간편하다. 그만큼 백엔드 개발을 쉽게 만들어 준다. GraphQL API를 만들기 위해서는 node와 자바스크립트 백엔드에 익숙해야 한다.
⭐️ GraphQL API의 장점
GraphQL은 번거로운 오버패치와 언더패치의 단점들을 해결해준다. 즉, GraphQL은 Over-fetching 없이 코드를 짤 수 있고 개발자가 어떤 정보를 원하는지에 대해 통제할 수도 있다. 그리고 Under-fetching을 겪을 필요도 없다. 한 쿼리에 내가 정확하게 원하는 정보만 받을 수 있다. 백엔드 개발자는 API 만들기에 쉽고 프론트엔드 개발자는 구체적이고 정확하게 받아오고 싶은 데이터들만 뽑아 써먹을 수 있음으로 백엔드와 프론트 개발자 모두에게 편리한 라이브러리 인 듯.
- Over-fetching : 내가 요청한 영역의 정보보다 더 많은 정보를 서버에서 받는다. 즉, 쓸모없는 정보들도 받게된다. 이는 비효율적이고 개발자들이 뭘 받았는지 모르게 된다.
- Under-fetching : 어떤 하나를 완성하기위해 다른 요청들을 해야할 때 발생한다. 예를들어 인스타를 만들면 페이지의 피드를 받고 알림도 받고 사용자 프로필도 받게된다. 앱을 처음 시작하려면 이 세가지 요청을 해야 함 ! 즉 3가지 요청이 3번 오고가야 앱이 시작된다는 것이다. 이처럼 REST에서 하나를 완성하려고 많은 소스를 요청하는 것이 Under-fetching이다.
⭐️ GraphQL 구조
- Query (쿼리 = 데이터)
- Mutation (변형)
- Subscription (설명)
Query 는 객체 구조로 표현한다. Query는 읽기를 요청하는 구문이고 Mutation은 수정을 요청하는 구문이다. Mutation을 통해 쿼리들을 추가 할 수도 삭제 할 수도 있다. GraphQL 서버에서는 정적인 타입 시스템을 사용해 데이터를 표현하는 Schema가 존재하고, 각 타입의 필드에 대한 함수로 구성된다. 그리고 하나의 EndPoint를 사용함으로써 RESTful API에서 생기는 많은 Enpoint의 복잡성을 줄여줄 수 있다. 이참에 RESTful API와 GraphQL API를 비교해보자
-
RESTful API
- Resource마다 Endpoint를 갖게 된다.
- 클라이언트마다 필요한 데이터를 각 Resource 종류별로 요청해야 한다. (요청 횟수가 늘어날 수 있음)
- Endpoint가 늘어날 수록 관리하기 힘들어진다.
- 요청과 응답 구조가 미리 정의되어 있다. 때문에 HTTP에 대한 Caching이 가능한 것이 장점이다.
-
GraphQL
- HTTP 요청의 횟수를 줄일 수 있다. (원하는 정보를 하나의 쿼리에 모두 담아 요청 가능)
- HTTP 응답의 사이즈를 줄일 수 있다. (필요한 정보만 부분적으로 요청가능)
이처럼 GraphQL은 REST API의 단점들을 보완해주는 역할을 하고 있는데 단점 또한 물론 갖고있다.
⭐ GraphQL의 단점
- 재귀적인 쿼리가 불가능하다. 결과에 따라 응답의 깊이가 얼마든지 깊어질 수 있는 API를 만들 수 없음
- 고정된 요청과 응답만 필요한 경우 쿼리로 인해 요청의 크기가 REST API의 경우보다 더 커진다고 한다.
단점에 대한 정보 출처(velog.io/@djaxornwkd12/REST-API-vs-GraphQL-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0)
⭐ GraphQL API 생성하는데 필요한 것
백엔드가 기존에 API를 만들기 위해서는 장고나 express를 사용하며 데이터를 받아오기까지 각종 프레임워크를 사용하고 작업시간이 오래걸린다고 하는데 그에 비해 GraphQL은 정말 간단명료하게 만들 수 있다. 바로 이 4개의 파일들만 있으면 가능하다.
- index
- schema
- resolvers
- db
- index
가장먼저 해줘야 될 것이 index 작업이다. graphql 세팅해주는 작업이고, 먼저 graphql-yoga 패키지를 설치해줘야 한다. 이걸 설치하는 이유는 그래프큐엘 요가에서 제공해주는 플레이그라운드로 데이터들을 불러오기 때문이다. 그리고 서버명과 resolver를 불러오고 서버가 실행되면 커맨드창에 표시되게 해주자
- 스키마 [schema.graphql]
이제 스키마를 짜줘야한다. graphql은 정적인 타입 시스템을 사용해 데이터를 표현한다. 스키마 Movie에 들어갈 데이터들의 타입들을 정의해주는데, 여기서 쓰인 ! 느낌표는 서비스가 항상 값을 제공하겠다는 약속이다. 그리고 스키마를 짜주면서 동시에 resolvers도 같이 해줘야 한다.
- [resolvers.js]
resolvers란?
Query를 해결해준다는 뜻이다. Query는 우리가 가진 데이터베이스에 문제같은 것이다. 그래서 우린 이 Query를 어떤 방식으로 해결(resolve)해야 한다. GraphQL에선 views나 urls같은건 없다. 오직 Query랑 resolvers만 있을 뿐이다. 그리고 resolvers를 내 원하는대로 프로그래밍 할 수 있다. DB로 갈 수도 있고 메모리로도 갈 수 있고 다른 API로도 갈 수 있다. 내 맘대로 가능하다 🙂
왼쪽 resolvers, 오른쪽 schema 데이터
- [db.js] 데이터베이스 관리하는 파일
json 파일로 만들어진 영화 REST API를 graphQL로 랩핑 (wrapping) 해주는 과정이다. 이렇게 하고 http://localhost:4000/ 에 접속하면 GraphQL 플레이그라운드가 나온다.
이처럼 플레이그라운드에서 쿼리로 movies 객체 안에 들어있는 데이터값들을 볼 수 있으며 mutations로 변형시킬 수도 있는 것을 DOCS에서 확인해볼 수 있다. Mutations으로 데이터를 추가할수도, 삭제도 가능하다.