- 축복이
- ai_엔지니어링
- 수요미식회
- 도쿄
- Python
- 시청
- fdr-x3000
- 축복렌즈
- 해리포터
- 여행
- 군산
- 우리fisa
- 전주
- 17-55
- CS231n
- 글로벌소프트웨어캠퍼스
- 사진
- 전시
- 건담
- 오사카
- 우리fis아카데미
- 맛집
- 제주도
- 대만
- 대만여행
- SQL
- 650d
- k-디지털트레이닝
- 카페
- 우리에프아이에스
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Today
- Total
브렌쏭의 Veritas_Garage
GraphQL은 뭔가? 그리고 REST와 비교. 본문
GraphQL ??? 그래프 수식 작성용인가??
이름에 QL 이라는 단어가 들어가는 것을 보면, SQL 형식을 가지는 놈 같다. 즉, 쿼리기반 언어이다. 엑셀처럼 키와 밸류를 가진 여러 데이터를 처리하고, 그 데이터들은 서로 링크가 되어 위치를 참조하고, 뭐 그런거. 그러나 기존의 SQL 문법보다 GQL의 문법은 좀 더 다르다.
sql의 문장(statement)은 주로 백앤드 시스템에서 작성하고 호출 하는 반면,
gql의 문장은 주로 클라이언트 시스템에서 작성하고 호출 합니다
- 카카오 Tech Blog -
- sql은 데이터베이스 시스템에 저장된 데이터를 효율적으로 가져오는 것이 목적이고, DB기준으로 글을 써야한다
- gql은 웹 클라이언트가 데이터를 서버로 부터 효율적으로 가져오는 것이 목적, 클라이언트가 뭘 바라는지에 초점을 맞춘다.
REST랑 뭐가 다릅니까 그래서?
그래서 JSON을 통으로 받아야하는 REST와 달리 GQL은 클라이언트가 필요한 것만 골라서 가져오는 함수 형태를 가진다. 그리고 엔드포인트가 하나라고 한다.
REST에서는 조회만 한다고 하더라도 app.get('/posts', ) app.get('/comments', ) app.get('/authors', ) 으로 3번 요청하고 3번 응답하는 과정이 필요하다. 그에 반해 GQL에서는 여러 api를 한번의 통신으로 가져올 수 있다. 신기하네
그리고 들어오는 정보도 꽤 다르다. 위 이미지에서 REST는 3종류의 JSON을 가져올것이다. 그러나 GQL의 경우 딱 1회 통신하기 때문에, 자체적으로 데이터를 정리해서 하나의 JSON으로 퉁쳐서 보내주게 된다. (그래서 필수적으로 백엔드단에 리졸버라는 것을 만들어 줘야 한다)
오 괜찮네요, 땡기기 어렵습니까?
요청 작성도 매우 간단하다. REST는 CRUD방식으로 기본 4개, 거기에 추가적인 요소를 합치면 요청 종류가 으마으마하다.
POSTMAN을 끼고 사는 이유
GQL은 단순하다.
- Query : 데이터 좀 보여줍쇼.
- Mutation : 데이터 좀 조작할게요.
깔끔하게 2개다. 그뿐이다. 그리고 URL작성도 필요 없다. 위에서 말했듯이 엔드포인트는 무조건 하나라서. 무지성으로 원하는 것만 요청하면 원하는 것만 돌려준다.
query{
API이름(보내줘야할파라미터: 값){
원하는것이름
원하는것이름2
}
}
mutation{
API이름(보내줘야할파라미터: 값, 바꾸고싶은파라미터: 값){
원하는응답
원하는응답2
}
}
쿼리 + 오퍼레이션 네임 쿼리
함수,함수.. 함수스럽다 라고 위에서 몇번 말했는데, 오퍼레이션 덕에 그렇다. 쿼리요청에 변수를 선언하고 써먹을 수 있다! 보통 API를 써서 정보를 불러올때 id 값이나, 다른 인자 값을 가지고 데이터를 요청할 것이다. 그럴때 편하다.
query 클라이언트가짓는이름(변수A: 값A, 변수B: 값B){
api이름(필요한파라미터: 변수A) {
알고싶은값이름
알고싶은값이름2
알고싶은값이름3
}
api이름2(필요한파라미터: 값, 필요한파라미터: 변수B){
알고싶은값이름
알고싶은값이름2
}
api이름3 {
알고싶은값이름
}
}
이런 방식이다.
그럼 반대로 API 만들기는 어떻나요
누가 돈을 버는가. 누가 귀찮은 일을 대신 해주는 사람이 귀찮은 만큼 돈을 버는 세상이다. 세상의 누군가가 10배 편해졌다면, 그 세상의 다른 누군가는 반드시 10배 귀찮아지게 되어있다. '귀찮음 보존의 법칙'
REST 보다는 좀더 할일이 있다. 일단 각 개별 데이터들을 따로 접근할 수 있게 DB 내 데이터들의 타입을 확인해서 작성해준다.
type 데이터 {
데이터요소: 타입(number, string ..etc)
데이터요소: 타입
데이터요소: 타입
}
여타 작업을 하고 나면 리졸버를 만들어줘야한다. 데이터들을 뭉탱이로 그냥 쏘는게 아니라 클라이언트가 원하는 것만 집어서 재조합 시켜 보내줘야 하기 때문이다.
const resolvers = {
Query: {
데이터이름: (parent, args) => {
// working with DB or call different API, ...
const 결과 = {
데이터요소: 데이터값,
};
return 결과;
},
데이터이름2: (parent, args) => ({ 배열형태데이터요소: 값, ... }),
},
};
윽 귀찮아
하여튼 이런 저런 리졸버까지 만들었다면 끝났다. 사실상 여러 엔드포인트에서 오는 값들을 리졸버가 모아서 정리해주는 함수이기 때문에 이 뒤로는 JSON덩어리가 된 데이터와 랜선의 영역이다.
어.. 지원문서는?
귀찮은 일을 미래로부터 당겨서 했기 때문에, 귀찮음보존법칙에 따라, 지원문서는 자동으로 생성할 수 있다. 개꿀.
'[Project_하다] > [Project_공부]' 카테고리의 다른 글
타입스크립트, MS의 모빌슈츠는 괴물인가? (0) | 2022.03.22 |
---|---|
자바스크립트, Array.prototype.sort() (0) | 2022.03.21 |
문자열 조작: String.Methods[Day06] (0) | 2022.03.21 |
TIL20220317 #Express #restAPI (0) | 2022.03.17 |
유용한 JS, Template Literal & ..Callback....? (0) | 2022.03.17 |
JS 배열과 객체 복사하기 (0) | 2022.03.16 |
HTTP Request / Response (0) | 2022.03.16 |