endpoint란?
→ API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL 입니다.
graphql이 없던 시절 즉, rest-api를 사용하던 시점의 가장 큰 문제점은 너무 많은 endpoint가 만들어진다는 점 이었습니다.
rest-api 에서는 post, get, put, delete, update 방식만해도 이미 endpoint가 5개가 생성되기 때문에 이외의 endpoint를 추가하게 되면 상당히 많은양의 endpoint가 생기게 됩니다.
언더페칭과 오버페칭
오버페칭
오버페칭은 클라이언트가 필요로하지 않는 추가 데이터까지 서버로부터 받아오는 상황을 뜻합니다
예를 들어, 사용자의 주소만 받아오고 싶을 때, "/users" 엔드포인트에 요청을 해 데이터를 받아온다고 가정하면 서버는 사용자의 주소뿐만 아니라 게시물, 이름, 이메일 등 추가 정보도 함께 모두 받아오게 됩니다.
이러한 과정에서, 불필요한 데이터를 받아오므로 네트워크 사용량과 처리 시간이 낭비되게 됩니다.
언더 페칭
언더페칭은 클라이언트가 필요한 데이터를 한 번의 요청으로 가져올 수 없어 여러 번의 추가 요청이 필요한 상황을 뜻합니다.
rest-api는 endpoint에 body를 넣어 보내기 때문에 하나의 endpoint에 하나의 body만 들어가게 됩니다. 따라서 클라이언트는 필요한 데이터를 한 번의 요청으로 가져올 수 없어 추가 요청이 필요하게 됩니다.
이 경우, 여러 번의 요청이 필요하므로 성능 저하가 발생할 수 있습니다.
graphql과 rest-api의 관계
위와 같은 rest-api의 문제점들을 개선하기 위해 나온 것이 GraphQL 입니다.
GraphQL은 rest-api의 post 방식에서 data를 넣을 수 있음을 이용해 만들어 낸 방식입니다.
graphql은 post방식의 body에 내가 실행시킬 함수의 이름을 적어서 endpoint를 요청합니다.
또한 요청을 보낼때도 하나의 endpoint인 post의 body에 원하는 api함수를 묶음으로 선언해주고 그 안에서 받을 인자들을 선택함으로써 이미 만들어진 함수들 중 매칭 된 함수가 실행되고, 원하는 결과값을 받아 올 수 있게 됩니다.
이렇게 graphql은 endpoint문제와 언더페칭과 오버페칭문제를 모두 해결했습니다.
GraphQL 의 단점
위 사진 처럼 서버에서 받아온 데이터를 캐시에 저장을 하면 이미 받았던 데이터를 백엔드 서버를 다시 통하지 않고 바로 보여줄 수가 있습니다.
하지만 GraphQL 같은 경우 endpoint 주소가 하나기 때문에 어떠한 api든 같은 주소를 써서 어떠한 데이터를 받아왔는지 애매모호해지기 때문에 캐시 저장이 다소 어렵다는 단점이 존재합니다.
