[독서] GraphQL 1강

[전자책] 웹 앱 API 개발을 위한 GraphQL

🚨 해당 영역에 쓴 코멘트는 개인적인 의견입니다.

 

- 클라이언트의 종류는 예전보다 다양해졌는데, 데이터 전송속도는 아직 해결해야할 과제이다.

Graphql이란?

- API를 만들때 사용할 수 있는 쿼리언어이다.

- 쿼리에 대한 데이터를 받을 수 있는 런타임

- graphql 쿼리는 실제로 필요한 데이터만 받도록 작성할 수 있다.

이건 근데 서버쪽에서도 데이터를 넘겨줄수있는 구조를 만들어야하는걸로 알고있다.
graphql 서버에서 설정되지않은 데이터는 조회하지못한다고 알고있음..!

 

- 조회시 쿼리문을 중첩하면 연관된 객체를 응답데이터로 받을수있음

공식문서를 보면 쿼리 사용예시를 확인할 수 있다. 

- 얻으려는 타입에 원치않는 데이터가 포함되어있다면 이를 제외해서 조회가 가능하다.

 

- graphql 서버에서는 쿼리가 실행될때마다 타입 시스템에 기초해 쿼리가 유효한지 검사한다.

- graphql 스키마에서 사용할 타입을 정의해야한다.

 

- graphql은 선언형 데이터 페칭 언어라고 불린다.

선언형이란?
how보다 what! 즉 무엇을 해야하는지에 초점을 맞추면된다

- 무슨 데이터가 필요한지만 명세하고, 어떻게 가져올지에 대해서는 신경쓰지않아도된다.

graphql 명세

- graphql은 클라이언트와 서버간의 통신 명세(스펙)이다.

- 쿼리를 작성할때 사용하는 언어의 문법을 설명한다.

- 타입 시스템 및 타입 시스템의 실행과 유효성 검사를 담당하는 엔진에 대해서도 설명한다.

 

- graphql를 자바스크립트와 쓸때는 graphql.js를 설치해서 쓰면된다.

아...! graphql은 명세일뿐이기때문에,
언어에맞게 graphql을 사용할수있도록 지원하는 라이브러리가 개별적으로 존재한다.
javascript > graphql.js
python > graphene
java > graphql-spring-boot-starter

이렇게 생각하니깐 명세라는 의미가 확 와닿음!!

 

graphql 설계 원칙

1. 위계적

- 필드안에 다른 필드가 중첩될 수 있으며, 쿼리와 그에 대한 반환데이터는 형태가 서로 같다

 

2. 제품 중심적

- 클라이언트가 요구하는 데이터와 클라이언트가 지원하는 언어 및 런타임에 맞춰 동작한다

위에 말했던것처럼 사용하는 언어마다 graphql 라이브러리가 각각 구현되어있음

 

3. 엄격한 타입 제한

- graphql은 graphql타입시스템을 사용한다. 스키마의 데이터 포인트마다 특정 타입이 명시되며, 이를 기초로 유효성검사를 한다.

이게 좀 신기했던게, 쿼리 요청시 클라이언트에 명시한 스키마의 타입 이름과 서버에 정의된 스키마의 타입 이름이 동일하지않으면 아예 쿼리에러를던져버림..!
이 부분이 어떻게 동작하는지는 책을 읽으면서 배워볼예정

 

4. 클라이언트 맞춤 쿼리

- graphql 서버는 클라이언트 쪽에서 받아서 사용할 수 있는 데이터를 제공한다.

이 말은 클라이언트뿐만 아니라 서버도 따로 작업이 필요하다는 의미이다!
그래서 만약 백엔드와 같이 협업하는 상황이라면 graphql 서버에서 클라이언트로 어떤 데이터를 보낼지에 대한 협의가 필요하지않을까?

5. 인트로스펙티브

- graphql 언어를 사용해 graphql 서버가 사용하는 타입 시트템에 대한 쿼리를 작성할 

 

데이터 전송의 역사

1. RPC

- 1960년. 원격 프로시저 호출

- 클라이언트에서 원격 컴퓨터로 요청 메시지를 보내 무언가를 하도록 만든다. 즉, 클라이언트가 서버로 데이터 요청을 보내고, 서버는 응답을 돌려준다.

2. SOAP

- 1990 후반. 단순 객체 접근 프로토콜

- XML을 사용해 메시지를 인코딩하고 HTTP를 사용해 전송한다.

- 타입시스템도 사용하고 리소스중심의 데이터 호출이라는 개념도 도입되었음

3. REST

- 사용자가 GET, POST, PUT, DELETE 메서드를 실행해서 웹 리소스를 가지고 작업을 진행하는 리소스 중심의 아키텍처

- RESTful  아키텍처에서 라우트는 정보를 나타내는 개념이다.

  예시:  /api/food/hot-dog

- REST를 사용하면 데이터 모델의 엔드포인트를 다양하게 만들 수 있다.

- REST는 초반에는 XML포맷을 사용했고, 이 포맷은 데이터를 사용할때 XML포맷을 파싱해야했는데, 얼마 지나지않아 JSON 포맷을 사용하게되었다고함.

- JSON은 특정 언어에 구애받지않고, 다양한 언어에서 파싱하고 사용할 수 있는 데이터 포맷이다!

REST의 단점

많은 기술이 그렇듯, 무언가가 새로 만들어질때는 기존에 사용하던 것이나, 현 상황이 불편하기때문일것이다.
graphql이 등장하게된 이유를 아래에 적어볼건데, 일을 하면서도 경험을 했던 포인트라서 아주 공감이 되었음.

1. 오버페칭

- 특정 API를 만들때는 클라이언트에서 필요한 정보보다 많이 보내주는경우가 있다. 즉, 필요하지 않은 데이터를 받아오게됨.

나는 주로 유저정보를 받아올때 오버페칭이 많이 발생한다고 느꼈다.
여러 컴포넌트에서 유저의 정보를 보여줘야할때는 유저정보를 받아오는 API를 재사용하는데,
컴포넌트별로 필요한 유저데이터의 개수가 다른데도 항상 많이 받아왔엇는데, 이런경우는 graphql을 도입하게되면 너무좋을것같다!!

- graphql을 사용해 필요한 필드만 받아오게되면 불필요한 데이터를 가져오지않아도되고, 응답 속도 역시 빨라질 여지가 있다.

2. 언더페칭

- 특정 데이터를 요청하고, 받아온 데이터를 사용해 추가 데이터를 요청하는것.

- 만약 언더페칭해야할 데이터가 많아질때는 클라이언트에서 각각의 HTTP 요청이 클라이언트 리소스를 사용하게되고, 또 그 와중에 데이터를 과도하게 가져오게된다.

- 이는 사용자의 체감속도를 느리게만들고, 네트워크나 기기의 속도가 느리면 콘텐츠를 아예 못 볼 가능성도 있음.

- graphql을 사용해서 쿼리를 중첩으로 정의해 페치 한번에 필요한 모든 데이터를 요청해서 언더페칭문제를 해결할 수 있다.

이 방식은 내가 실무에서 자주 사용했는데, 언더페칭이라는 이름을 가지고있는지는 처음알게되었음.
와 근데 코드예시를 보니 진짜 효율적이라는 생각이 들었다.
rest방식을 사용했을땐, api의 역할을 명확히하기위해서
특정정보 받아오기 > 그 정보를 사용해 다른 세부정보 받아오기
이런 방식으로 구현한 경우가 있었는데, graphql은 이런 문제를 한번에 해결해주는 느낌!

3. REST 엔드포인트 관리

- REST API에 대한 불만중 하나는 유연성이 부족하다는것이다. 클라이언트에 변경사항이 생기면 대개 엔드포인트를 새로 만들어야하는데, 이렇게 되면 엔드포인트의 개수가 빠르게 증가한다.

이것도 정말 공감을 하는게,
api response구조가 수정되어야하는 경우엔 api이름뒤에 v2를 붙여서 새로 만들거나 아예 다른 이름의 api를 만들었는데,
그럴때마다 백엔드개발자분이 네이밍때문에 고민하시는것을 많이봤다.

- graphql을 사용하면 설계상 엔드포인트가 보통 하나로 끝나게된다. 단일 엔드포인트가 게이트웨이로써 데이터 체계가 손쉽게 관리된다.

graphql 클라이언트

- graphql은 명세에 불과하고, 각자의 개발환경에 독립적이다!

- 그래서 실제로 개발을 할때는 graphql을 손쉽게 사용할수있게해주는 툴을 사용하게된다. 그게바로 graphql 클라이언트!

- graphql 클라이언트의 목적은 개발자가 빠르게 작업할수있는 환경을 만들어주고, 애플리케이션의 성능과 효율성을 끌어올리는것이다.

- 네트워크 요청, 데이터 캐싱, 사용자 화면에 데이터 주입 등의 일을 담당한다.

- relay, @apollo/client 등이 있다.

apollo studio를 통해 graphql server에 설정된 쿼리, 뮤테이션, 타입 등을 쉽게 확인할 수 있다.