Tags
- 전시
- SQL
- 우리에프아이에스
- 여행
- k-디지털트레이닝
- 사진
- 우리fis아카데미
- 해리포터
- fdr-x3000
- 시청
- 17-55
- CS231n
- 카페
- 건담
- 대만여행
- 제주도
- 축복이
- 축복렌즈
- 군산
- ai_엔지니어링
- 대만
- 우리fisa
- 오사카
- 맛집
- Python
- 수요미식회
- 도쿄
- 650d
- 전주
- 글로벌소프트웨어캠퍼스
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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
Recent Posts
300x250
브렌쏭의 Veritas_Garage
GraphQL, 실제로는 REST. 본문
GraphQL은 사실 REST였다.
누가 봐도 다르잖아;; 이미 블로그에 포스팅도 했다고;;
- 분명 다른 구조에 다른 방식처럼 보이는데, 결국 GQL의 역할은 REST로 존재하는 요청과 응답을 번역해서 간결화 시킨 것이었다.
- 그리하여 리졸버라는 것이 필요했던 것이고, GQL을 위한 데코레이터를 따로 추가적으로 사용해 작성했던 것이다.
거... 당황스러운 이야기네
일단 REST는
@Get('/login/google')
@Post('/trash/you')
이런 방식인데, GQL의 경우에는
@Mutation(() => Point)
createPoint(){}
@Query()
대충 이런 느낌이므로, 뭐가 어떻게 된것인지 들어보니, 실제로는 모든 요청을 GET이 아니라 POST로 전송하고, 엔드포인트를 조작해서 받게 된 것이다.
놀랍다!
모든 기존 REST문 뒤에 유지성으로 /graphql을 붙이고서 그것은 포스트로 요청하게 해서 함수화를 성공한 것이다. 천잰가????
GQL의 Query요청도 실제로는 REST POST방식으로 작동하는 것이었다.
기절할 것만 같다.
객체 형식으로 데이터를 보내고, 다시 객체 방식으로 데이터를 받기 때문에, 그 근간이 REST였다면 당연히 post일 수 밖에,.,,..,.,.,.,.따라서 큰 규모의 서비스일 수록 클라이언트 측의 요청이 적어질 수록 서버 부담이 덜어지기 때문에, GQL을 선호하게 된다.
결론
정신나갈것같애
- REST api의 under-fetching 문제를 해결하게 되었고 (원하는 것이 여러개면 요청을 쓸데없이 많이 보내야함)
- 일단 두가지 방식이라 편하게 요청방식을 고민할 필요가 없고
- 무조건 전체 내용을 받는게 아니라 원하는 내용만 골라서 받을 수 있고 (Over-fetching 문제를 해결)
- 항상 연결이 200으로 성공이지만 각각의 객체 내부 데이터는 상태메세지를 지정해서 줄 수 있다
****** 그리고 Postman 을 쓸 수 있다 *******
실제로는 한줄로 잘 써야 한다. 맘대로 줄바꾸고 그러면 안돼.
맨 앞의 query는 그냥 붙는거고, 그 안의 query를 쓰거나 혹은 mutation을 쓰고 그대로 작성하면 된다. 무섭다.
그럼 이제 .....
AXIOS로 GQL요청을 보낼 수 있다
정신 진짜 나갈거 같애
'[Project_하다] > [Project_공부]' 카테고리의 다른 글
검색 프로세스, Search process (2) | 2022.04.19 |
---|---|
ACID, 실패할거면 하지마라 그냥 (0) | 2022.04.19 |
Pagination, 보여줄 건 많은데 화면은 좁고.... (0) | 2022.04.18 |
백엔드, 이미지를 업로드 (0) | 2022.04.14 |
CORS, 웹의 신호등 (0) | 2022.04.12 |
Cloud, 디지털 피안 (0) | 2022.04.11 |
서버 분할, 눈물의 쇼 - 그리고 로그인의 역사 (0) | 2022.04.08 |
Comments