Next.js 가 제시하는 3 + 1 가지 Data Fetching 방법

• SSR
• CSR
• SSG
• ISR

SSR (Server Side Render)

• 서버가 그린다
• 그린다: 데이터를 가져와서 그린다
• 서버가 그린다: 서버에서 데이터를 가져와서 그린다

  SSR을 담당하는 함수

  • getServerSideProps

export async function getServerSideProps() {
  console.log("server");
  // 객체 형식으로 props를 꼭 return 시켜줘야한다
  // 컴포넌트로 props를 전달
  return {
    props: { time: new Date().toISOString() },
  };
}

CSR (Client Side Render)

• 클라이언트가(브라우저) 그린다
• 그린다: 데이터를 가져와서 그린다
• 클라이언트가(브라우저) 그린다: 클라이언트가(브라우저) 데이터를 가져와서 그린다

  CSR을 담당하는 함수 따로 없다

SSG (Static-Site Generation)

• 정적인 사이드를 생성한다

• 생성한다: 데이터를 가져와서 그려둔다

• 정적인 사이트를 생성한다: 정적인 사이트 데이터를 가져와서 그려둔다

• 개발환경에서는 SSG가 제대로 동작하지 않는다.(개발환경에선 SSG가 꼭 SSR 처럼 동작한다)

• SSG가 동작하는걸 보려면 build를 해야한다.

  SSG을 담당하는 함수

  • getStaticProps(with getStaticPaths)

    export async function getStaticProps() {
      console.log("server");
      // 객체 형식으로 props를 꼭 return 시켜줘야한다
      // 컴포넌트로 props를 전달
      return {
        props: { time: new Date().toISOString() },
      };
    }

  • * SSG는 build되는 시점에서 데이터를 가져와서 정적 사이트를 만들어논다

  • SSR과의 차이첨은 SSR은 페이지 접근시마다 데이터를 가져와서 그리지만 SSG는 build되는 시점에서만 데이터를 가져와서 정적 페이지를 구성한다

  • 정적인 사이트를 구성할때 좋다(서버 부하를 줄일수있음) ex: 블로그, 안내페이지...

  • getStaticPaths

    // dynamic route 사용시 정적으로 생성할 Paths를 getStaticPsops에 전달한다.
    export async function getStaticPaths() {
      // 예시
      const post = await fetch("https://www.exmple.con/posr")
      const res = JSON.stringify(post)
      const paths = res.map(itm => ({
        params: { id: itm.id }
      })
      
      // paths(required) Array
      // falback(required)
      return {
        /*
      	/post/[id].ts 경로일경우 params객체에 꼭 id parameter 가 필수로 있어야한다
      	/post/[...slug].ts 경로일경우 params객체에 꼭 slug배열이 필수로 있어여한다		
        */
        paths,
        /*
    	 -----------------------------------------------------------                              
      	 빌드 타임에 생성해놓지 않은 path로 요청이 들어온 경우 어떻게 할지
         정하는 boolean 또는 'blocking' 값이다
         
         - false 인 경우
         	  getStaticPaths가 반환하지 않은 모든 path에 대해서 404 페이지 반환
         	  *사용 예시
              	- 적은 path만 사용할 경우
                - 새로 페이지가 추가 될 일이 적을 경우
                - 새로운 페이지 자주 추가시 추가될때마다 다시 빌드해야함
         - true 인 경우
         	  정해지지 않은 path에 대해서 404페이지를 반환하지 않고 요청이 들어올시 첫 요청에서만 
              getStaticProps를 호출하여 미리 정의되어있는 path 리스트에 추가하고
              페이지가 랜더 되기전까지 fallback loading 화면을 띄우고 페이지를 랜더
              시킨다
              
              * "fallback" loading 화면은 router.isFallback 체크를 통해
                화면을 지정 할 수 있다 !지정하지 않으면 빌드시 에러발생
                ex) if(router.isFallback) {
                  return <div> Loading... </div>
                }
          - blocking 인 경우
          	  true일 때와 비슷하지만 페이지 생성중에 사용자에게 fallback 화면을 보여주지 않는다 
              SSR 처럼 동작해서 아무것도 미리 보여주지 않음
              fallback 화면을 정의해주지 않아도 된다
      	 */
        falback:'false'
      }
    }

ISR (Incremental Static Regeneration)

• 증분 정적 사이트를 재생성 한다

• 재생성한다: (특정주기로) 데이터를 가져와서 다시 그려둔다

• 증분 정적 사이트를 재생성한다: (특정 주기로) 정적인 사이트 데이터를 가져와서 다시 그려둔다

  ISR을 담당하는 함수

  • • getStaticProps(with revalidate)

      export async function getStaticProps() {
       console.log("server");
       return {
         props: { time: new Date().toISOString() },
         // revalidate 특정주기(몇초마다 데이터를 다시 그릴레)
         revalidate: 1,
       };
      }

  • SSR + SSG 에 장점만 모아놓은 데이터 패칭 방식
  • 데이터에 변화가 자주 일어나는 페이지에 사용

Pre-render 와 SEO

• Next.js는 모든 페이지를 기본적으로 pre-render(미리그려 놓는다) 한다.

• Pre-rendering과 SEO의 상관관계

  • CSR만 제공한다면, javascript를 읽을수 없는 검색엔진은 아무런 데이터도 조회해갈 수 없다
  • Pre-render를 해두면 javascript를 읽을수 없는 검색엔진도 title, image, 등등 을 통해서 필요한 데이터를 제공 가능

• Next.js 의 Pre-rendering 방식 ?

  • SSG(recommended) & SSR

  • Next.js 에서는 SSG를 적극 권장 이유는 SSG는 빌드 타입에 pre-render 하기 때문에
    서버에 부하가 덜 하다.

  • SSG는 빌드 타임에 pre-render

  • SSR은 요청 타임에 pre-render

• SSG 2가지 상황

  • Page의 내용물이 외부 데이터에 의존적인 상황
  • getStaticProps만 가지고도 가능
  • Page Paths 까지 외부 데이터에 의존적인 상황
  • getStaticPaths도 함깨 활용해야 가능

Layouts(여러 Page들의 공통 처리)

• 하나의 공통된 Layout을 쓰는 경우 components/Layout.js
  컴포넌트 하나를 pages/_app.js 에서 활용하면 된다

Router

• NextJs의 Router는 file-system 기반
  pages/ 혹은 src/pages/

  slug

  • pages/category/[slug].js => /category/:slug (ex. /category/food)
  • pages/[username]/info.js => /:username/info (ex. /kimjh/info)

  ...slug

  • pages/cart/[...slug].js => /cart/* (ex. /cart/2023/02/20)

  옵셔널 slug

  • pages/cart/[...slug].js /cart 로 접근하면 뒤에 아무것도 없기때문에 404가 뜬다.
  • pages/cart/[[...slug]].js 해주면 /cart 로 접근시 뒤에 slug가 없어도 cart로 이동한다.

  Shallow Routing

  • getServerSideProps / getStaticProps 등을 다시 실행시키지 않고,
    현재 상태를 잃지 않고 url을 바꾸는 방법

    url을 바꾸는 3가지 방식

    • location.replace("url") : 로컬 state 유지 안됨(ReRender)
    • route.push(url) : 로컬 state 유지 / data fetching 실행됨
    • route.push(url, as, { shallow: true }) : 로컬 state 유지 / data fetching 실행안됨

API Routes

Router의 slug 기능을 똑같이 사용할 수 있다.

API Middlewares

Request

• request.qurey
• request.cookie

Response

• response.status(code)
• response.json(body): serializable object
• response.redirect(code, url)
• response.send(body): string / object / Buffer