GraphQL, 실제로는 REST.

GraphQL은 사실 REST였다.

---

대체 그게 뭔 소리야..

누가 봐도 다르잖아;; 이미 블로그에 포스팅도 했다고;;

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요청을 보낼 수 있다

정신 진짜 나갈거 같애

아아아아아아악 개쩔어어어어엉억