최근 프로젝트에 서버 상태 관리 라이브러리로 react-query를 이용했다.
이 글은 기술적 의사결정에 의한 기술/스택 채택을 담은 글이다.
내가 직접 이용하지 않은 react-query의 기능들도 있지만 경험과 학습을 동시에 진행해보고자 한다.
React Query
서버 상태 관리를 위한 다양한 라이브러리가 있다.
대표적으로 Redux Toolkit + RTK Query, Apollo Client, SWR가 존재한다.
나는 왜 React-Query를 이용했고 어떤 장단점이 있는지 살펴보자.
React Query란?
react-query는 데이터 fetching, caching, 동기화, 서버 데이터 업데이트등을 쉽게 만들어 주는 라이브러리이다.
즉, 리액트에서 서버 상태 관리를 쉽게할 수 있도록 지원하는 라이브러리이다.
React Query 장점
- 비교적 적은 양의 코드로 작성이 가능하여 타 라이브러리에 비해
Boiler Plate code를 방지할 수 있다. 이는 유지/보수와 가동성 측면에서 이점이 있다는 말이된다. caching을 통해서 데이터를 효율적으로 핸들링하기 때문에 동일한 데이터 중복 요청을 줄이고 애플리케이션의 속도를 향상시킨다.caching된 데이터는 백그라운드에서 자동으로 업데이트 될 수 있고, 이를 통해서 항상 최신의 데이터를 볼 수 있다.Garbage Collection(GC)을 이용하여서버 쪽 메모리를 관리해준다.- Hook과 유사한 인터페이스를 제공하여 사용이 편리하고 학습 곡선이 완만하다.
Pagenation및무한 스크롤(infinite scroll)도구를 지원한다.
다른 라이브러리의 장단점
- Apollo Client
- 장점: GraphQL 최적화: GraphQL과의 통합에 특화되어 있어, GraphQL을 사용하는 프로젝트에 매우 적합
- 단점: GraphQL 의존성: REST API와 같은 다른 유형의 API와는 자연스럽게 통합되지 않는다.
- SWR
- 장점: 간결하고 직관적인 API, 자동 리밸리데이션(재검증)
- 단점: 제한된 기능, 커스터마이징 제한
- Redux Toolkit + RTK Query
- 장점:
- 통합된 상태 관리: 전역 상태 관리와 서버 상태 관리를 함께 처리할 수 있다.
- 강력한 커뮤니티와 생태계: 방대한 지원 자료와 미들웨어, 플러그인이 존재한다.
- 단점: 복잡성,
Boiler Plate code
- 장점:
React Query를 채택한 이유
각 라이브러리의 장단점을 고려했을 때 내가 프로젝트에 react-query를 사용한 이유는 아래와 같다.
- 무한 스크롤링/페이지네이션
무한 스크롤링/페이지네이션도구(useInfiniteQuery)를 제공하는 것을 확인하고 서버 상태 관리 이외에 프로젝트에 유용하게 사용할 수 있는 부가 기능을 활용하기 위해
- caching을 통한 Optimistic update
- 서버와의 API 통신 작업이 끝난 후 UI가 업데이트 되면서 발생하는 임의의 대기 시간을 개선하기 위해(즉각적인 UI 업데이트 제공
Mutation)
- 서버와의 API 통신 작업이 끝난 후 UI가 업데이트 되면서 발생하는 임의의 대기 시간을 개선하기 위해(즉각적인 UI 업데이트 제공
- Hook과 유사한 코드
- Hook를 사용하는 방법과 비슷하게 사용할 수 있기 때문에 빠르게 학습하여 적용하기 위해
refer
기록하고 꺼내보고