React query 도입 제안

프로젝트 시작하며.

1. 도입 배경

기존에 네트워크 요청의 경우 대부분 명령형으로 작성하고 있었다.

첫 번째 이유로 hook이라는 개념이 나오면서 선언형으로 작성할 수 있게 되며 해당 로직의 역할에 대해 명시적으로 나타낼 수 있게 되었다.

두 번째 이유로 비동기 요청에서 관리해야하는 상태(성공, 로딩, 에러), 캐시, 데이터 요청을 구현하는 것이 안정성 및 비용 측면에서 더 크게 다가 왔다.

하지만, React-query만이 정답은 아니기에 해당 솔루션에 대해 고려해보기로 하였다.

2. React-query vs RTK query vs SWR

다음과 같은 평가 기준으로 검토한 후 각 부분에 대해서 의견을 공유하였다.

1. Learning Curve(학습 비용) : 초심자가 쉽게 학습할 수 있는가?

2. Community size(커뮤니티 활성도) : 이슈가 발생했을 때, 커뮤니티에서 답을 찾을 수 있는가?

3. Stability(안정성) : 라이브러리 관리가 잘 되고 있는가

4. Compatibility(호환성) : 기존 코드에 같이 쓸 수 있는가?

• React-query vs RTK query

	React query	RTK query
Learning Curve	Low	High
Community size	Big	Small
Stability	High	High
Compatibility	High	Low

React-query vs RTK query 결과 모든 부분에서 React query가 현재 팀에는 잘 맞았다.

기본적으로 Redux를 쓰는 팀이 아니며 React hook 방식에 익숙해져있기 때문에 좋은 평가를 받은 것 같다.

• React-query vs SWR

	React query	SWR
Learning Curve	Low	Low
Community size	Big	Big
Stability	High	High
Compatibility	High	High

React-query vs SWR 결과 모든 부분에서 같은 결과를 가져왔다

기본적으로 React hook에 익숙한 팀에게 두 선지 모두 매력적이다.

하지만 기본적으로 React-query는 상태관리 측면에서 글로벌 상태와 분리할 수 있다는 점이 좋은 평가를 받을 수 있었다.

3. React-query가 최고야?

그렇지 않다고 생각한다.

React query도 서드파티이고 특정 문제를 해결하기 위한 솔루션이다.

한가지 예로 Recoil만으로 비동기 요청과 Server state 관리를 해도 뭐라할 사람은 없다고 생각한다.

React-query를 도입하면서 얻는 장점이 도입에 들어가는 비용보다 크다면 충분히 가치있다고 생각한다.

프로젝트를 마치며.

프로세스를 개선하기 위한 많은 도구와 라이브러리들이 있다. 기술 제안을 하기위해 다시 정리하며 해당 기술의 본질에 대해 한 번 더 생각해보았다.

내부 프로세스와 생산성 개선을 위해 앞으로도 기회가 있다면 제안을 해볼 것 이다.

540KB

Reactquery도입_정승덕_230801.pdf

pdf

발표자료

Next Step.

새로 기술을 도입하는데까지 많은 비용이 소모되어 당장의 기술 도입보다는 문제 해결에 초점을 맞추어보았다.

내부 기술 인력들에게 피드백을 받아 내가 놓은 부분과 잘한 부분을 정리해볼 것이다.

실제로 내 토이프로젝트에 적용 예시를 통해 사내 프로젝트에 도입할 수 있도록 유의미한 근거를 만들어볼 생각이다.