서버 상태 관리 도구를 사용하는 이유

클라이언트 상태와 서버 상태를 분리하여 라이브러리를 사용하는 이유에 대해 알아봅니다.

또한 우리가 마주하는 문제는 무엇이고, 이는 어떻게 해결해야 할까요?

서버 데이터와 클라이언트 데이터가 같지 않을 수 있습니다.

⇒ 지속적으로 동기화를 통해 데이터의 최신화 작업이 필요합니다.
서버의 데이터를 전달 받기 위해서는 일정 시간이 필요합니다.

⇒ 로딩전, 로딩중, 로딩후의 시점과 상태에 대한 관리가 필요합니다.
서버의 데이터를 전달받거나 수정하는 과정이 항상 성공하리라는 보장이 없습니다.

⇒ 진행, 성공, 실패에 따른 별도의 처리가 필요합니다.
서버에 데이터를 요청하거나 받는데에는 비용이 발생합니다.

⇒ 불필요한 중복 요청이나 응답을 최소화할 수 있는 방안이 필요합니다.

지속적으로 동기화를 통해 데이터의 최신화 작업이 필요합니다.

⇒ 데이터 요청, 데이터 변경 시 자동 동기화, 에러 발생시 재요청, 특정 주기별 업데이트
로딩전, 로딩중, 로딩후의 시점과 상태에 대한 관리가 필요합니다.

⇒ 로딩과정에 대한 상태 변경 전파
진행, 성공, 실패에 따른 별도의 처리가 필요합니다.

⇒ 성공/실패 관련 전파, 각 에러에 따른 대응 로직, 성공/실패에 따른 추가 데이터 동기화
불필요한 중복 요청이나 응답을 최소화할 수 있는 방안이 필요합니다.

⇒ 중복 데이터 요청 방지를 위한 캐싱 등등

위와 같은 불편함을 느낄 경우, 해결 방안으로 서버상태관리도구를 떠올려봅시다.

즉, 기존의 상태 관리 개념으로 웹의 보편적인 서버 동작을 처리하려고 하니 오히려 과도한 오버엔지니어링 효과가 발생합니다.

때문에 서버 상태관리 문제를 전문으로 해결하고자 하는 도구인 서버상태관리도구가 등장했습니다.

서버상태관리도구

Query Key와 staleTime : 특정 서버 요청에 키와 보관시간을 지정하여 아직 ‘신선’한 데이터에 대해서는 재요청을 하지 않습니다.
병렬과 직렬 쿼리 : 요청 간 의존이 없다면 병렬로 요청하여 응답시간을 개선하고, 의존되는 쿼리끼리는 직렬로 요청하여 응답 속도를 개선합니다.
주기별, 포커스별 자동 업데이트 : 일정 시간이 지나거나, 다른 작업을 하다가 다시 접근할 경우 다시 요청하여 최신화된 데이터를 유지합니다.
무한스크롤 및 페이지네이션 지원 : 현대 애플리케이션에서 보편적으로 사용되는 UI 방식인 무한 스크롤이나 페이지네이션 기능을 지원합니다.
Query 요청 취소 : 서버에 요청한 데이터가 필요가 없어진 경우, 해당 요청 이후의 작업을 무시할 수 있도록 지원합니다.
오프라인 캐싱 : 서버의 내용을 브라우저의 스토리지에 보관하고 이 데이터를 먼저 노출하여 더 빠른 응답 속도를 지원합니다.

Key를 통한 스마트 리프레시 : 수정 요청이 완료되면 관련 데이터를 한 번에 업데이트를 요청하여 최신화된 데이터를 받을 수 있도록 합니다.
낙관적 업데이트 지원 : 서버에서 데이터를 변경하고 변경된 데이터를 조회해서 화면에 반영되는 시간을 줄이고자, 브라우저에서 먼저 화면에 반영하고 서버에 데이터를 업데이트하되, 실패하면 원래 상태로 복구하는 기능을 지원합니다.
트랜잭션과 롤백 : 여러가지 동시 변경사항을 한 번에 요청하여 충돌을 방지하고, 이 중 하나라도 실패한다면 이전의 상태로 되돌리는 롤백 기능을 제공합니다.

서버의 데이터는 방대하나 클라이언트의 데이터는 그럴 수 없습니다.
또한 서버의 모든 데이터를 클라이언트와 1:1로 동기화할 수는 없습니다.
API를 통해서 가져온 데이터는 클라이언트에 맞게 재조정되어 보관하여 이를 캐싱이라고 합니다.
캐싱된 데이터는 상황에 맞게 재사용하며 클라이언트 프로그램에서 상태로 활용됩니다.
컴포넌트에서는 직접 서버에서 데이터를 활용하지 않고 이러한 캐싱된 서버 상태를 이용하여 개발하면, 서버와 무관하게 상태관리 추상화 레이어를 통해서 기존의 애플리케이션을 만드는 느낌과 유사하게 개발을 할 수 있습니다.