수업을 마치고 GraphQL이 정말 좋아보이고 혁신적인것 같았다. 그래서 단점은 없을까?라는 생각을 하게되어 장단점을 찾아보았다.
단 한 개의 Endpoint를 지님으로써, API나 View를 따로 구성할 필요가 없어진다.
요청을 보낼때는 정해진 한 군데로만 요청을 보내면 되고, 그 외의 API를 신경쓸 필요가 없어져, 유지보수가 용이해진다.
GraphQL은 한번의 요청으로 원하는 data들을 요청해서 기존에 REST API만을 사용할때 발생하는 Overfetching, Underfetching등의 문제가 발생하지 않는다.
Overfetching
ㄴ 원하는 data 이상의 정보받는 것으로, data의 정제에 리소스가 낭비된다.
Underfetching
ㄴ 원하는 data를 받기 위해 요청을 여러번 보내는 것으로, 네트워크를 통해 여러번 접근을 하여 리소스 낭비된다.
HTTP의 캐싱 전략은 각각 URL에 각자의 정책을 설정하는 방식으로 이루어 지는데, RESTful API는 이를 그대로 사용이 가능하다.
그러나 GraphQL은 하나의 URL로 처리하기에, HTTP에서 제공하는 캐싱 전략을 그대로 사용하는 것은 불가능하다.
따라서 GraphQL만의 캐싱 방법을 제공하게 되는데, 대표적으로는 영속쿼리(persisted query), 아폴로엔진(Apollo Engine)등이 있다.
GraphQL은 클라이언트가 필요한 데이터를 스스로 결정하여 요청하게 된다.
따라서 GraphQL의 다양한 요청형태에서 잘못된 요청을 필터링하기가 까다롭다.
graphql 수업이 종료되었다. 수업을 들으면서 이 graphQL을 어떻게 client가 사용할 수 있게 하는지 궁금했다. 마침 다음강의에서 방법을 알려준다하여 들을 예정이다.