[API통신] SWR - revalidate와 mutate의 차이점 (+optimistic, pessimistic UI)

이전 포스팅에서 SWR을 사용할 때 revalidate를 사용하여 지속적으로 서버로 요청을 다시 보내서 데이터를 가져온다고 하였다.

revalidate를 사용했을 때, 계속 요청을 보내고 있는 흔적

이러한 revalidate는, 가만히 있어도 계속 보내고 있기 때문에, 그렇게 하고 싶지 않을 경우가 있을 것이다. 이럴 때 mutate를 대신해서 사용한다. axios.post의 then에서 revalidate() 대신에 mutate(response.data, false)를 넣어주면 된다. mutate의 인자 중 첫 번째는 mutate할 대상, 두 번째 인자는 shouldRevalidate 속성에 대한 값을 설정하는 것이다. 공란이라면 기본적으로 true 설정이 되어있으므로 정말 업데이트를 하지 않으려면 false로 해줘야 한다.

const onSubmit = useCallback(
  (e) => {
    e.preventDefault();
    setLoginError(false);
    axios
      .post(
        'http://localhost:3095/api/users/login',
        { email, password},
        { withCredentials: true },
      )
      .then((response) => {
        mutate(response.data, false);
      })
      .catch((error) => {
        setLoginError(error.response?.data?.statusCode === 401);
      });
  },
  [email, password],
);

revalidate는 매번 서버로 요청을 다시 보내서 데이터를 받아오는 반면에 mutate는 서버에 요청을 보내지 않고 데이터를 수정한다. 그래서, 지속적인 요청을 막을 수 있다.

 

예시로, 인스타그램의 하트나 페이스북의 좋아요 같은 기능을 사용자가 누르자마자 숫자가 오르는 것을 들 수 있다.

하트나 좋아요를 우선 사용자 입장에서 반영을 해 주고, 나중에 서버로 업데이트 요청을 보내는 것이다. 이후 제대로 반영이 되었는지 점검을 하는데, 서버에 오류가 없다면 하트를 반영하지만 만약 서버에 오류가 생겨서 하트가 제대로 반영되지 않는 상황이라면 하트 반영을 바로 취소하고 꺼버린다. 이를 Optimistic UI라고 한다. 먼저 성공할 것이라고 간주하고 나중에 점검하는 것이다.

 

Optimistic UI의 경우 실제로 바로바로 업데이트를 해 주지는 않지만, 즉 이 좋아요를 누른 사실이 바로 서버에 전송되는 것은 아니지만 사용자 입장에서는 바로바로 업데이트가 되는 것으로 착각하게끔 할 수 있다. UX의 입장에서 굉장히 좋은 것이다.

 

반면에 Pessimistic UI도 있는데, 이는 하트 즉시 서버에 요청부터 하고, 그 이후에 이상이 없을 경우 반영하는 UI이다. 보통 Pessimistic UI를 대부분 채택한다. 그리고 이 경우 mutate의 두 번째 인자(shouldRevalidate)가 true가 되어야 하겠다. shouldRevalidate가 false라면, 서버에 요청을 보내지도 않고 로컬 단에서 데이터를 수정하는 것이다.