사내스터디 - GraphQL 스터디 1주차
📋 범위 1장
*본 글은 발표 대본용이라 상세 정보는 들어가 있지 않습니다.
GraphQL이란?
- API를 만들 때 사용할 수 있는 쿼리 언어
- 쿼리에 대한 데이터를 받을 수 있는 런타임
보통 쿼리 언어라 하면 SQL이 먼저 떠오른다.
SQL과 동일한 쿼리 언어지만, 차이가 있다.
SQL은 데이터베이스 시스템에 저장된 데이터를 효율적으로 가져오는 것이 목적이라면
GraphQL은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적이다.
GraphQL에 대한 특징을 살펴보자.
- 요청 값에 맞게 데이터들이 response되어 원하는 데이터 형태만을 받아올 수 있다.
- HTTP 요청 하나가지고 입맛에 맞게 원하는 타입대로 요청을 진행할 수 있다.
GraphQL은 선언형 데이터 패칭 언어라고 일컫는다.
=> 개발자는 무슨 데이터가 필요한지에 대한 요구사항만 작성하면 되지, 어떻게 가져올지에 대해서는 신경 쓰지 않아도 된다.
GraphQL의 서버 라이브러리는 다양한 언어로 구성할 수 있다. ex) python, js, java, ruby, PHP...
GraphQL은 클라이언트와 서버 간의 통신 명세(스펙)이다.
GraphQL 설계 원칙
1. 위계적
- GraphQL 쿼리는 위계성을 띠고 있다. 필드 안에 다른 필드가 중첩 가능하고, 쿼리와 그에 반환 데이터는 형태가 서로 같다
2. 제품 중심적
- GraphQL은 클라이언트가 요구하는 데이터와 클라이언트가 지원하는 언어 및 런타임에 맞춰 동작한다.
3. 엄격한 타입 제한
- GraphQL 서버는 GraphQL 타입 시스템을 사용한다. 스키마의 데이터 포인트마다 특정 타입이 명시되며, 이를 기초로 유효성 검사를 진행한다.
4. 클라이언트 맞춤 쿼리
- Graph QL 서버는 클라이언트 쪽에서 받아서 사용할 수있는 데이터를 제공한다.
5. 인트로스펙티브
- GraphQL 언어를 사용해 GraphQL 서버가 사용하는 타입 시스템에 대한 쿼리를 작성할 수 있다.
데이터 전송의 역사
1. RPC
- 1960년에 발명
- 이때의 클라이언트와 서버의 정보 전달 방식은 지금과 기본적으로 같다.
(클라이언트가 서버로 데이터 요청을 보내고, 서버는 응답을 들려준다.)
2. SOAP
- 1990년 후반
- XML을 사용해 메시지를 인코딩하고 HTTP를 사용해 전송한다.
- 결과 예측이 쉬우나, 구현하기가 매우 복잡하다
3. REST
- 사용자가 GET, PUT, POST, DELETE와 같은 행동을 수행하여 웹 리소스를 가지고 작업을 진행하는 리소스 중심의 아키텍쳐
- 데이터 모델의 엔드포인트를 다양하게 만들어 데이터 응답 형식을 자유롭게 만들어준다.
/api/food/korea
웹 개발에 엄청난 영향을 끼친 이 REST도 단점이 존재했다.
❓REST의 단점
1. 오버페칭
예를 들어보자. 내가 원하는 것은 사물의 이름이다.
하지만 데이터를 불러보면 사물의 이름 뿐만 아니라 무게, 만들어진 년도, 제작자 등등 필요한 정보이외에 많은 정보들까지 받게된다.
2. 언더페칭
어떤 모집군의 데이터들을 불러와야할때 데이터를 추가적으로 계속 요청해야되는 상황
HTTP 요청을 많이 날려야하고 이로인해 사용자 편의가 저하될 수 있다.
3. 유연성이 부족하다.
클라이언트에 변경 사항이 생기면 대개 엔드포인트를 새로 만들어야 한다.
이 단점들은 GraphQL을 써야하는 이유로 다가온다.
1. 오버페칭 문제
GraphQL은 앞서 말했던것처럼 원하는 데이터만 받아볼 수 있다.
요청에 데이터 형태를 정의하고 해당되는 데이터만 받아온다. 이는 응답 속도가 빨라지는 장점도 가지고 있다.
2. 언더페칭 문제
GraphQL을 사용하면 쿼리를 중첩으로 정의해서 패치 한 번에 필요한 모든 데이터를 받아올 수 있다.
이는 당연히 HTTP요청을 줄일 수 있다.
3. 유연성 문제
GraphQL을 사용하면 보통 엔드포인트는 하나로 끝나게 된다.
단일 엔드포인트로 여러가지 데이터 소스를 조율할 수 있다.
GraphQL을 선택하는 것은 더 나은 선택지가 될 수도 있다.
개발자가 빠르게 작업할 수 있는 환경을 만들어주고 애플리케이션 성능과 효율성을 끌어올려 준다.
주요 프론트엔드 개발 플랫폼에서 사용될 수 있고, 프레임워크에 종속적이지 않다.
또한, GraphQL 커뮤니티 생태계는 크고 계속 발전해나아가고 있으며 GraphQL 명세는 꽤나 안정적이다.
💁♂️ 정리
보통 쿼리 언어라면 프론트엔드는 사용할 일이 거의 없을거라 생각했다.
하지만, 백엔드에서만이 아닌 프론트엔드에서도 쓰이는 쿼리언어라는 점이 흥미를 자극했다.
GraphQL에 대해 가끔씩 접한 적이 있는데, 이번에 좋은 기회로 사내에서 GraphQL 스터디를 시작하게 되었다.
실무에서도 실제로 도입해볼만한 기술이라서 잘 배워두고 필요한 시점이 왔을때 도전을 해보고 싶다.
1장의 내용만을 읽어봤을때, 느껴지는건 확실히 획기적인 언어라 생각이 든다.
특히, 요청하는 쿼리문의 구조대로 응답이 온다는 것이 눈길을 끈다.
실무에서 API를 호출하여 사용할때, 나는 A만 필요한데 덩달아 B, C, D... 까지 오는 경우들이 더러 있기 때문이다.
그렇다고 API를 수정하자니, 그러면 API 개수가 더 늘게되어 보통은 보내진 데이터에서 데이터를 찾아 사용하는 경우들이 대부분일 것이다.
이러한 점에서 GraphQL은 장점이 분명한 것 같다.
하지만, 장점에 대한 내용만 기술되어 있고 아직 이 기술이 지니고 있는 단점에 대해서는 학습하지 못하였으므로,
너무 색안경끼고 바라보지 않고 계속해서 학습해 나아가봐야겠다.
📌 참고