프론트엔드 개발자가 되기위한 여정 -20

이정우·2022년 9월 29일
0

frontend-bootcamp

목록 보기
22/60

밸~하!

밸로그 여러분 안녕하세요!

오늘의 포스팅 주제는
globalState 그리고
GraphQL과 restAPI입니다!

여러분 과거에 포스팅한것에 추가로 학습한 내용이있어서 공유해볼까 합니다!
사실 graphql은 restAPI의 일종이라는것입니다!
무슨소리냐고요?!

어떤내용인지 한번 알아볼까요??

1. GraphQL vs RestAPI

자 다시한번 차이를 봐볼까요?
먼저 restAPI입니다
Rest API는 오버패칭이라고 하는데요!
그이유는요!
restAPI=> overfetching
->필요하지 않은것도 가져온다
맞습니다!
필요하지 않은것 까지도 다 가져옵니다

반대로 GraphQL은 언더패칭이라고 합니다!
graphQL => underFetching
->필요한것만 가져온다
그렇습니다!

이전까지 graphQl의 단점이라고 생각했던것은
한번에 한개씩 밖에 못가져온다고 생각을 했었는데
그게 아니라 graphQL을 사용하면 여러개의 api를 받아올수 있다는것 !
놀랍지 않나요?!

사실 원래 GraphQL은 한번에 여러개를 받아올수 있었지만
지난시간까지 RestAPI의 overfetching에만 집중해서 봤기에
이번엔 underfetching의 경우까지 같이 알아볼수 있도록 하겠습니다!

기존의 restapi의 경우에는 언더패칭의 문제점이 있었습니다
바로 필요한것을 가져오기위해서는 여러번 요청을 했어야했는데요!

하지만graphQL의 경우에는 한번만 요청을 하면 가져올수있다는거죠?

이번엔 이해를 돕기 위해
예제를 통해서 보겠습니다

기존의 RestAPI의 경우에는

{
writer:철수 // Post방식
title: 안녕하세요 // get
contents:반갑습니다 // get
}

위 3개를 요청하려면 너무많은 endpoint생성/언더패칭의 문제점/오버페칭의 문제점

이렇게 있었습니다

하지만 graphQL의 경우에는

{
createBoard(){
}
updateBoard(){}
} // post

이렇게 한번에 필요한 요청을 가지고올수있다는거죠

이렇게 된다면 많은 endPoint의 생성을 방지하고/언더패칭/오버패칭의 문제 또한 해결할수있게됩니다

하지만!
놀라운것은
graphQL은 restapi에서 발생한 언더패칭 오버패칭 endpoint를 해결해준 일종의 restapi의 일종이라는것이죠!
한마디로 줄이면

graphQl은 endpoint가 하나인 post 방식의 RestAPI이다!!

라는겁니다!
정말 놀랍지 않나요??
사실 그래프QL이나 레스트 API나 완전히 다른거라고 생각을 하고있었는데
사실은 사용방식중 하나라는것에 새로운 사실을 학습하게 되었습니다!

그렇다고 이거 한 주제만 적기에는 너무 짧죠?
그 다음 주제로 한번 가 볼까요~~

2. Global State - recoil

이번엔 글로벌 스테이트라는것입니다!

이전에 State에 대해서 포스팅을 했었는데요!

기존에는 useState를 사용해서 각 컴포넌트에 선언을 하고
선언한 컴포넌트 내부에서만 사용을 할 수 있었습니다

하지만 Global State라는것을 사용하면
한개의 컴포넌트에서만 사용하는것이 아니라
여러 컴포넌트에서 동시에 사용할수 있다는것입니다!

그러면 코드의 길이도 확실히 줄겠고
가독성도 뛰어나 지겠죠??

저번까지 했던것은
Props라는것을 통해서 propsdrilling을 하여 컴포넌트에 전달해줬었습니다!
하지만 globla state를 사용한다면 궂이 드릴링을 하지 않더라도 충분히 사용할수가 있겠죠??

하지만 이것을 직접 만들기 시작한다면 만드는데 어려움이 있어서
라이브러리에서 미리 만들어져있습니다
바로
Redux라는 것인데요!
이 redux라는것이 지속적으로 발전되어서
mobX->SWR을 거쳐서
나온 최신기술들이
바로
크게 두개로 나누자면
Rest에서는 react-query가있고!
graphQL에서는 apollo/client가 있습니다
그럼 이렇게 발전된 이유가 무엇일까요?

바로
백엔드데이터를 받아오기 위한 global State가 있고
프론트엔드 데이터를 저장하기 위한 global State가 나뉘기 떄문입니다.

Redux의 경우 한번 받아온것을 redux에 저장을하게되고
만약 Redux에 없는 데이터의 경우에는 새로 받아오자 라는 fetchPolicy라는것을 따랐습니다
그럼 왜 리덕스를 안쓰냐고요?
왜냐면 기존 Redux에서는 이것을 자체적으로 지원하지 않았기 때문에 이것을
자체적으로 지원할수있도록 해준겁니다

react-query 나 apollo/client같은 경우는 Redux+fetchPolicy가 포함이 되게 되었습니다
그렇기에 이제는 편하게 사용을 할 수 있게 된 것이지요

그래서 사용 법에는 크게 세가지 방법이 있습니다
1.apollo/client,react-query에 이것들도 같이 넣자 (프론트와 백엔드 같이)
2. 프론트 부분은 redux에 넣자(백엔드와 프론트 분리)
3. 미니 리덕스가있다면? 거기에 넣자(recoil)

이렇게 되니 Redux의 사용량이 줄어들기 시작했습니다
그러다가 뒤늦게 나오게 된것이 바로
ReduxToolkit이라는것이 나오게 됬습니다

자 오늘의 포스팅은 여기까지!

오늘의 정보 도움이 되셨나요??
오늘은 RestAPI와 graphql이 사실은 같은Rest였다는것과
Redux를 대체해서 나온 recoil과 여러 방법론에 대해서 알아보았습니다

정보가 도움이 되셨다면 하트! 눌러주세용

그럼 밸로그여러분
안녕!
밸~바!

profile
주니어 프론트엔드 개발자

0개의 댓글