static rendering /dynamic rendering / cache

---

서버 배포

1. Next.js 서버를 배포하기 위해서 아래와 같은 명령어를 입력한다.

npm run build

=> 서버에 올릴 html을 미리 만들어주는 작업이다.

---

 

static rendering / dynamic rendering

build 작업을 거치면 해당 화면을 볼 수 있는데,

=>ㅇ기호 : static rendering 방식이고,

=> λ기호 : dynamic rendering 방식이다.

 

fetch와 같이 데이터를 주고받는 함수의 유무에 따라서 빌드작업 이후

각각 static / dynamic 으로 랜더링 방식이 정해진다.

static rendering 의 경우는 데이터의 변화를 감지하지 못한 채 정적페이지로 남게 된다.

반대로 dynamic rendering은 데이터의 변화를 감지하면, 동적으로 페이지가 랜더링이 되는 것이다.

 

=> 즉 빌드작업을 할 때 html을 그려주는 작업을 dynamic 하게 동적으로 해준다는 얘기.

 

하지만, 개발자의 의도에 맞지 않게 build가 되어서, rendering 방식이 잘못 정해진다면,

우리는 수동으로 rendering 방식을 바꿔줘야 할 필요가 있다.

---

랜더링 방식을 바꿔보자

1. 바꿀 폴더의 page.js를 들어간다.

2. 아래 코드를 작성한다.

export const dynamic = 'force-dynamic'

=> 정적 페이지를 동적페이지로 바꾸기 위한 코드이다.

정적으로 바꾸고 싶다면 dynamic 부분을 static을 넣으면 된다.

 

3. 다시 빌드 작업을 한다.

npm run build

 

4. /list가 dynamic rendering (λ기호)로 바뀐 것을 확인할 수 있다.

---

캐싱

dynamic rendering 방식은 데이터의 변화가 있을 때마다 계속 html을 그려야 해서 서버에 부담이 있기 마련이다.

그렇다고 정적페이지는 싫다면,  시간마다 랜더링을 해주는 것도 좋은 생각이다.

=> 그것은 바로 캐싱기능을 사용하는 것이다.

export const revalidate = 60;

원하는 정적 페이지(static rendering)에 해당 코드를 작성하면, 서버에 배포를 하더라도 60초마다 rendering이 된다. 

=> 사이트에 방문자가 있을 경우만 해당. 즉 GET요청이 들어올 때.

---

배포한 서버로 브라우저 열기

npm run start

build 작업을 하면 dev가 아닌 start로도 브라우저를 실행시킬 수 있다.

=> 정적페이지에 데이터구조가 빌드 후에 변화가 있다면 배포된 후라 데이터가 배포 전 그대로일 것이다.

---

왜 다들 next.js를 우대하는지 실감이 나기 시작했다.

빠르고, 유연하며 서버과부하도 줄일 수 있고, 심지어 금전적인 부담까지 덜 수 있기에

현실적으로 와닿는 프레임워크라고 생각한다.