1. 렌더링??
가. Static Site Generation(SSG)
정적 페이지 생성 방식으로 90년대 많이 사용하던 방식으로 현재는 변경되지 않는 웹 페이지의 최적화에 쓰임
순서
1) 개발자가 HTML, CSS 파일 묶음을 생성(정적파일)해서 웹서버를 생성하여 거기에 묶음(정적파일)을 업로드함. 클라우드에 올려둠
2) 클라이언트에서 HTTP GET요청을 보내면 서버 내부에서 HTML, CSS, 이미지 파일 등 정적파일 등을 불러와서 응답함. 따로 HTML을 서버에서 생성하는 것이 아닌 올려둔 것 그대로 보내줌
3) 서버로 부터 받은 정적파일들을 클라이언트에서는 받아서 이 파일을 가지고 클라이언트 브라우저 내에서 DOM 등을 생성해 브라우저에 화면을 그림
장점
웹서버가 가벼워짐. 따로 빌드를 하지 않기 않고 요청만 처리하면 되니까
단점
HTML에 변경사항이 생길 경우 다시 빌드해서 올려야되고 사용자 요청에 따라 데이터가 변화하면 모든 경우의 수를 다 HTML 파일로 만들어서 올려야 됨.
나. Server-Side Rendering(SSR)
SSG의 단점을 개선시켜서 동적인 페이지 생성을 하기 위해서 등장함. 클라이언트의 요청에 따라 HTML 파일을 동적으로 생성해서 응답해줌
순서
1) 개발자가 빌드해서 서버에 배포를 함
2) 클라이언트가 서버의 특정 URL로 HTTP GET 요청을 보내면 서버의 해당 URL과 연결되어 있는 HTML 파일 생성 로직을 실행해서 HTML파일(CSS, JS포함)을 클라이언트에게 반환함
3) 클라이언트에서는 넘겨 받은 HTML파일을 해석 후 브라우저 화면에 렌더링
장점
사용자 요청에 의해 변하는 동적 데이터에 대한 HTML파일을 일일이 만들어 두지 않아도 됨.
단점
서버에 부하가 심해짐. 매 요청에 빌드를 다시 해야하기 때문에 중복된 요청이라도 빌드를 하게 될 수 밖에 없음
다. Client-Side Rendering(CSR)
React 이후의 웹구조. 최근 웹트렌드인 SPA(Single-Page-Application)이다. 물론 CSR과 SPA가 같은 개념은 아님. 자바스크립트가 애플리케이션 구현에 핵심적인 역할을 담당하고 있음.
순서
1) 개발자가 코드를 빌드해서 배포해둠
2) 클라이언트에서 요청이 들어올 경우 서버에서는 페이지를 구성하기 위한 최소 리소스만 전달함.
3) CDN은 빠르게 자바스크립트가 연결된 링크와 함께 HTML을 제공함
4) 브라우저가 HTML 파일을 다운로드 한 후 자바스크립트를 다운로드 한다.(이동안 사용자는 사이트를 볼 수 없음)
5) 자바스크립트가 실행되고 API가 데이터를 요청하고 그 동안 API가 요청되지 않은 파일들을 보게 됨
6) API에 대한 응답을 서버가 제공하고 화면을 렌더링 하게 됨.
장점
서버로 HTML 파일을 요청하지 않아 서버에 부하가 줄어들고 페이지 전환 시 네트워크 지연이 발생하지 않음.
단점
서버에서 실행되던 HTML 로직이 React에서 번들을 브라우저로 통해 다운받기 때문에 첫 접속시 느림
2. Next.js에서의 렌더링
가. SSG
Next.js에서 getStaticProps함수를 통해 HTML 파일에 들어갈 데이터를 빌드 시점에 넣어줄 수 있다.
나. SSR
Next.js에서 getServerSideProps함수를 통해서 HTML 파일을 클라이언트 요청에 따라 다르게 생성할 수 있다. 이 함수는 클라이언트가 해당 HTML을 요청했을 경우만 실행이 됨
다. CSR
Next.js에서 라우팅 Link태그를 들 수 있다.
3. Next.js의 대표적인 기능들
가. pre-rendering
next.js에서 기본적으로 모든 페이지를 프리 렌더링 함. 클라이언트 사이드에서 모든 작업을 수행하는 대신 미리 각 페이지에 대해서 HTML 파일을 미리 만들어서 성능과 SEO 측면에서 도움을 줌.
최소한의 자바스크립트 코드를 사용해 HTML화면을 미리 생성하고 자바스크립트가 로드되면 그때 컴포넌트와 앱 화면이 완전히 활성화 되고 이런 과정을 hydration이라고 한다.
next.js pre-rendering
React
next.js에서는 SSG와 SSR 형태의 프리 렌더링을 지원하고 있음. 성능상 SSG를 추천하고 있지만 각 페이지마다 어떤 종류를 택할지 선택할 수 있음.
Detail에서만 SSR을 할 수 있게 선택한 코드
나. data-fetching
1) getStaticProps
각 페이지에서 async 함수로 getStaticProps가 export 되면 Next 서버에서 빌드 시점에 이 함수를 호출하고 리턴한 props를 이용해 페이지를 프리 렌더링 한다.
// javascript case
export async function getStaticProps(context) {
return {
props: {}, // will be passed to the page component as props
};
}
// typescript case
import { GetStaticProps } from 'next';
export const getStaticProps: GetStaticProps = async (context) => {}2) getServerSideProps
매 요청마다 새로운 데이터를 갱신하게 하려면 getServerSideProps안에서 데이터를 패치한다. 정적페이지라면 getStaticProps로 데이터를 가져오면 되지만 최신화된 데이터를 사용해야 하는 경우 요청마다 페칭을 보내도록 할 수 있다.
// javascript case
export async function getServerSideProps(context) {
return {
props: {}, // will be passed to the page component as props
};
}
// typescript case
import { GetServerSideProps } from 'next';
export const getServerSideProps: GetServerSideProps = async (context) => {}3) getStaticPaths
동적 라우팅 처리를 하려면, 빌드 타임에 HTML이 그려질 때 각 라우팅 path 정보를 가진 리스트가 필요함. 라우팅 처리를 하는 곳에서 async 함수로 getStaticPath를 export 하면 Next 서버는 해당 함수가 리턴한 모든 path 경로의 페이지들을 프리 렌더링 한다.
export async function getStaticPaths() {
return {
paths: [
{ params: { id: '1' } },
{ params: { id: '2' } }
],
fallback: true
};
}fallback은 지정되지 않은 경로로 접속했을 때 404페이지로 처리할 것인지여부를 담음.
