SSR, SSG 및 SPA에 대한 주니어 개발자의 전체 가이드

모든 개발 도구 회사와 팀은 주니어 개발자가 이러한 용어에 익숙하다고 가정하는 것 같습니다.

코딩을 시작했을 때 Nuxt는 SSR 프레임워크이고, SSG용 Gatsby를 사용할 수 있으며, next.config.js에서 이 플래그 또는 저 플래그를 설정하면 SPA 모드를 활성화할 수 있다는 점을 어디에서나 보았습니다.

대체 뭐야?

첫 번째 단계로, 용어집은 다음과 같습니다. 하지만 세부 사항을 이해하는 데는 도움이 되지 않습니다.

• CSR = 클라이언트측 렌더링
• SPA = 단일 페이지 신청
• SSR = 서버사이드 렌더링
• SSG = 정적 사이트 생성

다음으로 어둠에 빛을 비춰보겠습니다.

정적 웹 서버

처음에는 웹사이트가 서버에서 요청한 HTML 파일이었습니다.

브라우저가 서버에 "/about 페이지를 건네주실 수 있나요?"라고 묻습니다. 그러면 서버는 about.html 파일로 응답합니다. 귀하의 브라우저는 해당 파일을 구문 분석하고 이와 같은 아름다운 웹사이트를 렌더링하는 방법을 알고 있습니다.

우리는 이러한 서버를 정적 웹 서버라고 부릅니다. 개발자가 직접 HTML과 CSS(그리고 약간의 JS)를 작성하고 이를 파일로 저장한 후 폴더에 저장하면 요청 시 서버가 이를 전달합니다. 사용자별 콘텐츠는 없었고 누구나 접근할 수 있는 일반적인 정적(불변) 콘텐츠만 있었습니다.

app.get('/about', async (_, res) => {
  const file = fs.readFileSync('./about.html').toString();
  res.set('Content-Type', 'text/html');
  res.status(200).send(file);
})

대화형 웹 앱 및 요청별 콘텐츠

그러나 정적인 웹사이트는 지루합니다.

사용자가 웹사이트와 상호작용할 수 있다면 훨씬 더 재미있습니다. 그래서 개발자들은 이를 가능하게 만들었습니다. JS를 터치하여 버튼을 클릭하고 탐색 모음을 확장하거나 검색 결과를 필터링할 수 있었습니다. 웹이 대화형으로 바뀌었습니다.

이는 사용자가 검색 매개변수로 보낸 내용에 따라 /search-results.html 페이지에 다른 요소가 포함된다는 의미이기도 합니다.

따라서 사용자는 검색창에 입력하고 Enter 키를 누른 다음 검색 매개변수와 함께 요청을 서버에 보냅니다. 다음으로 서버는 데이터베이스에서 검색 결과를 가져와 유효한 HTML로 변환하고 완전한 /search-results.html 파일을 생성합니다. 사용자는 응답으로 결과 파일을 받았습니다.

(요청별 HTML 생성을 단순화하기 위해 개발자는 핸들바와 같은 HTML 템플릿 언어를 개발했습니다.)

app.get('/search-results', async (req, res) => {
  const searchParams = req.query.q;
  const results = await search(searchParams);

  let htmlList = '

'; for (const result of results) { htmlList += `
• ${result.title}
`; } htmlList += '

'; const template = fs.readFileSync('./search-results.html').toString(); const fullPage = embedIntoTemplate(htmlList, template); res.set('Content-Type', 'text/html'); res.status(200).send(fullPage); });

"렌더링"에 대한 짧은 우회

저는 오랫동안 렌더링이라는 용어를 매우 혼란스럽게 생각했습니다.

원래 의미에서 렌더링은 인간이 처리할 수 있는 이미지를 생성하는 컴퓨터를 의미합니다. 예를 들어 비디오 게임에서 렌더링은 사용자가 매력적인 3D 경험으로 사용할 수 있는 초당 60개의 이미지를 생성하는 프로세스를 의미합니다. 서버 측 렌더링에 대해 이미 들어본 적이 있는데, 그것이 어떻게 작동할 수 있는지 궁금했습니다. 서버가 사용자가 볼 수 있도록 이미지를 어떻게 렌더링할 수 있을까요?

그러나 서버측 또는 클라이언트측 렌더링의 맥락에서 "렌더링"은 다른 의미를 갖는다는 사실이 너무 늦게 밝혀졌습니다.

브라우저의 맥락에서 '렌더링'은 원래 의미를 유지합니다. 브라우저는 사용자가 (웹사이트) 볼 수 있도록 이미지를 렌더링합니다. 그러기 위해서는 최종 결과가 어떤 모습이어야 하는지에 대한 청사진이 필요합니다. 이 청사진은 HTML 및 CSS 파일 형식으로 제공됩니다. 브라우저는 해당 파일을 해석하고 이로부터 모델 표현인 DOM(문서 개체 모델)을 파생시켜 렌더링하고 조작할 수 있습니다.

좀 더 잘 이해할 수 있도록 이를 건물과 건축에 매핑해 보겠습니다. 집의 청사진(HTML 및 CSS)이 있고 건축가는 이를 책상 위의 소규모 물리적 모델(DOM)로 변환합니다. 조작할 수 있다고 생각하고 모두가 결과에 동의하면 건설 작업자는 모델을 보고 이를 실제 건물(사용자가 보는 이미지)로 "렌더링"합니다.

그러나 서버의 맥락에서 "렌더링"에 관해 이야기할 때는 구문 분석이 아닌 HTML 및 CSS 파일 생성에 대해 이야기합니다. 이 작업은 브라우저가 해석할 파일을 수신할 수 있도록 먼저 수행됩니다.

클라이언트 측 렌더링으로 넘어가서 "렌더링"에 관해 이야기할 때 DOM(브라우저가 HTML 및 CSS 파일을 해석하여 생성하는 모델)을 조작하는 것을 의미합니다. 그런 다음 브라우저는 DOM을 사람이 볼 수 있는 이미지로 변환합니다.

클라이언트 측 렌더링 및 단일 페이지 애플리케이션(SPA)

Facebook과 같은 플랫폼의 등장으로 개발자에게는 더 많고 빠른 상호작용이 필요했습니다.

대화형 웹 앱에서 버튼 클릭을 처리하는 데는 시간이 걸렸습니다. HTML 파일을 생성하고 네트워크를 통해 전송해야 했으며 사용자의 브라우저에서 이를 렌더링해야 했습니다.

All that hassle while the browser could already manipulate the website without requesting anything from the server. It just needed the proper instructions — in the form of JavaScript.

So that's where devs placed their chips.

Large JavaScript files were written and sent to the users. If the user clicked on a button, the browser would insert an HTML component; if the user clicked a "show more" button below a post, the text would be expanded — without fetching anything.

  
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
  
  
    <div id="root"></div>
    <script>
      document.addEventListener('DOMContentLoaded', () => {
        const root = document.getElementById('root');

        root.innerHTML = `
            <h1>Home
            <button>About
        `;

        const btn = document.querySelector('button');
        btn.addEventListener('click', () => {
          root.innerHTML = `
            <h1>About
        `;
        });
      });
    </script>
  

Though the code snippet suggests the opposite, developers didn't write vanilla JavaScript.

Ginormous web apps like Facebook had so much interactivity and duplicate components (such as the infamous Like-button) that writing plain JS became cumbersome. Developers needed tools that made it simpler to deal with all the rendering, so around 2010, frameworks like Ember.js, Backbone.js, and Angular.js were born.

Of them, Angular.js was the one that brought Single Page Applications (SPAs) into the mainstream.

An SPA is the same as Client-Side Rendering, but it is taken a step further. The conventional page navigation, where a click on a link would fetch and render another HTML document, was taken over by JavaScript. A click on a link would now fire a JS function that replaced the page's contents with other, already preloaded content.

For this to work properly, devs needed to bypass existing browser mechanisms.

For example, if you click on a that's wrapped in a

element, the browser normally sends a POST request to the server and renders the HTML file of the response (an agreed upon standard all browsers conform to). But, since the server had already sent all the instructions, and the browser had now taken control over rendering pages, that behavior needed to be prevented.

Devs invented all kinds of hacks to bypass this and other mechanisms, but discussing those hacks is outside the scope of this post.

Server-Side Rendering

So what were the issues with that approach?

SEO and Performance.

First, if you look closely at the above HTML file, you'll barely see any content in the

tags (except for the script). The content was stored in JS and only rendered once the browser executed the <script>. Hence, Google's robots had a hard time guessing what the page's content was about — in fact, they couldn't guess anything. <p>The site couldn't be indexed and thus wouldn't rank highly on Google. <p>Second, since the browser would only send a single request to the server and then continue to render the SPA on its own, all content that could ever be rendered had to be delivered with the initial request. With large web apps, this could easily surpass a couple megabytes, which slowed down the page load significantly. Amazon conducted a study that concluded businesses would lose 1% of revenue with every 100ms in added page load time, so that was a huge no-no for most companies. <p>In short, developers needed to create HTML files on the server again. <p>But they couldn't circle back to templating-languages and request-specific content — by now, everybody was writing React, and they loved the component-driven approach. Wasn't there a way to write React and render it on the server? Of course! With the advent of Node.js, developers were already writing JS on the backend, and the road to full-stack frameworks such as Next.js or Nuxt was paved. <p>Those frameworks render React (or Vue, Svelte...) on the server. Basically, React turned into a templating language such as Handlebars.<br> <pre class="brush:php;toolbar:false">// List.tsx import React from "react" export const List = (props: { results: { title: string }[] }) => ( <ul> {props.results.map((r) => ( <ListElement title={r.title} /> ))} ) export const ListElement = (props: { title: string }) => ( <li>{props.title} ) // server.ts app.get("/search-results", async (req, res) => { const searchParams = req.query.q const results = await search(searchParams) const fullPage = renderToString( React.createElement(List, { results }) ) res.set("Content-Type", "text/html") res.status(200).send(fullPage) }) <p>(Note: the only difference to the "Request-Specific Content" approach is that we're now using modern frontend frameworks to write our HTML.) <h2> Static Site Generation <p>Great, so our pages were indexable and fast again. <p>However, some sites weren't as fast as they <em>could be. <p>If the content didn't change (like the page of a blog post), why should the server newly fetch and build the HTML for every user visiting the page? That seemed wasteful. Wouldn't it be enough to build the HTML once and reuse it whenever somebody requested it? <p>That approach is called static site generation. <p>In contrast to the original static web server approach, where developers manually wrote and stored HTML files on the server, here, the HTML files were <em>generated: <p>기술 지식이 없는 사람들이 CMS(WordPress 또는 Sanity와 같은 콘텐츠 관리 시스템)에 콘텐츠를 작성하고 이미지를 업로드했습니다. 개발자는 React 구성 요소를 작성하고, CMS의 API를 사용하고, 모든 페이지의 데이터를 가져오고 대략적인 청사진에 따라 HTML 파일을 빌드하는 <em>빌드 스크립트를 실행했습니다. 완성된 파일은 서버에 저장되어 사용자의 요청에 따라 제공될 준비가 되었습니다. <p>개발자는 새 콘텐츠가 제공되면 빌드 스크립트를 다시 트리거하여 새 파일을 생성할 수 있습니다. <h2> 블록의 새로운 아이: 서버 구성 요소 <p>2024년 8월 현재 RSC(React Server Components)는 아직 실험적이라고 표시되어 있지만 큰 인기를 누리고 있습니다. <p>기본 아이디어는 다음과 같습니다. RSC 이전에는 먼저 React 구성 요소를 클라이언트에 전달해야 했습니다. 거기서 렌더링하고 데이터를 가져와야 하는 경우 서버에 또 다른 요청을 보냅니다. 응답을 기다렸다가 다시 렌더링해야 했습니다. 이것은 낭비입니다. RSC를 사용하면 데이터를 가져오고 서버에서 구성 요소를 렌더링할 수 있습니다. 완성되고 분리된 HTML 구성 요소만 클라이언트에 전송되고 기존 HTML과 병합됩니다. 페이지의 나머지 부분은 그대로 유지됩니다. <p>결과적으로 성능이 훨씬 향상되었습니다. 서버 간 왕복 작업이 줄어들고, 네트워크를 통한 킬로바이트도 줄어들고, 다시 렌더링되는 일도 줄어듭니다. <p>또한 React 코드에서 바로 데이터를 기다릴 수 있으므로 작성이 훨씬 간단해집니다. <p>그러나 평소와 같이 기존 프레임워크에 새로운 기능이 추가되면 RSC는 React를 훨씬 더 복잡하게 만듭니다. 서버 또는 클라이언트에 구성 요소가 필요한지 지속적으로 고려해야 합니다. 캐싱 레이어가 관련됩니다. RSC와의 상호작용은 불가능합니다. 간략하게 설명하자면, 물은 여전히 ​​탁합니다. <p>프런트엔드의 복잡성에 싫증이 난 개발자들은 이에 대한 반발로 HTMX와 같은 간단한 프레임워크를 작성하고 선호하기 시작했습니다. </script>

위 내용은 SSR, SSG 및 SPA에 대한 주니어 개발자의 전체 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!