서버 쪽 렌더링이란 무엇입니까? 그것을 사용해야 합니까?

제목에서 말한 바와 같이, 나는 더 이상 인기가 없는 이 기술의 장점과 단점을 소개하고, 일부 초보자들이 그것을 더욱 잘 이해하도록 도와줄 것이다.
우선, 우리 는 몇 가지 용어 를 깊이 이해합시다

SSR?동구통용했어세계 태권도 연맹?
우선, 서버 측의 렌더링을 모르는 것들에 대해서는 별다른 것이 없다.일반적인 정적 사이트는 서버에서 보여집니다. 서버는 요청을 받고 브라우저에 HTML을 출력합니다.
우리는 또한 템플릿 언어로 하여금 서버 측에서 보여준 교묘한 기교로 여겨지도록 했다.
그러나 JavaScript에 대해 이야기할 때 서버 측은 일반적으로 백엔드 시스템에서 실행할 때 HTML을 보여주는 전단 코드를 가리킨다.

SPA+SSR=동일 구성*
* 또는 범용
동구 또는 통용 응용 프로그램은 서로 바꿀 수 있는 짧은 말로 서버 측과 클라이언트가 같은 언어를 사용할 수 있도록 응용 프로그램을 작성하는 방식을 가리킨다.더욱 구체적으로 말하면, 자바스크립트의 경우, 당신도 같은 문법을 사용하는 것이 가장 좋다.
예를 들어 NodeJS에서 백엔드를 실행하는 경우 CommonJS 모듈 구문을 사용하고 있을 수 있습니다.

//...Our awesome app code...
const circle = require('./circle.js');
//...Rest of our awesome app code...

너는 ES6로 너의 반응을 써라.

//...Our awesome app code...
import React, { Component } from 'react';
//...Rest of our awesome app code...

Webpack을 사용하면 응용 프로그램의 서버에서도 ES6 가져오기 문법을 사용할 수 있습니다. 이것은 응용 프로그램을 구성하는 진정한 목표입니다.

왜 나는 먼저 React with 서버 쪽을 사용해서 렌더링해야 합니까?
기존의 React 애플리케이션은 로드할 때 다음과 같은 프로세스를 거칩니다.

브라우저 요청 페이지

일시 중지

우리는 매우 빈 html과 스크립트 표시를 받았는데 우리의 모든 코드가 있는 JS 파일을 가리킨다

브라우저에서 스크립트 요청

일시 중지

화면에 표시되는 내용

지금 우리는 왕복 서버가 두 번 있는 것을 보았는데, 이것은 받아들일 수 있는 것이다.그러나 우리 프로그램에 블로그 게시물 목록이나 일련의 그림이 있거나 어떤 API로부터 요청해야 할 것이 있다면 이제는 절차가 더욱 진실해지고 이렇게 보일 것이라고 상상해 보자.

브라우저 요청 페이지

일시 중지

브라우저에서 JS 요청

일시 중지

React 어플리케이션 시작, 백엔드에서 데이터 요청

일시 중지

화면에 표시되는 내용

보시다시피 요청 수가 증가했기 때문에, 우리 사용자들이 화면에 있는 모든 것을 보기 전까지는 많은 일들이 발생합니다.
서버측 어플리케이션

브라우저 요청 페이지

일시 중지

화면에 보이는 내용!

뭐?어떻게 써요?좀 더 자세히 살펴보겠습니다.

브라우저 요청 페이지

서버가 메모리에 부하되어 응답

서버에서 필요한 데이터 확보

서버 어플리케이션

서버가 생성한 HTML을 브라우저로 보내기

사용자 보기

JS 파일 필요

React 어플리케이션 시작, 백엔드에서 데이터 요청

화면의 응용 프로그램 재방송(수화물).

보시다시피 사용자를 위해 내용을 얻기 전에 우리는 서버에 한 번만 접근했습니다.현재, 우리가 모든 내용을 다시 발표하기 전에 제공한 내용은 정적이기 때문에, 사용자의 속도가 매우 빠르고, 문제가 발생하기 전에 클릭하면 프로그램이 응답하지 않을 것이다.

우리는 이런 방법으로 어떤 문제를 해결했습니까?
그중 가장 큰 두 가지는 검색엔진 최적화와 감지 성능 향상이다.
만약 당신의 응용 프로그램이 조금 크다면 검색엔진 파충류는 당신의 페이지를 기본적으로 빈 html로 간주하고 script 라벨을 가지고 있어서 당신의 응용 프로그램을 요청할 수 있습니다. 왜냐하면 DOM이 채워지는 순간을 기다리지 않고 당신의 페이지도 인덱스되지 않기 때문입니다.
이와 함께 구글도 자바스크립트가 만든 내용을 검색하기 위해 파충류 프로그램을 개선했지만, 반드시 또는 바이두가 이 기능이 부족하기 때문에, 만약 당신의 시청자 중 더 많은 비율이 다른 검색엔진에서 온다면, 당신은 이 문제를 해결해야 한다.
React SSR을 사용하면 대부분의 경우 첫 번째 의미 있는 드로잉 시간이 크게 단축됩니다.이것은 몇몇 회사의 중요한 지표다.많은 회사들이 웹 애플리케이션의 탑재 시간을 줄여 이윤을 늘리는 이야기를 들은 적이 있을 것이다.( https://wpostats.com/ ).
위에서 나는'감지 성능 향상'이라고 썼다. 비록 전통적인 React 응용 프로그램을 사용하는 것보다 사용자에게 더 빨리 내용을 제공할 수 있지만, 문제는 이것이 성능 향상이 아닐 수도 있다는 것이다.위의 SSR 요청 예시에서 서버도 클라이언트가 하는 모든 것을 볼 수 있습니다. 이것은 React를 시작하여 프로그램을 보여주고 HTML을 출력합니다.이것은 네가 두 번이나 이상적이지 않은 일을 했다는 것을 의미한다.react는 예쁜 jsx 코드를 HTML로 변환하는 방법renderToString()이 매우 느리고 동기화됩니다.이것은 서버로 하여금 더욱 큰 부하를 견디게 할 것이며, 서버의 초기 응답은 잠시 후에 도착할 것이다.
서버 측 렌더링을 사용하기로 결정한 경우 API 및 비즈니스 로직과 렌더링을 위한 서버가 두 대 있을 수 있습니다.렌더링 프로세스의 작업 크기를 파악하면 렌더링 서버를 확대하여 추가 부하와 일치하도록 할 수 있습니다.
월마트 실험실의 엔지니어들은 내가 처음으로 이런 문제에 부딪힌 사람이 아니기 때문에 SSR의 이런 괴벽을 최적화시킬 수 있는 도구를 만들었는데, 이를 전극이라고 부른다.그들은 또한 몇 편의 멋진 문장을 썼다. 만약 네가 이 점을 할 수 있다면 정말 읽을 만하다. (https://medium.com/walmartlabs/using-electrode-to-improve-react-server-side-render-performance-by-up-to-70-e43f9494eb8b
넥스트와 같은 리액트 SSR의'프레임'도 있다.예를 들어 js는 지역 사회의 좋은 흡인력과 지원을 받고 있다.
또한 React SSR을 사용하면 여러 계층의 복잡성이 증가합니다.자유롭게 사용하거나windowdocument일한 거 기억나세요?됐어!
물론 농담일 뿐입니다. 그러나 프로그램이 노드 환경에서 먼저 실행되기 때문에 (예: window 와 document 정의가 없기 때문에 외부 componentDidMount 나 외부 if (typeof window !== 'undefined') 에서 사용하는 것을 제한해야 합니다.나는 내가 익숙해질 때까지 내 프로그램이 몇 번이나 고장났는지 기억하지 못한다.
노드 서버는 사용자의 루트를 포착하여 아래로 전달합니다. 반응을 보이고 무엇을 렌더링할지 결정합니다. 그러면 서버의 루트에 어떻게 접근합니까?아니오, 해결 방안?이중 거리.당신의 앱 디스플레이는 Redux 상점의 내용에 달려 있습니까?이인실.
SSR은 많은 복잡성을 도입했는데 다행히도 Next 같은 도구입니다.js는 많은 문제를 해결했지만, 만약 당신이 계속 이 문제들을 스스로 해결하겠다고 고집한다면 정말 어려울 것이다.

React 서버에서 렌더링을 사용해야 합니까?
그렇게 지도 모른다, 아마, 아마...
만약 당신/당신의 회사가 정말로 검색엔진의 최적화를 중시하고 당신의 방문량의 상당 부분을 구글 이외의 검색엔진에서 온다면 그렇습니다.
만약 당신/당신의 회사가 정말로 사용자가 감지하는 성능을 중시한다면, 당신의 클라이언트 응용 프로그램 성능이 아무런 개선도 얻지 못한다면, 생각해 보세요.
다른 어떤 상황에서도, 나의 건의는 그것을 멀리하는 것이다. 그것은 프로젝트의 복잡성을 증가시킬 뿐, 많은 이익을 가져오지 않을 것이다.