22.4 Preview Deployments

바로 배포 시키기 전에 preview 할 수 있어야 하겠지?
깃에서 브랜치 따서 push 하면 알아서 배포가 된다.
일단  enter-message라는 이름의 깃 브랜치를 따자.

git checkout -b enter-message

그리고 코드 수정하고 바로 커밋하면

git add .
git commit -m "New Welcome Msg"
git push origin enter-message

브랜치에서 보낸 코드가 빌드 되고, 볼 수 있는 preview 도메인이 생긴다.
그리고 prod로 배포 하려면
promote to production 누르면 끝!



22.5 Limits in Vercel
https://vercel.com/docs/concepts/limits/overview

<Image> 태그 사용할 때만 해당.

Edge Middleware Invocations는 middleware.ts임
한달에 100만회로 제한. 알아서 잘 활용해라.

역시 제한이 있다.

아래로 가면 내 앱의 사용현황을 볼 수 있다.
https://vercel.com/dashboard/usage

근데 serverless function은 revalidate할 때도 카운팅 되기 때문에 조심해라.
https://vercel.com/docs/concepts/limits/usage#invocations

Vercel은 NextJS앱을 배포하는 플랫폼에선 압도적 1위임.

두가지 방식이 있다. NextJS를 활용 하는.
1. 풀스택 프레임워크 - api route, 미들웨어, 서버컴포넌트,image컴포넌트 등 전부 활용
2. getStaticProps 만 사용 - HTML을 생성하는 정적사이트 생성기(SSG)로 사용

2번의 경우 어디에 배포해도 상관 없음. 
1번으로 활용한 경우는 배포할 곳이 Vercel밖에 없음.Netlify, cloudflare, github pages, heroku도 안됨.
NextJS를 만든 곳이니까. 

이제 배포를 해보자.
1. Vercel 가입(github으로 가입하면 편함)하고 https://vercel.com/dashboard로 가자.
create a New Project 누르고

2. git을 import한다.

3. .env에서 사용하던 변수들을 아래에 입력한다.

일단 저기에 DATABSE_URL이 들어가야 하는데
Planetscale가서 보자. connect버튼 누르고. Prisma를 선택하고. 아래 스트링을 넣음 된다.

4. 그리고 빌드하면 에러가 난다.
환경 변수들 다 추가해서 고쳐주고,
빌드가 다 돼도 에러난다.
Uncaught SyntaxError: Unexpected token '<'
Uncaught SyntaxError: Unexpected token '<'
js,css로딩이 안된다. 미들웨어의 문제인듯하다.
stackoverflow 검색결과 middleware.ts파일에 아래를 넣어주니 해결 되었다.

export const config = {
  matcher: "/",
};

the problem is Next.js is making some request to /_next/* and you redirect request to the login page, those are requests are needed and are never finished. You need to avoid redirect any requests made to /_next/*
Next.js가 보내는 /_next/라는 리퀘스트를 내 코드가 login페이지르 리다이렉트 시켜서 그렇단다.
https://stackoverflow.com/questions/73229148/uncaught-syntaxerror-expected-expression-got-while-using-next-js-middlewar






ODR(On Demand Revalidation)
getStaticProps
: 빌드 시 최초 한번만 실행 됨. 그래서 데이터가 담긴 HTML이 생성 됨.
아래처럼 revalidate를 쓰면 페이지가 최신인지 아닌지 판단 가능.
nextjs 내부의 타이머가 20초로 맞춰지고, 그 때 까진 모든 사용자에게 같은 페이지를 보여줌. 20초 이후에 방문자가 오면 그 사람에게 역시 같은 페이지를 보여주고, nextjs 내부에서 새 버전의 페이지를 만듦. 그래서 그 다음 방문자에게 새 버전을 보여줌. 역시 로딩이 필요없지.

export async function getStaticProps() {
  console.log("building comming, statically");
  const posts = await client.post.findMany({ include: { user: true } });
  return {
    props: {
      posts: JSON.parse(JSON.stringify(posts)),
    },
    revalidate: 20,
  };
}

아니면 특정 액션 이후에 revalidate를 동작케 할 수 있다. 
api 폴더 내에 revalidate.ts를 만들고 .env에 나만의 TOKEN을 저장한다.
그리고 api/posts에서 post를 작성 할 때, 특정 TOKEN을 포함한 URL로 request를 날려주면
revalidate.ts에서 토큰을 비교해서 revalidate를 해준다.

 

ISR(Incremental Static Regenertion)
그럼 동적인 페이지들도 정적페이지로 만들수는 없을까? (/products/[id] 페이지의 동작방식에서 구현함.)
getStaticPaths에서 paths에 빈 array를 넘기면 됨.
그러면 아래 사진처럼 products폴더 안에 빨간 박스 부분 없이 build됨.
그리고 /products/1로 최초 request가 오면, 1.html을 생성한다.
그 다음 request에는 이미 생성된 HTML을 주게 되니 로딩없이 바로 페이지가 렌더링된다.
이렇게 incremental하게 static 페이지를 generate하는 방식여서 ISR이라고 부른다.


여기서 fallback 옵션을 어떤 것을 주느냐에 따라
페이지를 생성할 동안 사용자에게 어떤 화면을 보여줄지 정할 수 있다.
true,'blocking',false

export const getStaticPaths: GetStaticPaths = () => {
  return {
    paths: [], //페이지 빌드 할 때 아무런 HTML페이지도 미리 생성하지 않는다는 뜻. 그러나 사용자의 요청에 따라 미리 만들어지기 시작할꺼고, 여기서 fallback이 활용된다.
    fallback: true,
    //GetStaticProps or GetStaticPaths이 있는 페이지에 왔을 때, HTML이 아직 없으면,
    //유저를 잠깐 blocking하고 그동안 백그라운드에서 페이지를 만들어서 유저를 줌.
    //blocking 할동안 유저는 아무것도 못보지
    //이는 딱 한번만 일어남. 기본적으로 SSR임.

    //false면 어떤 페이지든 프로젝트의 빌드과정에서 만들어지는 것만이 가질 수 있는것. 추가하지못함
    //그래서 이 경우 404 return됨

    //true면 page generate될 때 까지 무언갈 보여줌
  };
};

1. fallback: true
router에 접근해서 router.isFallbck이라는 변수를 이용해서 페이지 생성 동안 대신 보여줄 html을 지정해준다.

참고로 ISR 이면 위 코드에서 GET방식의 /api/products/ 컨트롤러는 필요 없겠지. 이미 생성된 페이지를 보여주기 때문에. POST는 데이터 변경해야 하기 때문에 필요하고.

2. fallback: false
404 페이지가 리턴됨. 
프로젝트가 build 될 때 생성된 페이지들만 보여준다는 뜻임.

3. fallback: 'blocking'
GetStaticProps or GetStaticPaths이 있는 페이지에 왔을 때, HTML이 아직 없으면,
유저를 잠깐 blocking하고 그동안 백그라운드에서 페이지를 만들어줌.
blocking 할동안 유저는 아무것도 못봄. 이는 딱 한번만 일어남. 기본적으로 SSR임.


참고 할 것들.
ISR은 user의 정보에 의존적인 페이지(account,profile,dashboard 등)에는 적합하지 않음.
사용자별로 페이지를 만들어 놓는게 불가능하니까.
이 때는 그냥 normal fetching을 사용해야 함.

그리고 SSR(getServerSideProps)은 DB가 빠르면 고려해볼만 하다. 다만 blank 페이지를 보게되겠지.




20.7 Code Challenge
community/[id] 부분을 
getStaticProps, getStaticPaths, 그리고 fallback을 사용해서 HTML로 만들어봐.
필요할 때, revalidate도 해야하고.
궁금해요 기능을 위해서 SWR도 해야 함. profile/index에서 사용했었음. 이거 똑같이 하면 됨.

20.0 Introduction

ISR = 단계적 정적 재생성
NextJS에서 최고의 기능!!

페이지를 렌더링하는 방법들
1. CSR - 완성된 초기 html먼저 보여줌, ReactJS가 데이터 알아서 불러오고.
2. SSR - all or nothing, 완성된 HTML 보여주고, ReactJS는 필요없음.(getServerSideProps)
3. 빌드 될 때 파일 미리 생성해두기(getStaticProps, getStaticPath), interaction없는 static page(F&Q 같은 곳)에 사 - 직전 포스트의 내용

이제는 페이지 불러 올 때 getServerSideProps없이도 로딩상태를 완전히  안보여줄 수 있다.


20.1 ISR part One
ISR사용하면 로딩 안보이고, 서버에서 렌더링 할 필요 없음(getServerSideProps사용 안함). 페이지 즉시 불러 올 수 있음.
유저가 페이지 열면 서버단에서 렌더링 되는게 아님. 이미 랜더링 된 상태.

getStaticProps()의 return 객체에 revalidate에 시간(초)을 넣으면
그 시간마다 페이지가 다시 빌드 됨.

export async function getStaticProps() {
  console.log("building comming, statically");
  const posts = await client.post.findMany({ include: { user: true } });
  return {
    props: {
      posts: JSON.parse(JSON.stringify(posts)),
    },
    revalidate: 20,
  };
}
export default Community;

좀더 정확히 말하면,
1. revalidate에는 20초라는 타이머가 설정되고
2. 유저 몇명이 오든 20초 안에 오면 같은 버전의 페이지를 보여줌.
3. 그리고 20초가 지나서 유저가 오면, 여전히 2번의 유저들과 같은 페이지를 보여주지만, 이 때 revalidate를 해서 다시 빌드를 시작한다.
4. 그리고 그 다음에 온 유저는 그 빌드된 새 버전의 페이지를 보게 됨.
즉, revalidate시간이 지나도 사람 안오면 굳이 빌드 안함.
https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration

이를 테스트 해보려면 npm run dev로는 안됨.
개발자 모드이기 때문에 계속 최신 화면 보여주기 때문. 
그러니 npm run build 하고, npm run start해야 함.

19.13 Dynamic getStaticProps

일단 설치

npm i unified remark-parse remark-html

https://www.npmjs.com/package/remark-html

설치하고 아래처럼 사용하면 된다.

import { unified } from "unified";
import remarkParse from "remark-parse/lib";
import remarkHtml from "remark-html";


getStaticPath를 통해 파일 읽고, 파일 이름 읽어서 params에 {slug:name} 객체를 전달한다.
이것들을 페이지로 만들어주세요~하는거지

그러면 getStaticProps에서 context객체를 통해 위 params에 접근 가능하게 되고, 
슬러그 id들을 접수 받고, 이 슬러그(post)들을 HTML로 바꿔주고
화면을 그린다. 아래 사진 참고.

아래는 결과물

 

19.14 Inner HTML
ReacJS는 위처럼 받은 데이터가 html태그여도 그냥String으로 받는다.
보안에 상당히 취약하기 때문이다. 댓글로 <script>태그를 넣어 사용자 정보를 빼올 수도 있다.
그러니 이를 막아놨다.
다만 위 경우, data source를 신뢰 할 수 있기 때문에 dangerouslySetInnerHTML이라는 옵션을 사용하면 된다.
dangerouslySetInnerHTML은 브라우저 DOM에서 innerHTML을 사용하기 위한 React의 대체 방법,__html 키로 객체를 전달한다.

참고, css파일에서 @apply를 사용하면 tailwind 문법 사용가능하다.

19.15 Recap
getStaticProps가 잘 동작하는지 보려면, .next 폴더 지우고 build다시 해야 함.
getStaticProps처럼 페이지 빌드할 때 미리 다 해놓는걸 Backend or CRM or Admin pannel 이라고 부른다(?)

이번에는 세션을 어떻게 가져올거냐?
핵심은 NextPageContext

19.6 getServerSideProps

NextJS 데이터 fetching을 어떻게 하나?

유저에게 화면을 어떻게 보여줄지는 두가지로 나뉜다.
1. 다 로딩되면 한번에 보여주자. SSR (server side rendering)
2. 로딩 전에 뭐라도 보여주자. CSR (client side rendering)

1번 방식을 구현하려면 getServerSideProps()를 사용하면된다.
페이지에서 getServerSideProps(서버 측 렌더링)라는 함수를 export 하면 Next.js는 getServerSideProps에서 반환된 데이터를 사용하여 각 요청에서 이 페이지를 미리 랜더링한다고함.

useSWR을 안쓰고 index.tsx에 getServerSideProps()를 다음과 같이 넣어주면
서버에서 먼저 실행한다. 그럼 잘 작동하는데 이 때 useSWR의 다양한 기능을 못씀.
static optimization이나 cache 못함.
그리고 getServerSideProps() 실행 도중 에러나면 아무것도 보지 못한다.

export async function getServerSideProps() {
  const products = await client.product.findMany({});
  console.log(products);
  return {
    props: {
      products: JSON.parse(JSON.stringify(products)),
    },
  };
}

이제, 서버사이드랜더링 + useSWR사용을 알아보자.

19.7 SSR + SWR
위 방식 만으로 prototype
페에지는 SSR로 불러오지만, 클라이언트 단에서 페이지 열릴 때 useSWR이 백그라운드에서 API로 최신 데이터 불러서 업데이트 하는 것.

이 예에서는 getServerSideProps()에서 product의 count를 불러오지 않음.
새로고침 하면 SSR로 한번에 뜨는데
나중에 SWR에서 API로 불러온 product의 count가 업데이트 됨.


여러개도 됨

<SWRConfig
      value={{
        fallback: {
          "/api/products": {
            ok: true,
            products,
          },
        fallback: {
          "/api/user": {
            ok: true,
            products,
          },
        },
      }}
    >
      <Home />
    </SWRConfig>



import Document, { Head, Html, Main, NextScript } from "next/document";

class CustomDocument extends Document {
  render(): JSX.Element {
    console.log("Document is running");
    return (
      <Html lang="ko">
        <Head>
          <link
            href="https://fonts.googleapis.com/css2?family=Noto+Sans+KR&display=swap"
            rel="stylesheet"
          />
        </Head>
        <body>
          <Main></Main>
          <NextScript></NextScript>
        </body>
      </Html>
    );
  }
}

export default CustomDocument;
//NextJS앱의 html 뼈대를 짜주는 역할
//안의 Main은 Nextjs가 앱 컴포넌트를 랜덩링 해주는 것.
//HTML 뼈대를 짜주는 역할을 하는 파일이라 서버에서 단 한번 실행 됨.
//<Main>안에서 _app.tsx가 들어간다.

_document.tsx의 역할.
이 페이지는 단 한번 렌더링 됨.
그리고 아래 html은 크롤라나 bot이 올 때 이미 완성되어있다. SEO에 좋다.

아래는 위치

 

_document.tsx


NextJS의 폰트 최적화는 구글 폰트에 한정되어있기 때문에 구글폰트 링크를 써야 함.
어떻게 최적화 해줄까?
개발자모드에선 확인 안됨.
빌드해야 함

일단 구글폰트를 불러오는 링크(<linkhref="https://fonts.googleapis.com/css2?family=Noto+Sans+KR&display=swap"rel="stylesheet"/>)에는 폰트를 불러올 링크들이 또 있다.
따라서 빌드 시에 이 링키들을 열어서 한군데 모아줌. 그러니 이미 폰트들을 불러와 두는거지. 두단계를 건너 뛴다고 보면 되나? 꽤나 도움이 될듯하다.

 

+ Recent posts