본문 바로가기

Next.js

Next.js 2-2. getServerSideProps(SSR)

  • getServerSidePrsop는 언제 실행될까?

  getServerSideProps는 서버 측에서만 실행되며 브라우저에서는 실행되지 않는다. 페이지에서 getServerSideProps를 사용하면 이 페이지를 직접 요청할 때 getServerSideProps가 실행되며 이 페이지는 반환된 props로 미리 렌더링 된다.

  또 이 페이지가 next/link 또는 next/router를 통한 전통적인 client-side 페이지인 경우, Next.js는 getServerSideProps를 실행하면서 서버로 API 요청을 보낸다. 그리고 getServerSideProps는 페이지를 렌더링 하는 데 사용할 JSON을 반환한다. 이 모든 작업은 Next.js에 의해 자동으로 처리되므로 추가적으로 getServerSideProps를 정의할 필요는 없다. 

  getServerSideProps는 page로부터만 export 될 수 있다. page가 아닌 파일로부터는 안된다. getServerSideProps는 독립적으로 실행 함수로만 export 될 수 있다. 즉, getServerSideProps를 페이지 컴포넌트의 속성으로 추가하면 작동하지 않는 것이다. getServerSideProps API 레퍼런스는 getServerSideProps와 함께 사용할 수 있는 모든 파라미터와 props를 커버한다.

 

 

  • 언제 getServerSideProps를 사용해야 할까?

  getServerSideProps는 요청 시 데이터를 가져와야 하는 페이지를 렌더링해야 하는 경우에만 사용가능하다. 이는 request 데이터 또는 속성(예: authorization 헤더나 지리적 위치)의 특성 때문일 수도 있다. getServerSideProps를 사용하는 페이지는 요청 시 서버 사이드 렌더링되고 cache-control 헤더가 구성된 경우에만 캐시 된다. 요청 중에 데이터를 렌더링 할 필요가 없으면 클라이언트 측 또는 getStaticProps에서 데이터를 가져오는 것을 고려해야 한다.

 

 

  • getServerSideProps 또는 API 경로

  서버에서 데이터를 가져온 다음 getServerSideProps에서 해당 API Route를 호출하려는 경우 API Route에 도달하고 싶을 수 있다. 이것은 불필요하고 비효율적인 접근 방식이다. 왜냐하면 서버에서 실행 중인 getServerSideProps 또는 API routes가 서버에서 실행되는 것으로 인해 과한 요청의 원인이 될 수 있기 때문이다.

  예를 들어, CMS로부터 특정 데이터를 부르는 데 사용하는 API route가 있다고 하자. 그 API route는 getServerSideProps에서 직접 호출된다. 이렇게 하면 추가 호출이 발생해 성능이 저하된다.

 대신 API route 내부에서 사용하는 로직을 직접적으로 getServerSideProps에 import 할 수 있다. 이것은 CMS, db 또는 그 외 API를 getServerSideProps안에서 직접적으로 호출할 수 있다는 것을 의미한다.

 

 

  • 클라이언트 측에서 데이터 가져오기

  페이지에 자주 업데이트되는 데이터가 포함되어 있고 데이터를 사전 렌더링할 필요가 없는 경우 클라이언트 측에서 데이터를 가지고 올 수 있다. 이에 대한 예시는 아래와 같다.

  먼저, 데이터가 없는 페이지를 즉시 표시한다. 정적 생성을 사용하여 페이지의 일부를 사전 렌더링할 수 있다. 누락된 데이터의 로드 상태를 표시한다. 그런 다음 클라이언트 측에서 데이터를 가져와 준비되면 표시한다.

  이와 같은 접근 방식은 사용자 대시보드 페이지에 적합하다. 대시보드는 비공개의 사용자별 페이지이므로 SEO와 관련이 없으며 페이지를 사전 렌더링할 필요가 없다. 데이터는 자주 업데이트되므로 요청 시 데이터를 가져와야 한다.

 

 

  • SSR(서버 측 렌더링)을 사용한 캐싱

캐싱 헤더(Cache-Control) 내부를 사용하여 getServerSideProps의 동적 응답을 캐싱할 수 있다. 예를 들어 stale-while-revalidate를 사용하는 것이다.

// 이 값은 10초 동안은 fresh한 것으로 간주된다. (s-maxage=10)
// 다음 10초 이내에 요청이 반복되면 이전으로 돌아가 캐시된 값은 여전히 최신 상태이다. 
// 만약 요청이 59초 전에 반복되는 경우라면
// 캐시된 값은 오래되었지만 여전히 렌더링된다. (stale-while-revalidate=59)
//
// 백그라운드에서 캐시를 채우기 위한 재검증 요청이 이뤄진다.
// fresh한 값으로 페이지를 새로고치면 새 값이 표시된다. 
export async function getServerSideProps({ req, res }) {
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=10, stal-while-revalidate=59'
  )

  return {
    props: {},
  }
}

 

 

  • getServerSideProps는 오류 페이지를 렌더링 할까?

  만약 getServerSideProps안에서 에러가 던져지면 이것은 pages/500.js 파일로 보인다. 개발 중에는 이 파일이 사용되지 않고 개발 오버레이가 대신 표시된다.

 

참조: https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props

 

Data Fetching: getServerSideProps | Next.js

Fetch data on each request with `getServerSideProps`.

nextjs.org

 

'Next.js' 카테고리의 다른 글

Next.js 4-1. getSaticPaths  (0) 2023.04.24
Next.js 3-2. getStaticProps (SSG)  (0) 2023.04.21
Next.js 3-1. getStaticProps (SSG)  (0) 2023.04.21
Next.js 2-1. getServerSideProps(SSR)  (0) 2023.04.19
Next.js 1. 왜 Next.js인가?  (0) 2023.04.18