해결된 질문
작성
·
109
0
안녕하세요.
강의를 전부 수강한 수강생입니다.
강사님의 강의를 보다가 궁금한 것이 있어서 질문 남깁니다.
강의에서는 API 요청 방식을 fetch를 사용하여 전부 Next 서버에서 요청을 보내는 방식이던데 클라이언트 컴포넌트에서 fetch를 사용하여 브라우저를 통해 요청하는 방법과 강의와 같이 사용하는 방법, API Route(Handle) 방식을 사용하는 방법의 차이를 알 수 있을까요??
또한 Next 서버의 부하는 괜찮은지 궁금합니다.
답변 1
1
안녕하세요 이정환입니다.
3가지 데이터 페칭 방식을 항목별로 정리해볼게요!
1) 서버 컴포넌트에서 fetch 메서드 사용해 데이터 요청
사전 렌더링 중 Next.js 서버가 백엔드 서버에게 데이터를 요청합니다.
사전 렌더링 중에 데이터가 페칭되므로 초기 HTML에 데이터를 포함할 수 있습니다. 이는 브라우저에서 데이터를 요청하는 다른 방식에 비해 FCP 측면에서 이점이 됩니다.
사전 렌더링 과정이 길어지게 될 경우 Next.js 서버 측에 부하가 발생할 수 있습니다.
위 부하는 적절한 캐싱(풀 라우트 캐시, 데이터 캐시 등)으로 어느정도 해결 가능합니다.
2) 브라우저에서 백엔드 서버에게 직접 데이터 요청
브라우저 -> 백엔드 서버로 직접 데이터가 요청됩니다.
브라우저에 컴포넌트가 마운트 된 이후 데이터 요청이 시작됩니다.
로딩 상태를 처리해야 하며, 데이터 요청이 시작되는 타이밍이 1번에 비해 느립니다. 따라서 FCP, LCP가 비교적 느릴 수 있습니다 (실제 데이터가 뜨는 속도가 느리다는 뜻)
Next.js 에서 제공하는 캐싱 기능을 활용할 수 없습니다. 따라서 사용자가 많이 접속하면 그만큼 많은 데이터 페칭이 백엔드 서버에게 발생하게 됩니다. 이 경우 백엔드 서버의 부하 문제가 발생할 수도 있습니다. (백엔드만의 캐싱 기법으로 해결해야 합니다)
3) 브라우저에서 Route Handler(API Routes)를 통해 Next.js 서버에게 데이터 요청
브라우저 -> Next.js 서버 -> 백엔드 서버 로 데이터가 요청됩니다.
2번과 마찬가지로 브라우저에 컴포넌트가 마운트 된 이후 데이터 요청이 시작됩니다.
마찬가지로 로딩 상태를 처리해야 하며, 데이터 요청이 시작되는 타이밍이 1번에 비해 느립니다. 따라서 FCP, LCP가 비교적 느릴 수 있습니다 (실제 데이터가 뜨는 속도가 느리다는 뜻)
Next.js에서 제공하는 캐싱 기능을 일부 이용할 수 있습니다 (데이터 캐시 사용 가능) 그러나 브라우저에서 Next.js 서버로 향하는 데이터 요청 자체는 발생함을 유의해야 합니다.
만약 Next.js의 데이터 캐시가 작동하지 않을 경우 데이터 요청이 가장 오래 걸릴 위험이 있습니다. (2번을 거쳐가야 하기 때문)