Next.js SSG에서 SSR로 변환, Cache-Control 별도로 지정하기

이번 프로젝트를 하면서 정말 많은걸 경험하고 배우게 되었다.

규모가 크기도 했지만 SSR, CSR 관련해서도 다시한번 정리가 되었고,

프로젝트가 끝난 후 QA를 진행하고 생각하지도 못했던 에러들을 만나고 수정했다.

 

그 중에서도 처음에는 원인을 찾지 못했던 에러가 있다.

 

- 웹페이지의 일부분을 코드 스니펫으로 나타나고 있었다.

장시간동안 페이지를 켜두거나 재시동 또는 다시 시작을 한 후 사용하던 페이지가 열리면 이렇게 에러가 발생했다.

만약 router로 다시 그 페이지에 접근하게 되더라도 이러한 문제가 발생했다. 

 

SSR로 작업을 했지만 SSG로 빌드되었고, 정적인 파일로 동작을 하다보니 미리 서버측에서 가져온 HTML파일을 생성하다보니 그 뒤에는 서버와 연결이 되지 않아서 나오는 문제인걸로 파악했다.

 

우선적으로 서버상태관리를 리액트쿼리를 사용했고 Next에서 지원하는 fetch, swr, NextAuth를 사용하지 않았기 때문에 발생한 문제이기도 하다.. 프로젝트 이전에 설계단부터 급하게 들어가다보니 생긴 문제인거 같아서 더 아쉽다.

 

 

그래서 문제를 정리하자면

처음부터 SSG로 처음부터 만들지 않았고, SSR로 만든 페이지가 SSG로 나오는것이 문제였다.

이 외에도 CSR로 작업한 페이지 렌더링 방식은 SSG로 나오기 때문에 이또한 문제가 되었다.

 

 

File Conventions: Route Segment Config | Next.js

그렇게 Next.js 공식문서에서 찾은 해결방법!

 

Next.js 13에서 따로 use client를 작성하지 않으면 서버페이지로 진행되는줄 알았지만 그게 아니였다.

Cache-Control 별도로 지정해주어야 했다.

 

그래서 해결 방법은? 2가지이다. SSR, CSR에 적용해주어야하는 방법은 달랐다.

 

첫번째 SSR에서 SSG로 나올때

export const dynamic = "force-dynamic";

- 이렇게 dynamic변수에 따로 force-dynamic를 지정해주게되면 동적이지는 않지만 요청이 올때마다 수행하도록 SSR로 동작한다.

 

export const revalidate = 0;

- Next에서는 revalidate를 페이지마다 설정할 수 있었다. 기본값은 false이기 때문에 따로 설정하지 않으면 SSG로 동작한다.

- 0으로 설정을 하면 SSR처럼 요청이 올때마다 만들어지기 때문에 계속 발생한 에러처럼 코드스티펫이 나타나지 않게 할 수 있다.

* 따로 초단위로 작성이 가능한데 그렇게 하면 초 간격으로 ISR을 사용할 수 있다.

 

---

수정코드 적용 전,후 페이지 렌더링 방식

- SSG로 페이지 렌더링 되던 것들이 이제는 SSR로 렌더링 된 모습을 볼 수 있다.

 

Next.js에서 13버전을 사용했지만 신경쓰지 못한 부분들이 아직도 많이 있는것 같다.

12버전을 사용할껄 이라는 생각도 드는거 같다.. 새로운 기술들을 사용할때는 공식문서와 레퍼런스들을 잘 살펴보는게 중요한것 같다.