[stackoverflow 영문 답글 해석]Server-side vs Client-side

문제

react React-router 사용시 루트경로(localhost:8888)가 아닌 다른url(localhost:8888/about)을 주소창에 직접입력하거나 다른url(localhost:8888/about) 위치에서 새로고침을 하면 not found 에러가 뜨는 문제

Server-side vs Client-side

이것에 대해 가장 먼저 이해해야 할 것은 이제 URL이 해석되는 곳이 2곳인 반면 이전에는 1곳만 존재한다는 것입니다.
과거에 수명이 단순했을 때는 일부 사용자가 http://example.com/about에 대한 요청을 서버로 전송하여 URL의 경로 부분을 검사하여 사용자가 about 페이지를 요청하고 있음을 확인한 후 다시 보냈습니다.

React-Router가 제공하는 client-side routing을 사용하면 일이 조금 간단합니다.

1. 처음에는 클라이언트에 아직 JS 코드가 로드되어 있지 않습니다. 따라서 첫 번째 요청은 항상 서버에 대한 것입니다.
2. 첫번째 요청을 서버에 하면 React 및 React Router 등을 로드하는 데 필요한 스크립트 태그가 포함 된 페이지가 반환됩니다.
3. 해당 스크립트가 로드된 경우에만 2단계가 시작됩니다.
4. 2단계에서 사용자가 예를 들어 About us 네비게이션 링크를 클릭하면 URL은 http://example.com/about로 로컬에서 변경되지만(히스토리 API로 가능) 서버에 대한 요청은 없습니다.
5. 대신, React Router는 client side 작업을 수행하고 렌더링한다. 그리고 렌더링한 React 보기를 결정합니다. 정보 페이지에서 REST API 호출을 수행 할 필요가 없습니다. 서버 요청이 발생하지 않고 페이지 경로를 Home에서 About Us로 전환했습니다.

따라서 기본적으로 링크를 클릭하면 페이지를 새로 고치지 않고 주소 표시 줄의 URL을 조작하는 일부 Javascript가 실행되어 React Router가 클라이언트 측에서 페이지 전환을 수행합니다.

그러나 주소 표시 줄에 URL을 복사하여 붙여 넣어 친구에게 전자 메일로 보내면 어떻게되는지 생각해보십시오. 친구가 아직 웹 사이트를로드하지 않았습니다. 다시 말해, 그녀는 여전히 1 단계에 있습니다. No React Router가 아직 컴퓨터에서 실행되고 있지 않습니다. 따라서 그녀의 브라우저는 http://example.com/about 서버에 요청을합니다.

Combining server-side and client-side routing

http://example.com/about URL이 서버 측과 클라이언트 측 모두에서 작동하게하려면 서버 측과 클라이언트 측 모두에 대한 경로를 설정해야합니다. 말이 되나요?

그리고 이것이 당신의 선택의 시작입니다. 솔루션은 부트 스트랩 HTML을 반환하는 모든 경로를 통해 문제를 우회하는 것부터 서버와 클라이언트가 동일한 JS 코드를 실행하는 완전 동형 접근 방식까지 다양합니다.

문제를 모두 우회 : Hash History(HashRouter)

Browser History 대신 Hash History을 사용하면 정보 페이지의 URL은 다음과 같습니다. http://example.com/#/about 해시(#) 기호 뒤의 부분이 서버로 전송되지 않습니다.
따라서 서버는 http://example.com/ 만보고 인덱스 페이지를 예상대로 보냅니다. React-Router는 #/about 부분을 선택하고 올바른 페이지를 보여줍니다.

단점

• 못생긴 URLs ..!!!!
• 이 방법으로는 서버 측 렌더링이 불가능합니다. 검색 엔진 최적화(SEO)가 안됨.

Catch-all

이 방법을 사용하면 Browser History를 사용하지만 서버에서 /*으로 오는 요청을 모두 index.html로 보내는 catch-all을 설정하면 Hash History과 동일한 상황을 효과적으로 제공 할 수 있습니다.
깨끗한 URL이 있으며 나중에 모든 사용자의 즐겨 찾기를 무효화하지 않고도이 체계를 개선 할 수 있습니다.

단점

• 더 복잡한 설정
• 여전히 좋지 않은 SEO

Hybrid

하이브리드 방식에서는 특정 경로에 대한 특정 스크립트를 추가하여 catch-all 시나리오를 확장합니다. 콘텐츠가 포함 된 사이트의 가장 중요한 페이지를 반환하도록 간단한 PHP 스크립트를 만들 수 있으므로 Googlebot은 적어도 페이지의 내용을 볼 수 있습니다.

단점

• 훨씬 더 복잡한 설정
• 당신이 특별하게 처리하는 경로(routes)에 대해서만 좋은 SEO
• 서버 및 클라이언트에서 컨텐츠를 렌더링하기위한 코드 복제

Isomorphic (client에서 서버를 사용)

Node JS를 서버로 사용하여 양쪽에서 동일한 JS 코드를 실행할 수 있다면 어떨까요? 이제 모든 라우트를 단일 반응 라우터 구성에 정의했으며 렌더링 코드를 복제 할 필요가 없습니다. 서버는 클라이언트에서 페이지 전환이 발생한 경우와 동일한 마크 업을 보냅니다. 이 솔루션은 SEO 측면에서 최적입니다.

단점

• 서버는 반드시 JS를 실행할 수 있어야합니다. 이는 대부분 노드 JS 기반 서버를 사용해야 함을 의미합니다.
• 많은 까다로운 환경 문제 (using window on server-side 등)
• 험한 learning curve

그래서 우리는 어느것을 사용해야 하나요?

멀리 갈 수있는 것을 선택하십시오. 개인적으로 catch-all은 설정하기에 충분히 간단하다고 생각합니다. 이 설정을 통해 시간이 지남에 따라 개선 할 수 있습니다. Node JS를 서버 플랫폼으로 이미 사용하고 있다면 Isomorphic 응용 프로그램을 수행하는 것이 확실합니다예, 처음에는 힘들지만 일단 중단되면 실제로는 문제에 대한 매우 우아한 해결책입니다.

기본적으로 저에게는 이것이 결정적인 요소입니다. 내 서버가 노드 JS에서 실행되면 isomorphic이됩니다. 그렇지 않으면 Catch-all 솔루션을 선택하고 시간이 지남에 따라 SEO 요구 사항에 따라 솔루션을 확장합니다 (하이브리드 솔루션).

What is Isomorphic JavaScript?

• Single Page Application
  - 하나의 페이지에서 모든 변경사항을 처리하게 된다.

  • 실제 페이지 이동이 일어나지 않고, 해당되는 부분의 View 데이터를 받아 render 하기 때문에 속도가 빠르다

• Isomorphic 형태의 개발
  - Isomorphic 이라는 것은 서버와 클라이언트에서 동일한 코드를 가지고, 동작 가능한 형태를 말한다고 한다.

  • 이전 SPA 방식에는 많은 장점이 있지만 단점중에 서버에서 어느정도의 수준까지 렌더링을 해야하는지, SEO(검색엔진 최적화) 에 대한 적용 문제가 있었다고 한다. 이런 문제를 해결하고자 Isomorphic 형태의 개발을 사용한다.

Isomorphic 형태로 react 개발하기

React로 Isomorphic Web App 개발하기 해당 페이지글에 설명이 정말 잘되어 있다.

( ------------------------------------------------- 작성중 ------------------------------------------------- )

참고블로그

• https://stackoverflow.com/questions/27928372/react-router-urls-dont-work-when-refreshing-or-writing-manually
• https://likejirak.tistory.com/66