- Under-Fetching / Over-Fetching
- Recoil
1. Under-Fetching / Over-Fetching
GraphQL은 필요한 정보만 골라 받아올 수 있는데, REST-API는 필요한 정보에 도달하기 전까지의 모든 것들만 받아와야한다. 이를 Over-Fetching 이라 부른다.
GraphQL은 한 번에 여러 개의 정보를 묶음 요청할 수 있지만, REST-API는 한 번에 여러 개의 정보를 가져오지 못하고, 한 번에 하나씩만 가져올 수 있다. 이를 Under-Fetching 이라 부른다.
이때까지 사용했던 gql 들의 최상단에 이름을 쓴 부분은 묶음 그룹의 이름이라고 보면 된다.
해당 그룹 내에서 한 번에 여러 개의 정보를 묶음 요청할 수 있다!
REST-API의 Under / Over Fetching 문제점들을 개선한 버전이 바로 GraphQL이다.
GraphQL이 없고 REST만 존재할 당시,
POST /boards
GET /boards
GET /boards/:id이런 식으로 요청을 보냈었는데, 이렇게 직관적으로 이름을 지은 것을 Restful한 API라고 불렀다.
문제점
1. 너무 많은 endpoint 생성
2. 한 페이지에서 한 번에 여러 정보를 받아오지 못하고, 각 정보 마다 한 번씩의 요청
3. 특정 정보를 받아올 때, 관련이 없지만 연결되었다는 이유로 다른 정보를 가져와야 하는 점
개선 과정?
endpoint는 하나만 만들고 그 안에 필요한 정보를 보내주는 기능을 담은 함수들을 만들자! -> endpoint solution
요청을 보낼 때 응답으로 받아올 원하는 기능을 담은 함수를 선언해주자! -> underfetching solution
요청을 보낼 때 응답으로 받아올 항목을 미리 정해주자! -> overfetching solution
결국 GraphQL은 REST 이다?
GraphQL은 endpoint가 하나인 POST방식의 REST-API라고 생각하면 된다.
GraphQL의 단점?
요청이 실패했는데 200이 나오는 경우가 GraphQL의 특징..
요청을 보낼 때 타입 검사에서만 통과한다면 응답은 항상 200으로 나온다. 그룹 내에 실행되었지만 항목을 못 받아와도 실행에 성공하면 응답은 200이기 때문이다.
그럴 땐 전체 상태코드가 200이더라도 자세히 파고 들어가보면 성공한 것은 성공으로 뜨고 실패한 건 실패로 뜬다.
2. Recoil
컴포넌트를 만들 때 기능을 위해 쓰일 변수를 만들기 위해 각 컴포넌트 마다 만들어 놓은 state가 있을 것이다. 부모 컴포넌트에서 만든 state가 자식 컴포넌트에도 적용된다면 굳이 자식 컴포넌트에 또 만들지 않고 props를 이용해서 state를 넘겨주기도 한다.
컴포넌트가 많아지면 그만큼 컴포넌트의 깊이도 깊어지고, state를 공유하려면 여러 컴포넌트를 거쳐서 넘겨야할 수도 있을 것이다. state가 거쳐가며 지나간 길의 컴포넌트들에는 전부 리렌더링이 일어나게 되고, 불필요한 리렌더링은 많이 일어날 수록 성능 저하의 원인이 된다.
이러한 문제점을 해결할 수 있는 것이 바로 global state이다. global state란 전역에 영향을 미칠 수 있는 state를 말한다.
global state의 종류
1. 백엔드에서 받아온 데이터를 저장
2. 프론트 데이터 저장
fetchPolicy : 백엔드로 api를 호출하기 전에 결과값이 globalState에 있는지 검증하는 패치정책
react-query나 apollo/client는 fetchPolicy 기능이 내장되어있다.
백엔드에서 받아온 데이터를 저장하는 부분은 react-query, apollo/client가 있는데, 프론트는 어떻게 해야하나?
- apollo/client, react-query에 프론트 데이터들도 같이 넣자!
-> 너무 비효율적이다. apollo setting 등
프론트에서는 이럴 때 상태를 전역적으로 관리할 수 있는 Context API를 사용할 수 있고, 이외에도 상태를 전역 범위에서 관리하기 위해 Redux나 MobX,SWR, Recoil 같은 상태 관리 라이브러리를 사용한다.
- 그러면 프론트 부분은 redux에!
-> 그러기엔 redux는 보일러플레이트 코드가 많아서 너무 크고 무겁다. - 미니 리덕스가 없을까?
-> 아직 개발 단계라 불안정하지만 가벼운 Recoil을 사용해보자.
apollo의 useQuery에서 fetch-policy를 사용할 수 있는데, 이를 잘 활용하면 백엔드에서 새로 받아와야 할 때와 기존의 global state에 있던 걸 받아와야 할 때를 확실히 구분 지을 수 있다.
