일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- sort
- 자료구조
- next/Image
- 정규표현식
- 코드스테이츠
- 배열
- 백준
- OSI 7계층
- 페이지네이션
- nodejs
- javascript
- MUI
- 알고리즘
- 프론트엔드
- primitive type
- 버블정렬
- JavaScript Deep Dive
- 코드스테이츠 메인프로젝트
- 자바스크립트
- input class
- 유데미
- 재귀함수
- 백준 nodeJS
- Node js
- CSS
- 코딩테스트
- react js
- 이벤트 루프
- Native select
- kakao map api
- Today
- Total
신입 개발자에서 시니어 개발자가 되기까지
[section4] GraphQL 본문
1. GraphQL이란?
1.1 개념
- 오픈소스 쿼리언어
- 데이터가 그래프 형태로 연결되어 있다고 전제한다.
- 그래프 자료구조는 클라이언트의 요구에 따라 트리형태의 구조를 가질 수도 있다. 노드와 노드를 간선으로 연결하기만 하면 되니까.
- 다시말해, 클라이언트의 요구에 따라 유연하게 트리 구조를 응답할 수도 있고, 그래프 구조를 응답할 수 있다.
1.2. 특징
- HTTP를 통해 API 서버로 요청을 보낸다.
- 응답은 JSON형식으로 받는다.
- 서버 개발자가 작성한 각 필드에 대응하는 resolver 함수로 각 필드의 데이터를 조회할 수 있다.
- GraphQL 라이브러리가 조회 대상 schema가 유효한지 검사한다.
2. GraphQL vs REST API
2.1. GraphQL이 나오게 된 배경
- REST API의 한계
사용자의 이름, 포스팅 목록, 팔로워 목록만 필요하다고 했을 때 REST API는 필요없는 다른 정보들까지도 가져온다. username 외에도 address, birthday 등등. (overfetch)
또한 포스팅 목록, 팔로워 목록이 필요한데 이를 얻기 위해서는 추가적인 요청을 보내야 한다. REST API에서는 각 자원에 따라 엔드포인트를 구분하기 때문이다.
REST API에서는 자원의 크기와 형태를 서버에서 결정하기 때문에 클라이언트가 필요한 내용이 변할 경우 다른 endpont에서 새로 가져오거나 가져온 데이터를 수정해야한다.
2.2. 차이점
- REST API는 Resource에 대한 형태 정의와 데이터 요청 방법이 연결되어 있지만, GraphQL에서는 Resource에 대한 형태 정의와 데이터 요청이 완전히 분리되어 있습니다.
- REST API는 Resource의 크기와 형태를 서버에서 결정하지만, GraphQL에서는 Resource에 대한 정보만 정의하고, 필요한 크기와 형태는 클라이언트 단에서 요청 시 결정합니다.
- REST API는 URI가 Resource를 나타내고 Method가 작업의 유형을 나타내지만, GraphQL에서는 GraphQL Schema가 Resource를 나타내고 Query, Mutation 타입이 작업의 유형을 나타냅니다.
- REST API는 여러 Resource에 접근하고자 할 때 여러 번의 요청이 필요하지만, GraphQL에서는 한번의 요청에서 여러 Resource에 접근할 수 있습니다.
- REST API에서 각 요청은 해당 엔드포인트에 정의된 핸들링 함수를 호출하여 작업을 처리하지만, GraphQL에서는 요청 받은 각 필드에 대한 resolver를 호출하여 작업을 처리합니다.
Resolver란?
GraphQL에서 데이터를 가져오는 구체적인 과정을 담당하는 함수. 각 필드마다 이 함수가 하나씩 존재한다. 만약 필드가 스칼라 값(문자열이나 숫자와 같은 primitive타입)인 경우에는 실행이 종료된다. 그러나 필드의 타입이 스칼라 타입이 아닌 타입이라면 해당 타입의 리졸버를 호출한다.
연쇄적인 리졸버 호출은 DFS로 구현되어 있을 것이다.
-카카오 테크 참고
2.3. GraphQL의 장단점
2.3.1. 장점
- 하나의 endpoint 요청. 모든 요청은 POST 메서드를 사용한다.
- underfetching이나 overfetching이 없다.
- playground라는 GUI로 resolver와 schema를 한눈에 볼 수 있다.
- 클라이언트 구조 변경에도 지장이 없다.
- REST AP는 백엔드 프로그래머가 작성한 API의 request / response 형식에 의존적이지만, GQL을 사용한 방식에서는 이런 의존도가 많이 사라진다.
2.3.2. 단점
- 학습에 시간이 필요하다.
- 캐싱이 복잡하다.
- 고정된 요청과 응답만 필요한 경우에는 Query로 인해 REST API 보다 요청의 크기가 더 크다.
3. GraphQL의 구조
-Query는 read, Mutation은 Create,Update,Delete 개념으로 보면 된다.
• Query: 저장된 데이터 가져오기 (REST의 GET과 비슷)
• Mutation: 저장된 데이터 수정하기
- Create: 새로운 데이터 생성
- Update: 기존의 데이터 수정
- Delete: 기존의 데이터 삭제
• Subscription: 특정 이벤트가 발생 시 서버가 대응하는 데이터를 실시간으로 클라이언트에게 전송
4. 객체 타입과 필드
type Character {
name: String!
appearsIn: [Episode!]!
}
• Character : GraphQL 객체 타입. 필드가 있는 타입이라는 의미.
• name, apperaIn : Character 타입의 필드.
• 스칼라 타입 : string, number와 같은 primitive 타입.(string은 스칼라 타입이다)
• ! : 필드가 non-nullable임을 의미한다. 값이 꼭 있어야 한다는 뜻.
• [Episode] : Episode 객체의 배열(array)를 의미한다.
- 대괄호([])는 배열을 의미한다.
5. 쿼리
5.1 일반 쿼리(static)
{
human(id: "1000") {
name
height
}
}
root 객체에서 시작해서 human 필드를 선택하고, human에 의해 반환된 객체에 대해 name과 height 필드를 선택한 것을 의미한다.
5.2 오퍼레이션 네임 쿼리(dynamic)
-정보를 불러올 때 id값이나, 다른 인자값으로 데이터를 불러올 때 사용한다.
query HeroNameAndFriends($episode: Episode) {
hero(episode: $episode) {
name
friends {
name
}
}
}
$episode는 변수가 들어갈 자리다. 이 변수에 따라서 원하는 데이터를 불러올 수 있다.
'코드스테이츠 > section4' 카테고리의 다른 글
[section4] 웹사이트 최적화하기 (0) | 2022.12.05 |
---|---|
[section4] 웹사이트 최적화(코드 분할, lazy import) (0) | 2022.11.29 |
React Virtual DOM (0) | 2022.11.28 |
[Section4] Webpack 번들링, 배포(feat. css, image loader) (0) | 2022.11.24 |