원문 :
https://codedamn.com/news/javascript/useswr-vs-react-query-differences-and-which-one-should-you-choose
https://blog.logrocket.com/swr-vs-tanstack-query-react/
https://tech.madup.com/react-query-vs-swr/
https://sihyungyou.github.io/iOS-race-condition-in-swift/
많은 라이브러리를 통해 React에서 데이터를 가져올 수 있지만 현재 가장 인기 있는 두 가지는 바로 SWR / Tanstack React Query이다. 이 두 라이브러리는 얼핏 비슷해 보일 수 있지만 몇 가지 중요한 차이점이 있다. useSWR과 Tanstack React Query의 차이점을 살펴보고 어떤 라이브러리가 프로젝트에 적합한지 결정해 보자.
useSWR이란?
useSWR는 동기식 API를 제공하는 데이터 가져오기용 React Hooks 라이브러리이다. API 메서드를 호출할 때, useSWR에서 데이터 가져오기를 자동으로 조정하고 구성 요소로 반환한다. useSWR은 API, 데이터베이스 및 서버 측 렌더링을 포함한 모든 소스에서 데이터를 가져올 수 있다.
SWR은 먼저 캐시에서 데이터를 반환한 다음, 서버에 데이터를 가져오는 요청을 보내고, 마지막으로 최신 데이터를 제공하는 전략이다.
React Query?
React Query는 React에서 비동기 데이터를 관리하기 위한 라이브러리이다. 크게 React Apollo의 클라이언트를 기반으로 하지만 기능이 적고 크기가 작다.
React Query는 React 앱에서 비동기 데이터를 가져오고, 캐시하고, 업데이트하기 위한 일련의 hooks 및 tools를 제공한다. 핵심 hooks 외에도 React Query는 데이터 관리, 오류 처리 및 페이지네이션등 유용한 유틸리티를 제공한다.
React Query는 리액트 애플리케이션에 서버 상태를 가져오고, 캐싱하고, 동기화하고, 업데이트하는 것을 쉽게 해 준다.
useSWR와 React Query의 차이점
SWR와 React Query를 선택하기 전에 고려해야 할 몇 가지 주요 차이점을 살펴보자
- useSWR은 단일 API 엔드포인트에서 데이터를 가져오는 것으로 제한된다. 반면에 React Query는 여러 API 엔드포인트에서 데이터를 가져올 수 있다. 이는 React Query를 보다 다재다능하게 만든다.
- useSWR은 API 엔드포인트에서 최신 데이터를 반환한다. 최신 데이터를 원하는 경우 유용할 수 있지만 race condition 즉, 경쟁 조건으로 이어질 수 있다. React Query에는 API 엔드포인트에서 데이터를 가져오는 빈도를 제어할 수 있는 내장 캐싱 메커니즘이 있다. 그러므로, 데이터를 가져올 때 좀 더 안정적으로 만든다.
- race condition은 예측 가능한 작업 시퀀스의 completion 순서가 예상하지 못하게 흘러가 프로그램 로직이 undefined state가 되는 경우를 말한다. 예를 들어, 콘텐츠가 완전히 로드되기 전에 UI가 업데이트 된다거나 로그인이 되지 않았는데 로그인 되었을 때의 화면을 보여주는 경우다.
- useSWR은 API 엔드포인트에서 데이터를 가져올 때 오류를 처리하는 방법을 제공하지 않는다. 반면에 React Query에는 오류가 정상적으로 발생할 때 처리할 수 있는 에러 헨들링 시스템이 내장되어 있다.
- React Query는 React hooks와 기존 클래스 기반 구성 요소와 호환되는 반면 useSWR은 React hooks용으로 명시적으로 설계되어있다.
- useSWR은 SWR 위에 구축되어있지만 React Query는 Axios 위로 구축되어있다.
- useSWR은 데이터 소스를 원격으로 쿼리할 수 있는 반면 React Query는 애플리케이션의 API에서 데이터 캐싱 및 가져오기에 중점을 둔다.
- useSWR은 종속성이 변경되면 자동으로 데이터를 다시 가져오는 반면, React Query를 사용하면 데이터를 다시 가져올 시기와 빈도를 결정할 수 있다.
- useSWR은 첫 번째 요청이 완료될 때까지 초기화되지 않은 값을 반환하는 반면, React Query는 캐시된 값을 즉시 반환한다. (존재하는 경우)
인기 및 지원
오픈 소스 라이브러리는 일반적으로 인기를 얻고 다음과 같은 상황에서 Github 스타게이저를 얻는다.
- 더 많은 개발자가 특정 라이브러리를 사용하는 경우
- 해당 라이브러리가 평균 이상의 개발자 지원을 제공하는 경우
- 저장소가 잘 유지 관리되는 경우
이 두 라이브러리에는 많은 스타게이저가 있으며 뛰어난 개발자 커뮤니티도 있다. SWR은 디버깅을 위한 공식 개발자 도구를 제공하지 않지만 커뮤니티 회원이 디버깅 목적으로 GUI 개발자 도구를 만들었다. 반면에 React Query는 SWR보다 더 자세하고 체계적이며 지원이 되는 공식 문서를 유지하고 있다.
개발자 도구
React Query는 공식 개발자 도구와 함께 제공되지만 SWR은 비공식이지만 사용되는 SWR용 도구인 swr-devtools를 만들었다.
swr-devtools는 읽기 전용 데이터만 표시하지만 디버깅에 필요한 중요한 정보를 보여준다.
반면 React Query 개발자 도구는 캐시된 데이터를 표시뿐만 아니라 캐시된 콘텐츠를 조작할 수 있도록 한다.
내장된 유용성 기능
SWR 또는 React Query와 같은 라이브러리를 사용하는 세 가지 주요 이유가 있다.
- 서버 상태와 React 앱 상태를 동기화하기 위해 작성해야 하는 코드의 양을 줄인다
- 데이터 캐싱 및 중복 제거 쿼리를 통해 원격 리소스를 최적으로 사용
- 실시간 경험으로 애플리케이션 사용성 향상
사용성 향상은 캐싱 및 쿼리 최적화의 중요한 이유이므로 두 라이브러리 모두 경쟁적으로 다음과 같은 사용성 기능을 제공한다.
- 초점에 대한 재검증
- 네트워크 상태 다시 가져오기
- 데이터 프리페치
- 시간 간격에 따른 재검증
TanStack Query는 다음과 같은 추가 유용성 기능을 제공한다.
- 사용자가 컴포넌트로 다시 돌아올 때 무한 스크롤 위치를 저장하기 위한 스크롤 복원 기능
- 장기 실행 쿼리를 중지하기 위한 쿼리 취소 기능
- 오프라인 mutation 지원
번들 크기 및 성능 최적화
모든 사용자가 초고속 인터넷 연결을 사용하거나 고급 컴퓨터를 사용하는 것은 아니다. 따라서 건강한 번들 크기를 유지하고 성능 최적화를 구현하면 모든 사용자가 인터넷 속도와 컴퓨터 사양에 관계없이 원활하게 앱을 실행할 수 있다.
React SWR은 매우 가벼운 라이브러리다. BundlePhobia에서 gzip 압축된 크기를 4.2kB로 측정합니다. 반면, React Query는 광범위한 기능으로 인해 약간 무겁기 때문에 11.4 kB로 측정된다. 이는 실제로 React 핵심 라이브러리 크기의 4배 이상이다!
두 라이브러리 모두 렌더링 최적화, 중복 제거 요청 및 캐시 최적화를 내부적으로 수행한다. 참고로, 캐싱 라이브러리는 HTTP 요청 처리 속도를 향상시키지 않는다. HTTP 요청 성능은 HTTP 클라이언트 라이브러리 성능, 브라우저의 JavaScript 엔진 구현, 네트워크 속도, 현재 CPU 부하 등과 같은 다양한 요인에 따라 달라지기 때문이다.
요약
비교 | SWR | React Query |
전반적인 API 설계 | 일부 고정 기능으로 개발자를 위한 최소한의 API 제공 | 완벽하게 사용자 정의할 수 있는 기능을 갖춘 개발자를 위한 상세하고 다소 복잡한 API를 제공 |
번들 크기(gzipped) | 4.2KB | 11.4KB |
인기도, 커뮤니티 지원 및 문서화 | 좋은 커뮤니티, 잘 관리된 저장소, 데모가 포함된 전반적으로 좋은 문서 | 좋은 커뮤니티, 잘 관리된 저장소, 많은 실제 예제와 완전한 API 참조가 포함된 유익한 문서 |
기본 데이터 가져오기 및 변형 기능 | 개발자 요구 사항을 충족하지만 개발자는 일부 기능에 대해 추가 코드를 작성해야 하며 심층적인 사용자 지정 문제에 직면할 수 있다. | 심층적인 사용자 정의 지원으로 개발자 요구 사항을 충족한다. 소규모 프로젝트와 통합하려는 개발자는 API가 약간 더 복잡하다는 것을 알 수 있다. |
성능 최적화 | 요청 중복 제거, 렌더링 최적화 및 최적화된 캐싱 지원 | 요청 중복 제거, 렌더링 최적화 및 최적화된 캐싱 지원 |
내장된 유용성 기능 | 포커스 재검증, 네트워크 상태 재인출, 데이터 사전 인출, 간격 기반 재검증 | 포커스에 대한 재검증, 네트워크 상태 다시 가져오기, 데이터 사전 가져오기, 간격 기반 재검증, 요청 취소, 오프라인 변형 및 스크롤 복원 기능 |
개발자를 위한 내장 기능 | 페이지 매김 및 무한 로딩 기능을 제공한다. Chrome 및 Firefox 확장을 사용하여 개발자 도구 GUI를 제공한다. | 페이지네이션 및 무한 로딩 기능을 제공한다. 캐시 조작을 지원하는 공식 개발자 도구 GUI가 함께 제공된다. |
리액트 서스펜스 | 지원 | 지원 |
다른 프런트엔드 라이브러리에 대한 공식 지원 | 아니오, 유사한 커뮤니티 라이브러리 사용 가능: https://github.com/ConsoleTVs/sswr | 진행 중 유사한 커뮤니티 라이브러리 사용 가능: https://github.com/DamianOsipiuk/vue-query |
무엇을 선택해야 할까?
useSWR와 React Query의 주요 차이점은 이 두 라이브러리가 캐싱을 처리하는 방식이다. useSWR은 받은 데이터를 자동으로 저장하므로 필요할 때 캐시에서 가져오기 때문에 네트워크에 다시 요청할 필요가 없다. 속도 면에서는 좋지만 백엔드 서비스가 자주 업데이트되면 데이터가 stale하게 된다. React Query는 캐싱에 대한 더 많은 제어를 제공하기 때문에 유용하지 않은 캐시를 지울 수 있다.
또 다른 차이점은 페이지네이션을 처리하는 방식이다. useSWR은 가져온 데이터에 자동으로 페이지를 매기므로 사용자가 아래로 스크롤할 때 수동으로 데이터를 계속 가져올 필요가 없다. 하지만 React Query는 기본적으로 페이지네이션을 지원하지 않지만 쉽게 구현할 수 있다.
간단하게 데이터를 가져오기에는 useSWR가 좋고, 데이터 캐싱 및 더 많은 제어가 필요한 경우에는 React Query가 좋다고 할 수 있다. 즉, 데이터를 가져오는 간단한 방법이 필요하고 데이터가 오래되어도 상관 없다면 useSWR이 좋은 옵션이다. 하지만 캐싱에 대한 보다 세밀한 제어가 필요할 때는 React Query가 좋은 선택이다.
결론
두 라이브러리 모두 장단점이 있다. SWR은 React 요청 처리의 캐싱 문제를 해결하기 위한 최소한의 API를 제공하는 것이고 React Query는 동일한 문제에 대해 완전한 기능을 갖춘 솔루션을 제공한다. React는 클래스 기반 구성 요소의 복잡성을 줄이기 위해 기능적 구성 요소를 도입했기 때문에 이러한 단순성을 좋아하는 개발자는 SWR, 상세하고 강력한 API로 작업하고 데이터 캐싱을 위한 프레임워크와 같은 올인원 솔루션을 찾는 개발자는 React Query를 선택하면 된다. 둘 사이에 확실한 승자는 없다.
'Front-End > React' 카테고리의 다른 글
React 동작 방식 (0) | 2024.03.25 |
---|---|
엑셀 다운로드 (0) | 2023.07.02 |
API를 호출할 때 useState 대신 useSWR을 사용해야 하는 이유 (0) | 2023.01.09 |
[React] useEffect와 sideEffect (1) | 2022.08.22 |
[React, JS] 비동기 동기 처리 (0) | 2022.08.11 |