Next.js로 프로젝트 중인데, 팀원과 의견조율이 잘 안돼서 도움 부탁드립니다.

Question

안녕하세요, 저는 백엔드 개발자로 일한지 이제 2년차가 된 개발자입니다. 사이드프로젝트에서는 프론트 개발을 하고 있고 현재 Next.js를 사용하고 있습니다. 백엔드팀도 따로 있어서 Next.js의 API routes는 BFF같은 느낌으로 사용하고 있습니다. [Next pages] <-> [Next API] <-> [백엔드 서버] 현재 상황은 유저의 로그인정보를 어떻게 관리하냐로 이야기를 하고 있습니다. 1. 마이페이지 -> 프로필 수정 페이지 2. 로그인 -> 메인페이지 이렇게 유저의 프로필 정보가 많이 쓰이다보니까 이걸 매번 GET해서 가져올까, 전역상태로 관리할까 이야기를 하는데 좀처럼 의견이 좁혀지지가 않는 상황이라 다른 분들의 의견을 여쭙고 싶습니다. (참고로 저희 둘 다 프론트 개발경험이 그리 많지 않습니다) A: 그냥 매번 GET하자.(넥스트 API 캐싱을 사용하자) - 전역상태관리보다 코드 복잡도가 줄어들 것 같다. - 넥스트의 API 최적화를 사용하는 게 더 Next스러운 방식같다. B: 전역 상태로 관리하자. - useEffect로 현재 모든 GET 요청을 하고 있기 때문에 윌업데이트에 변경이 일어나면 재렌더링이 일어남 - (하지만 컨텍스트 정보가 바뀌지 않으면 최초 렌더 이후 리렌더 되지 않음) - 캐싱한 데이터를 받아오더라도 결국 불필요한 api요청을 보내는 것이며 api요청을 보내는 것보다 전역 상태에서 가져다 쓰는 것이 더 바람직하지 않나 서로 비슷한 실력에 사람도 둘 밖에 없어서 결정을 내리기 힘들어서, 다른 분들의 의견을 좀 들어보고 싶습니다. 읽어주셔서 감사합니다.

김현우 · Accepted Answer

아래 의견으로 2. 전역상태 투표했습니다.
제 주관적인 의견입니다.

- http 요청 캐싱은 수정이 일어나지 않는 리소스에 대해서만 동작하는게 깔끔해 보입니다.
- 메인페이지에서 get -> 여러 페이지에서 공유 -> 프로필변경페이지에서 patch 의 흐름으로 보이니 페이지마다 프로필정보를 get하는 코드를 작성하는건 전역상태로 관리할 때보다 코드가 불필요하게 길어지고 반복되지 않을까 싶습니다. 더군다나 이러한 데이터 흐름은 제가 전역상태를 사용하는 흐름과 동일해요.

제임스Web · Answer

가위바위보리자드스팍 으로 결정하시죠

아무래도 좋은걸로 고집부리지맙시다

K · Answer

사실 다른 요소들을 더 고려할 필요가 있습니다.
백엔드 개발을 같이하시니, 
- 트래픽이 얼마나 많은지
- 유저정보를 가져오는 작업의 오버헤드가 얼마나 되는지
등 백엔드의 요소를 고려해보면 답이 나올 것 같습니다.

과부하를 발생시키는 요인이 없고, 네트워크 비용을 고려하지 않겠다면 유저정보가 필요할 때마다 불러오는게 나아보입니다.

이보성 · Answer

두 의견을 조합하면 API라이브러리를 사용할 수 있을 것 같습니다. swr과 같은 라이브러리를 사용해서 클라이언트 단에서 API의 응답결과를 캐싱하고 재사용할 수 있습니다.

김하늘 · Answer

보편적인 방법은 useSession을 만들거나 nextauth의 useSession을 이용하는 게 아닐까 싶어요.

세혁 · Answer

프론트엔드 학생이라 도움이 될까 싶긴하지만
최근 사이드 프로젝트에서

유저 정보를 nextAuth session으로 관리하고
로그인 유무가 필요한 경우에 대해서는 프론트엔드 session 정보를

그 외 유저 상세 데이터 조회 및 수정에 대해서는
GET 과 함께 nextAuth 백엔드 api를 활용했습니다.
( 프론트엔드 session user id 를 GET 에 같이 보내도 되지만 데이터 변형등 보안문제를 생각해 백엔드 session 정보를 사용했습니다. )

김병훈 · Answer

잘 작동만 한다면  매번 바꾸면 오류들도 더 많이 해결해야해서 복잡해요

덕 · Answer

저는 불필요한 서버 통신은 최소화하는 게 사용성 측면이나 비용 측면이나 좋다고 생각하는 편입니다
기본적으로 컨텍스트로 관리하고 서버 호출이 필요한 경우에 따른 로직을 짜는 식으로...
데이터의 종류와 사용처에 따라서 구분해야하지 않나 싶네요

pabami · Answer

넥스트는 안 써봤지만
리액트와 nodejs, mysql 쓰고 있습니다.

로그인용 유저 db는 최소 정보로 로그인 전용 및 authentification으로 쓰고
프로필 같이 유저 정보는 따로 db 만든 것을 로그인 유저계정에 조인해서 불러와서 씁니다.

로그인용은 전역으로 쓰고
프로필용은 매번 get 합니다.

방준우 · Answer

클라에서 api 바로 접근해도 되면 리엑트 쿼리로 캐싱하고 매번 get 하는게 더 좋을 거 같고 > 전역 상태효과 겸 BFF 인터페이스 유지에 용이
next 서버 캐싱은 서버 접속이기 때문에 최대 성능에 영향을 주니 매번 접근은 지양하는게 좋을거 같다고 생각이 드네요

장필수 · Answer

여러 브라우저에서 로그인한 상태로 프로필을 수정했을때  다른 브라우저에 변경된 내용을 반영시키려면  어려울 것 같아 저는 1번을 선택했습니다

상현 · Answer

useEffect에서 요청을 하고 있다면 CSR이고, react가 담당하는 것이며,

next.js의 캐시는 http 프로토콜의 표준 캐시 컨트롤을 사용하는 것으로 그 위치를 보통은 getServerSideProps에 놓기에 SSR인 점이 현재 동작과 다릅니다.

현재는 해당 프레임워크를 쓰는 목적과 로직의 동작 형태가 서로 이어져 있지 않은 거겠죠.

캐싱이 목적이라면 csr 방식을 유지하고 react-query를 사용하여 실제 요청을 줄일 수 있습니다.

state로 관리하는 가장 큰 이유는 spa 동작 방식을 따라가기 위함입니다. router.refresh, router.replace가 pages router에서는 서로 다른 페이지 이동처럼 화면에 블링크가 일어나기 때문에 state에 넣어두고 ajax 방식으로 뷰를 전환해서 유려하게 보이려는 목적이 있는 거죠.

app router 기반이라면 이 page transition에 보다 많이 자유롭습니다.

문서 탐색을 더 해보세요.

짹 · Answer

저는 nextAuth 써서 useSession 사용하는데 깔끔합니다.