어디서 본 포스팅인지 모르겠지만, 그 포스팅이 틀렸습니다. 혹시나 그 출처가 있다면 같이 링크도 달아주셔도 되고요.

GraphQL은 REST와 같이 선택사항으로 백엔드에서 데이터를 어떻게 가지고 올 수 있냐의 문제입니다. Todo list를 관리하는 백엔드를 개발할 경우, REST는 User와 Todo item항목들을 2번의 호출로 가져와야 하지만 GraphQL은 한번으로 가능할 수 있죠. 그래서 GraphQL과 REST의 선택사항이지 Redux와는 완전 별개입니다.

Redux는 React나 Frontend에서 상태를 관리하기 위한 패턴입니다.

백엔드에서 User와 Todo item들을 가져 왔을 때 state를 보다 더 효율적으로 관리하기 위한 패턴이라고 생각하면 됩니다.

맞습니다.

프론트에서 apollo라는 걸 이용해서 캐쉬에 데이터가 저장됩니다.

캐쉬된 데이터가 수정이 되면 해당하는 모든 gql에서 데이터 수정된게 반영되어 redux와 동일한 효과를 줄 수 있습니다.

chrome apollo 확장프로그램 깔아보세요~

예를 들어 쿼리로 데이터목록을 받아온 상태에서 뮤테이션으로 데이터를 생성이나 수정하면 다시 쿼리로 데이터 목록 받아오는게 아니라 캐쉬에서 수정이나 추가된 부분만 변경이 일어나는 아주 똑똑한 라이브러리죠 ㅎㅎ

예를 들어 좋아요 같은 기능을 구현 할때 전역 상태를 변경해서 한 곳에서 발생한 좋아요를 모든 곳에서 영향을 받게 해줘야 하는데.

graphql apollo사용하면 뮤테이션 시 id값으로 데이터에 수정이 일어난 부분을 확인하고 그 부분만 캐싱된 데디터에 반영해주고 관련된 모든 뷰를 업데이트 해주죠

아주 편합니다

페코옹

혹시 실례가 안된다면 캐쉬에 대해서 여쭤보고 싶습니다.

만약 뭔가 데이터를 가져오는 요청을 graphql로 보낼 때 '제목'을 기준으로 데이터를 가져온다고 가정하겠습니다.

그러면 처음에 '제목1'이라는 것을 요청에 실어서 보내고 난 후, 받아온 데이터는 캐쉬에 저장이 됩니다. 그 다음에 '제목2'라는 것을 요청에 실어서 보내면, 기존에 캐싱된 '제목1'의 데이터는 새로받아온 '제목2'에 덮어씌여지나요? 아니면 '제목2'가 새로 캐싱되나요??

요약하면 같은 요청을 보낼 때 안에 들어있는 데이터가 다르다면 기존 캐싱에 덮어씌여지는지, 따로따로 캐싱되는지에 대한 질문입니다!!!

@페코옹 

사람들이 오해할 수 있기 때문에 확실하게 이야기 해야 합니다.

graphql apollo가 redux 코드를 줄여주는데 도움을 줄 수는 있지만, 대체할 수는 없습니다. 그에 관련된 사례도 없기도 하거니와, Best practice도 아닙니다.

곰개발ㅈ ㅏ

찾아본다고 답글이 늦었습니다!

https://d2.naver.com/helloworld/2838729

여기 보고 참조했었습니다. 그러면 이 포스트에서는 어떤 식으로 상태관리를 하는것일까요?? contextAPI같은 것을 사용하나요??.

혹시 그리고 어떤 방식으로 redux코드를 줄일 수 있는지 말씀해주시면 감사합니다!!!!

거듭 말하지만 GraphQL apollo가  Redux를 대체할 수 있는 것이 아닙니다. Redux 코드를 줄여줄 수는 있겠죠. 

GraphQL apollo 공식 블로그에 나와 있는 내용입니다. 참고하세요. 

https://www.apollographql.com/blog/reducing-our-redux-code-with-react-apollo-5091b9de9c2a/

곰개발ㅈ ㅏ

지식 공유 감사드립니다!!!

페북에서 리액트 내에서 데이터의 흐름을 Flux 라는 패턴으로 정의를 내렸는데, 그거를 이제는 스타 개발자가 된 댄 애브라모브가 Redux 로 구현한 겁니다. Redux 는 앱 내에서 하나의 공유되는 State 를 가지며 Action -> Reducer -> State change 순서로 데이터가 흐릅니다. 그러므로 리덕스는 변화를 추적하기 아주 용이합니다. graphql 은 REST API 인터페이스를 교체할 수는 있지만 Redux 가 가져오는 여러가지 개발의 편리한 점까지 교체할 수 있는지는 잘 모르겠네요. 만약 몇개의 간단한 컴포넌트만 가지는 앱을 만드시는 거라면 컴포넌트가 data 를 GraphQL 을 이용해서 최신의 데이터로 sync 를 할 수는 있지만 꼭 GraphQL 이 아닌 간단한 Axios, react-swr, 혹은 react-query 같은 것을 써서 할 수도 있습니다. (앞의 라이브러리들은 GraphQL 인터페이스를 이용해서 fetch 를 할 수도 있습니다.) 하지만 Medium to Large 어플리케이션 개발은 Redux 를 이용하시는 것을 추천드립니다.

@톨머프

링크 공유 감사드립니다. 꽤 재밌는 주제네요.

쭉 읽어봤는데, stackoverflow나 medium이 올라왔으면 좋은 논쟁 거리로 딱이었을 주제긴 하네요. 댓글이 수백개 이상 달렸을 듯요. 암튼 저 블로그에선 제가 동의할 수 없는 부분이 많이 있네요.

곰개발ㅈ ㅏ

혹시 어떤 부분에 동의하실수 없는지 여쭤봐도 될까요??

아직 모르는게 많아서 좀 더 공부해보려고 합니다.

톨머프

ID가 키가 된다고 보시면 될 것 같습니다.

곰개발ㅈ ㅏ

3년이 더 지난 블로그 글을...ㅎ

일단 제가 말씀 드리고 싶은건

100프로 redux에서 지원하는 기능들을 대체 할 수 있다  = X

앱의 상태관리를 처리할 수 있다 = O

Offbench 

1은 알고 2는 모르시는 경우.. (1 : graphql,  2 : apollo )

@톨머프 

일단 글에서 데이터 로직이 복잡해 지고, 관리해야 하는 플러그인이 늘어난다는 것이 개발자의 부담을 늘리게 되어서 Redux를 GraphQL 기반의 Platform인 Apollo로 대체했다고 되어 있습니다.

여기서 제가 동의할 수 없거나, 글에서 주장의 동기가 부족한 이유이긴 합니다. Redux의 단점으로 Bolierplate때문에 Verbose하다는 것은 이미 많이 알려진 이야기 입니다. 

단점이 되기도 하지만, 장점으로 예측 가능하거나, 테스트/디버깅 하기 쉽거나, 확장성이 용이하기 위한 패턴이긴 합니다. 그래서 Redux가 좀 더 복잡한 로직을 처리하기가 유용할 수 있고, Apollo가 그 문제를 해결해 주지는 않습니다.

태생적으로 Apollo가 가진 Cache가 상태를 관리해주기 위한 패턴으로 개발된 것이 아니고, 그걸 대체한다는 표현을 쓰는 것 까지는 무리가 있다는 것이 제 생각입니다.

아얘 처음부터 생산성에 초점을 쓴 글이면 동의를 할 수 있겠으나, 다른 여러 Tech stack들이 혼합 되면서 왜 선택한지에 대한 의문이 더 늘어가게 됩니다.