SWR API Options (feat. 라이브러리에 대한 고찰)

라이브러리에 대한 고찰 및 SWR관련 이슈 해결 기록 

회사에서는 SWR을 사용하고 있다. SWR을 간단하게 소개하면, 데이터 fetch 라이브러리로써 내부적으로 처리되는 로직으로인해 컴포넌트는 수시로 업데이트된 데이터의 stream을 받을 수 있다. 따라서 SWR은 알림기능, 라이브 기능 등에 최적화된 라이브러리라고 할 수 있다.

`With SWR, components will get a stream of data updates constantly and automatically.
And the UI will be always fast and reactive.`

 

이번에 발생한 이슈는 SWR API의 다양한 기본 옵션중에서 ShouldRetryOnError와 관련된 이슈였다.

shouldRetryOnError: fetch 함수에 오류가 발생하면 다시 서버에 데이터를 요청한다. 기본값은 true

shouldRetryOnError의 명세처럼 기본값은 true로 되어있다. 따라서 SWR로 fetching 하는 API콜에 오류가 발생하면, 지속적으로 Error를 요청한다. 만약 API 오류가 일시적인 오류라면 상관이 없지만, 해결될 수 없는 에러인데 계속 API Call을 하는 것이면 문제가된다.

 

이슈가 발생한 API Call은 다른 데이터에 종속적이어서 만약 종속하는 데이터의 API의 요청이 fail하면 해당 데이터에 undefiend가 set되고 fetcher에 오류가 발생시키고 있었다.

 

이때 shouldRetryOnError이 true이기 때문에 오류 발생 상황에서 클라이언트는 끊임없이 서버로 요청을 보내게되었고, 이 이슈로 인해 네트워크 요청에 과부하가 걸리고 심하면 서버가 터질 수도 있는 상황이었다. 

 

shouldRetryOnError Option은 위와 같은 상황을 디버깅하면서 발견했고, SWR의 Api Option docs가 있다는 것도 알게 됐다. SWR의 레퍼런스를 확인하고 shouldRetryOnError을 global config로 false로 처리하고, 종속하는 api의 데이터가 set되지 않으면 종속된 api call을 요청할 수 없도록 conditional fetching을 적용하여 해결할 수 있었다.

라이브러리.. '잘' 사용하자

더 고도화된 기술이 집약되어 있을수록 사용하기는 편하지만 에러가 발생했을 때 디버깅을하기 쉽지않다. 이럴 때 공식 레퍼런스를 확인하면 디버깅의 단서를 발견할 수 있다. 이런 점 때문에 라이브러리 사용에 점점 회의감을 느끼기도 하지만, 프론트엔드 분야에서는 라이브러리를 '잘' 사용하는 것도 중요하기 때문에 레퍼런스를 보는 습관을 들여야 한다.

 

다양한 라이브러리 중에서 현재 회사의 리소스와 기능을 고려하여 어떤 것을 선택할지 깊게 고민해보고, 결정한 뒤에는 해당 기능의 본질에 대해서 꼭 탐구해야 한다는 큰 교훈을 얻을 수 있었다.