React에서 SSR (NextJS vs Gatsby)
React SSR
Gatsby와 NextJS를 비교하기 전에 왜 이런 프레임워크를 써야하는지 알 필요가 있다. React에서 CRA로 프로젝트를 생성하게되면 SPA 기반 라이브러리로 CSR을 사용해 개발을 하게 된다. CSR이 가지는 장점도 있겠지만, SEO와 초기 렌더링 문제 등 CSR의 한계로 인해 오늘 날은 CSR + SSR 형태로 많이 개발을 하게된다. 하지만 CRA로 React를 구성한다면 SSR은 직접 구현을 해야하낟.
React에서 SSR을 구현하려면 어떻게 해야할까? React에서 SSR 구현에 대한 포스팅이 아니기 때문에 간략하게 설명을 한다.
- React-router와 @loadable-component를 사용해 SSR을 지원하는 Code-splitting을 사용한다.
- React-helmet을 통해 SEO에 대응한다.
- Webpack과 babel을 설정한다. (node(server), web(client)) 2 종류로 컴파일 해야한다.
- 서버측에서 ReactDOM.hydrate을 이용해 렌더링한다.
이러한 과정을 직접 개발하고 개발도 중 계속 설정을 변경해야할 일이 생길 수 있다. 그래서 우리는 프레임워크를 통해 SEO를 제공하거나 CSR + SSR 형식으로 개발할 수 있다. 본 포스팅에선 대표적으로 사용하는 NextJs와 Gatsby를 비교한다.
NextJS
현재 가장 많이 사용하고 있는 SSR 프레임워크이다. 자세한 설명은 NextJS를 포스팅 한 적이 있어 해당 NextJs란? 포스팅에서 확인 가능하다.
Gatsby
Gatsby는 정확히 말하면 SSR은 아니고 SSG(정적 페이지 렌더링) 즉 정적으로 HTML을 구축해 SEO을 대응하고, GraphQL과 React가 결합되어 있다. SSG 형태의 최적화가 잘 되어있고, 여러 플러그인을 제공하여 작업(코드) 량을 줄일 수 있다. 하지만, 서비스가 커지면 정적으로 생성할 페이지나 파일 크기가 늘어나기 때문에 빌드시간, 파일 사이즈가 계속 늘어나게 되고, 많은 플러그인들은 디펜던시를 갖게 되어 Gatsby의 버전 업데이트에 따라 빌드가 되지 않을 수 있다.
NextJS vs Gatsby
나의 개인적인 견해이지만 두 프레임워크의 사용방법은 정확히 구분할 수 있을 것 같다.
Gatsby의 경우는 블로그나 렌딩 페이지 혹은 CMS 등의 정적인 데이터가 많고 서비스가 크지 않을 때 모두 SSG로 렌더링 하여 성능면의 이점을 가져갈 수 있고,
NextJS의 경우에는 유저와의 상호작용으로 데이터가 변경되거나, 앱내의 웹뷰 처럼 데이터가 수시로 변경되는 것들은 NextJS를 이용하는게 맞는 것 같다. 사용자의 동작을 예측하고 SSG로 구성하는 것은 불가능하고, CSR을 이용한다면 SSG의 장점을 이용하지 못하기 때문에 이런 경우엔 NextJS가 맞는 것 같다.
두 프레임워크 모두 용도에 맞게 사용하면 좋은 프레임워크이다. Gatsby는 SSG 성능 최적화 NextJS는 SSR과 SSG 그리고 개발의 유연성, 빌드 등을 중점을 두고 만들어진 느낌이다.