API마다 패치해오는 방법을 의논해봐요 (feat.tanstack-query, useFetch)

[Gilpop8663]

API 밑에 자신의 생각을 적어주세요~ 🤭

추가적으로 적어야 할 명세가 있다면 적어주시면 감사하겠습니다~

• 게시글 목록 조회

• 게시글 상세 조회

• 게시글 작성 (생성, 수정)

• 댓글 목록 (조회, 수정, 삭제, 생성)

• 카테고리 목록 조회

• 신고 기능 (게시글, 댓글, 유저)

• 유저 정보 (조회, 닉네임 수정, 회원 탈퇴)

[Gilpop8663]

캐시타임: 기본 5분
스테일타임: 기본 0초

• 기본값으로 설정했을 시 화면이 바뀌게 된다면 새롭게 패치하는 것으로 이해했습니다.
• 불러온 후 같은 화면에서 캐시 타임 5분이 지난다면 캐시 데이터가 만료되고 새롭게 패치하는 것으로 이해했습니다.

캐시 타임, 스테일 타임에 대한 참고자료

https://ttaerrim.tistory.com/m/53

게시글 목록 조회

선정 도구: tanstack-query

• 정렬 기능 및 검색, 카테고리별 게시글, 내가 쓴 게시글, 내가 투표한 게시글 등에서 무한 스크롤이 사용됨
• 게시글 목록 화면에서 해당 게시글에 투표를 할 수 있음
• 이 때 게시글 투표를 낙관적 업데이트를 통해 사용성을 증가시킬 수 있음

캐시타임: 기본 5분
스테일타임: 기본 0초

캐시 타임과, 스테일타임에 대한 이유

• 변경이 잦은 데이터이기 때문에 스테일 타임을 0초로 하여 항상 최신화를 해주어야 한다고 생각합니다.

게시글 상세 조회

선정 도구: tanstack-query

• 상세 데이터에서 투표 선택지를 바꾸는 기능이 있습니다. 낙관적 업데이트를 한다면 UX를 높일 수 있습니다.
• 게시글 수정, 게시글 삭제, 게시글 신고 기능 등이 있습니다
• 게시글 조회 시 Suspense를 이용해 스켈레톤을 보여줄 것이라면 tanstack-query가 필요해보입니다
• 게시글 삭제했을 때 홈페이지로 이동하기에 새로 패치되어서 tanstack-query와는 상관없는 것으로 생각됩니다.
• 게시글 수정 시 게시글 작성 페이지로 이동하기에 새롭게 패치해와서 tanstack-query와는 상관없는 것으로 생각됩니다.
• 게시글 신고가 5회 쌓인다면 게시글 비공개 처리가 되는 것으로 알고 있는데 신고한 유저가 5회일 때 홈페이지로 이동된다면 tanstack-query와 상관없지만, 5회일 때 본문 내용 및 투표 선택지만 안보이게 되고, 댓글만 보이게 된다면 tanstack-query가 필요해보여요

결정적인 이유

• useFetch를 사용하여 조회해온다면 투표 선택지 변경을 할 때 마다 리패치해서 깜빡거리는 이슈가 있을 것으로 예상됩니다

캐시타임: 기본 5분
스테일타임: 기본 0초

캐시 타임과, 스테일타임에 대한 이유

• 투표 데이터가 반영된다는 점에서 변경이 잦은 데이터이기 때문에 스테일 타임을 0초로 하여 항상 최신화를 해주어야 한다고 생각합니다.

게시글 작성 (생성, 수정)

선정 도구: useMutate 커스텀 훅 제작 후 사용이 좋아보여요

• 생성 시에는 작성이 완료되면 홈페이지로 이동하기에 mutate 기능이 필요해보이지 않아요
• 수정 시에는 작성이 완료되면 수정한 상세 게시글 페이지로 이동하기에 mutate 기능이 필요해보이지 않아요

투표

선정 도구 : tanstack-query, useMutate 커스텀 훅 제작

• 투표 선택지 생성, 변경시에 게시글의 쿼리키 값을 초기화해줘야 사용자에게 새롭게 렌더링된 데이터가 보이게 됩니다.
• 커스텀 훅을 만들어 사용하고 거기서 쿼리키값을 초기화하는 로직을 해주어도 되겠네요

댓글 목록 (조회, 수정, 삭제, 생성)

선정 도구: tanstack-query

• 댓글 상세 조회가 없고 , 댓글 목록 조회만 있습니다
• 댓글 아이템 수정, 삭제 시 댓글을 새로 불러올 때 깜빡거리게 될 것입니다
• 탄스텍쿼리로 낙관적 업데이트를 하게 되었을 때 깜빡거리는 이슈를 보완할 수 있다고 생각해요
• 삭제도 낙관적 업데이트가 가능해보여요
• 생성도 낙관적 업데이트가 가능해보여요

캐시타임: 기본 5분
스테일타임: 기본 0초

캐시 타임과, 스테일타임에 대한 이유

• 게시글 상세 조회할 때 댓글도 변경은 잦은 데이터이기 때문에 매번 불러오는 것이 맞다고 생각해요

카테고리 목록 조회

선정 도구: tanstack-query

• 선호하는 카테고리가 변경될 때 낙관적 업데이트가 좋아보여요
• 카테고리 목록은 변하지 않는 데이터이기 때문에 서버에 요청 수를 줄일 수 있는 tanstack-query가 좋아보여요

캐시타임: 기본 1시간
스테일타임: 기본 1시간

캐시 타임과, 스테일타임에 대한 이유

• 카테고리 목록이 변하는 일은 없을 것입니다
• 선호하는 카테고리 버튼을 눌렀을 때 카테고리 목록을 새롭게 패치하도록 하기에 캐시,스테일 타임을 길게 잡을수 있다고 생각해요

게시글 통계 페이지

선정 도구: tanstack-query

• 게시글 통계 페이지는 변경되지 않는 데이터이기에 서버에 요청 수를 줄일 수 있는 tan stack-query가 좋아보여요
• 해당 페이지에서는 요청수가 최대 6번으로 알고 있는데 유저가 여러번 왔다갔다한다면 요청수가 많아질 것으로 예상되요

캐시타임: 기본 30분
스테일타임: 기본 30분

캐시 타임과, 스테일타임에 대한 이유

• 게시글 통계 페이지 데이터가 변하는 일은 없습니다
• 캐시 타임과 스테일 타임을 너무 길게 잡는다면 메모리가 낭비된다고 생각해서 20~30분이 좋아보여요

신고 기능 (게시글, 댓글, 유저)

선정 도구: tanstack-query, useMutate fetch하는 커스텀 훅

• 신고 시 5회가 되었다면 댓글, 게시글의 쿼리 키 값을 초기화해주고, 새롭게 보이도록 해야 합니다
• 게시글, 유저, 댓글 신고의 경우에 tanstack-queey의 useMutate를 사용하지 않더라도 일반 패치를 하고 쿼리 키값만 초기화 해줄 수 있습니다.

유저 정보 (조회, 닉네임 수정, 회원 탈퇴)

선정 도구: tanstack-query

• 내가 작성한 글, 내가 투표한 수 등이 변하는 데이터입니다
• 낙관적 업데이트를 하지 않으면 투표할 때마다 왼쪽의 유저 정보가 깜빡일 것으로 예상되어요
• 닉네임 수정 시 낙관적 업데이트를 이용할 수 있어요

캐시타임: 기본 1시간
스테일타임: 기본 1시간

캐시 타임과, 스테일타임에 대한 이유

• 유저 정보가 변하는 일은 투표, 작성, 닉네임을 변경할 때로 잦은 변경이 일어날수도, 아닐수도 있습니다
• 투표시, 작성 시, 닉네임을 변경 시 유저 정보를 불러오는 훅에서 사용하는 쿼리 키값을 수동으로 제거해준다면 통신 횟수를 줄일 수 있을것 같아요
• 대신 작성, 투표 시에도 유저의 쿼리 키 값을 초기화하고 낙관적 업데이트 하는 로직이 추가되어야 합니다

결론

• 사이트를 이용하는 유저가 조회 시 깜빡거리는 화면을 안 보여줌으로써 사용성을 늘리고 있다
• 낙관적 업데이트를 편리하게 하기 위해 tanstack-query를 사용하고 있다.
• 서스펜스를 사용하기 위해 tanstack-query를 사용하고 있다
• 변경되지 않는 데이터를 캐싱된 데이터로 보여주면서 서버의 비용을 절감시킨다
• 생각했던 것보다 useFetch의 장점이 없고, 캐시,스테일 타임을 조절해서 사용한다면 useFetch를 사용할 이유가 없어보여요
• useMutate와 같이 패치하는 커스텀훅을 만들어 사용해도 됩니다. 하지만 이미 tanstack-query를 이용하고 있는 입장에서 tanstack-query의 만들어진 커스텀훅을 사용하지 않고 새로 만들어 사용하는 이유가 따로 없다면 만들 필요가 없어보여요

[inyeong-kang]

어떤 도메인의 데이터가 tanstack query로 fetching 하고자 한다면, 이 데이터와 연관된 도메인도 많아서 자연스럽게 데이터 fetching을 tanstack query를 사용하게 되더라구요..! (ex. 카테고리 목록이 변경됨 -> 게시글 목록도 변경되어야 함)

제 생각에도 tanstack-query가 제공하는 isLoading, isError, error 같은 값을 잘 활용하면.. 커스텀 훅을 만들지 않아도 된다고 생각합니다!

게시글 목록 조회✅

• 무한스크롤에 tanstack-query가 제공하는 useInfiniteQuery hook을 사용하고 있으므로,

게시글 상세 조회✅

• 게시글 상세 조회할 때 투표 수정 기능이 필요해서 tanstack-query를 이용해 낙관적 업데이트를 구현해야 한다고 생각합니다.
  • 물론 낙관적 업데이트를 useFetch를 이용해서 구현할 수도 있겠지만.. 이미 낙관적 업데이트로 구현한 부분(댓글 수정)도 있어서 지금처럼 query를 사용하는 것이 나아보여요.

게시글 작성 (생성, 수정)✅

댓글 목록 (조회, 수정, 삭제, 생성)✅

카테고리 목록 조회

(이부분도 게시글 상세 조회와 동일합니다.)

신고 기능 (게시글, 댓글, 유저)

유저 정보 (조회, 닉네임 수정, 회원 탈퇴)

• staletime과 cachetime 에 대한 세부적인 값은 좀 더 고려해보도록 하겠습니다!
  • 관리자가 관리하는 값들은 이 값들을 길게 가져가는 것이 적절하다고 생각합니다~~

[chsua]

tanstack-query

사용하고 싶다: 투표를 하는 등 어떤 인터렉션이 있을 때 스무스한 처리가 가능함. 변화되지 않는 정보는 캐싱이 가능함.
사용하고 싶지 않다: 생각해보니 새로운 기술에 대한 거부감인 것 같음

어디까지 도입?

전체적으로 도입하는 것에는 동의하나
현재 상황에서 useFetch를 모두 바꾸는 것에는 비동의
상세페이지는 리액트쿼리로 바꾸는 것이 좋겠지만 통계는 지금 하기에 시간이 없음