티스토리 뷰
GraphQL 이란
API를 만들 때 사용할 수 있는 쿼리 언어, 쿼리에 대한 데이터를 받을 수 있는 런타임이기도 하다.
GraphQL 쿼리는 사용자가 필요한 데이터만 받도록 작성할 수 있다.
쿼리문을 중첩하여 다양한 객체를 응답 데이터로 받아올 수 있고, 하나의 요청으로 두 가지 데이터 타입에 대한 응답을 얻어낼 수 있다.
마찬가지로 원하지 않는 데이터에 대해서는 제외하여 요청을 보낼 수 있다.
GraphQLdms 선언형(declarative) 데이터 페칭(fetching)라고 불린다. 어떤 데이터를 불러올 것인지, 요구사항만 작성하면 되고, 어떻게 데이터를 가져올 것인지는 신경 쓰지 않아도 된다.
GraphQL의 서버 라이브러리는 다양한언어로 만들어져 있기 때문에 유연한 사용성을 보인다.
GraphQL의 설계원칙
위계적
필드 안에 다른 필드가 중첩될 수 있으며, 쿼리와 그에 대한 반환 데이터는 형태가 서로 같다.
제품 중심적
클라이언트 강 요구하는 데이터와 클라이언트가 지원하는 언어와 런타임에 맞춰 데이터를 제공한다.
엄격한 타입 제한
타입 시스템을 중시하며, 스키마의 데이터 포인트마다 특정 타입으로 명시되며, 이를 토대로 쿼리 호출 시 유효성 검사를 실시한다.
클라이언트 맞춤 쿼리
클라이언트에서 받아서 사용할 수 있는 데이터를 제공한다.
인트로 스펙 티브(introspective)
GraphQL언어를 통해 GraphQL 서버가 사용하는 타입 시스템에 대한 쿼리 시스템을 작성할 수 있다.
데이터 전송의 역사
RPC
1960년에 RPC(Remote Procedure Call)가 발명되었다. RPC는 클라이언트에서 원격 컴퓨터로 요청 메시지를 보내 작업을 실시하도록하고, 원격 컴퓨터는 응답 메시지를 보낸다. 당시의 서버-클라이언트는 지금의 컴퓨터와는 다른 개념이지만, 현재 서버-클라이언트의 정보 전달 방식과 동일한 방식을 사용하고 있다고 한다.
SOAP
1990년 MS사에서 SOAP(Simple Object Access Protocole)을 만들었다. SOAP는 XML을 사용해 메세지를 전송하고 HTTP를 사용해 전송한다. SOAP에서 타입 시스템을 사용하고 리소스 중심의 데이터 호출이라는 개념을 사용하였다. SOAP의 경우 결과 값을 예측하기에는 쉽지만, 구현하기 복잡하다는 단점을 가지고 있었다.
REST
아마 현재 가장 익수 한 데이터 요청 방식이 아닐까.
사용자가 GET, PUT, POST, DELETE와 같은 행동을 수행해서 웹 리소스를 가지고 작업을 진행하는 리소스 중심의 아키텍처에 대한 내용.
리소스 네트워크는 가상 상태 머신이고, 위의 GET, PUT, POST, DELETE와 같은 행동은 머신 내 상태를 변경한다.
RESTful 한 아키텍처에서는 라우트 정보를 나타내는 개념이다. 각각의 라우트를 통해 정보를 요청하게 되면 그에 따른 응답을 받을 수 있는 구조이다.
REST를 사용하면 다양한 엔드포인트를 만들 수 있고, 이전의 아키텍처들보다 그 방법이 쉽다. 기존에는 Ajax요청으로 XML 형식을 사용했지만 XML응답을 파싱 하는 수고를 덜기 위해, 이후에는 JSON이라는 데이터 포맷을 사용하게 되었다.
REST의 단점
오버 패칭(Overfetching)
필요하지 않은 데이터를 불러온다. 엔드포인트 내에 전달받는 데이터는 고정되어있기 때문에 정작 필요한 데이터보다 더 많은 데이터가 담긴 응답 데이터가 전달될 수 있다.
언더 패칭(Underfetching)
원하는 데이터가 불충분하다. 마찬가지로 엔드포인트에서 제공하는 데이터를 제외하고 추가로 데이터를 받아와야 하는 상황이 발생할 수 있다.
그리고 기존 REST에서 커스텀 엔드포인트를 관리하는 부분에서도 불편함이 있다. 새로운 엔드포인트를 만들기 위해서는 백엔드/ 프런트 엔드 모두 계획하고 의사소통하는 데에 참여하여 시간이 많이 걸려 개발 속도가 늦어질 수 있다.
GraphQL을 사용하면 설계상 엔드포인트가 하나로 끝난다. 단일 엔드포인트가 게이트웨이로써 몇 가지 데이터 소스를 조율하는 역할을 하고 데이터 체계 역시 손쉽게 관리된다.
GraphQL 클라이언트
Relay
페이스북이 만든 클라이언트로 React, React Native에서 사용할 수 있다. GraphQL 서버에서 데이터를 페칭 하는 용도로 만들어졌다.
아폴로(Apollo)
모든 프런트엔드 플랫폼에서 사용할 수 있고, 어떤 프레임워크에 종속되어있지 않다. GraphQL 서비스를 만들 때 도움 되는 개발 툴이나, 성능 모니터링 툴도 제공한다.
'Books' 카테고리의 다른 글
[GraphQL] 3장 Graph 쿼리어 (0) | 2022.06.04 |
---|---|
[GraphQL] 2장 그래프 이론 (0) | 2022.06.04 |
[Clean Code] #13 동시성 (0) | 2022.05.12 |
[Clean Code ] #12 창발성 (0) | 2022.05.10 |
[Clean Code] #11 시스템 (0) | 2022.05.10 |
- Total
- Today
- Yesterday
- 문제풀이
- reactrouter
- React
- redux
- 상호평가
- 파이썬
- React.memo
- TypeScript
- AxiosInterceptor
- 백준
- Vue.js
- 알고리즘
- bundler
- GraphQL
- 프로그래머스
- webpack
- python
- error
- Transpiler
- redux-thunk
- Vue
- Repository Pattern
- Preloading
- js
- clean code
- v-for
- programmers
- Vuex
- SPA
- SOAP API
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |