<div id="readability-page-1" class="page"><div>
                            <ul>
                                
                                    

                                    
                                        <li>
                                            
                                            <div>
                                                    

                                                    
                                                    <div><h2>✌ 라운드 트립 애플리케이션(round-trip)</h2>
<ul>
<li>
<p>오랫동안 웹 앱은 라운드 트립 모델을 따랐다.</p>
</li>
<li>
<p>먼저 브라우저는 첫 HTML 페이지를 서버에 요청하고 수신하고 링크 클릭이나 폼 제출 등 사용자의 행위가 일어나면, 브라우저는 <b>다시 완전히 새로운 HTML 콘텐츠를 요청하고 수신한다.</b></p>
</li>
<li>
<p>이런 방식은 애플리케이션에서 브라우저는 본질적으로 HTML 콘텐츠의 렌더링 엔진일 뿐이며, <b>모든 애플리케이션 로직과 데이터는 서버에 존재한다.</b></p>
</li>
<li>
<p>브라우저는 일련의 stateless(무상태) HTTP 요청을 보내고 서버는 그에 따라 HTML 문서를 동적으로 생성해 처리하는 식이다.</p>
</li>
<li>
<p><b>웹 브라우저의 사용률이 낮은 대신 다양한 종류의 클라이언트</b>를 지원할 때 라운드 트립 방식의 웹 개발을 많이 채택한다.</p>
</li>
</ul>
<h3>❗ 라운드 트립 애플리케이션의 단점</h3>
<ul>
<li>사용자가 다음 HTML 문서가 요청되고 로딩될 때까지 기다려야 한다.</li>
<li>모든 요청을 처리하고 모든 애플리케이션 상태를 관리하기 위해 서버 측에 대형 인프라가 필요하다.</li>
<li>각 HTML 문서가 독립적으로 동일한 콘텐츠를 각자 포함하므로 더 넓은 대역폭이 필요하다.</li>
</ul>
<h4>📌 이러한 이유로 리액트는 라운드 트립 애플리케이션에 적합하지 않은데, <b>서버로부터 수신한 새로운 HTML 문서마다 브라우저가 초기 준비 작업을 수행해야 하기 때문이다.</b></h4>
<h2>✌ 싱글 페이지 애플리케이션(SPA, single-page application)</h2>
<ul>
<li>
<p>라운드 트립 애플리케이션과 다른 접근법을 사용한는데 첫 HTML 문서의 로딩은 동일하다.</p>
</li>
<li>
<p>그 다음 사용자의 행위는 HTML의 작은 조각이나 데이터 집합에 <b>삽입할 일부 데이터만</b>을 위한 HTTP 요청을 발생시킨다.</p>
</li>
<li>
<p>따라서, <b>초기 HTML 문서는 다시 로딩되거나 대체되지 않으며</b>, HTTP 요청이 비동기 방식으로 수행되는 동안 사용자는 <b>계속 현재의 HTML과 상호작용할 수 있다.</b></p>
</li>
<li>
<p>리액트는 SPA가 잘 어을리는데 애플리케이션을 초기화하는 브라우저 작업은 <b>처음 한 번만 수행</b>되며, 애플리케이션이 실행된 후에는 데이터나 콘텐츠에 대한 요청과 사용자 행위에 대한 응답이 모두 <b>백그라운드에서 수행되기 때문이다.</b></p>
</li>
<li>
<p>SPA는 때문에 말 그래도 단일 페이지로 구성되며 기존의 라운드 트립 애플리케이션과 비교할 때, 배포가 간단하며 네이티브 앱과 유사한 <b>사용자 경험(UX)을 제공할 수 있는 장점</b>을 가진다.</p>
</li>
<li>
<p>이러한 장점으로 인해 부가적으로 애플리케이션의 속도의 향상도 기대할 수 있어서 모바일 퍼스트 전략에 부합한다.</p>
</li>
</ul>
<h3>❗ 싱글 페이지 애플리케이션의 단점</h3>
<ul>
<li>초기 구동 속도
<ul>
<li>SPA는 웹 애플리케이션에 필요한 정적 리소스를 최초에 한번 다운로드하기 때문에 초기 구동 속도가 상대적으로 느리다.</li>
<li>하지만, 애플리케이션에 적합한 기술이므로 트래픽의 감소와 속도, 사용성, 반응성의 향상 등의 장점의 생각한다면 결정적인 단점이라고 할 수 없다.</li>
</ul>
</li>
<li>앱 규모가 커지면 자바스크립트 파일이 너무 커진다.
<ul>
<li>페이지 로딩 시 사용자가 실제로 방문하지 않을 수도 있는 페이지의 스크립트도 불러오기 때문이다.</li>
<li>하지만, 코드 스플리팅(code splitting)을 사용해 라우트 별로 파일들을 나누어서 트래픽과 로딩 속도를 개선할 수 있다.</li>
</ul>
</li>
<li>SEO(검색엔지 최적화) 문제
<ul>
<li>자바스크립트를 사용하여 라우팅을 관리하는 것은 자바스크립트를 실행하지 않는 일반 크롤러에서는 페이지의 정보를 제대로 수집해가지 못한다는 잠재적인 단점이 따른다. (서버 렌더링 방식이 아닌 자바스크립트 기반 비동기 모델이기 때문.)</li>
<li>그렇기 때문에 검색 엔진의 검색 결과에 페이지가 잘 나타나지 않을 수도 있다.</li>
<li>하지만 리액트에서는 <a href="https://velopert.com/3425">서버 사이드 렌더링(server-side rendering)</a>을 통해 해결할 수 있다.</li>
</ul>
</li>
</ul>
<figure id="og_1595757772384" contenteditable="false" data-ke-type="opengraph" data-og-type="website" data-og-title="react-router :: 3장. 서버사이드 렌더링 | VELOPERT.LOG" data-og-description="이 튜토리얼은 3개의 포스트로 나뉘어진 이어지는 강좌입니다. 목차를 확인하시려면 여기를 참고하세요. 3장. 서버사이드 렌더링 이번 장에서는 리액트 어플리케이션을 서버사이드 렌더링 하는" data-og-host="velopert.com" data-og-source-url="https://velopert.com/3425" data-og-url="https://velopert.com/3425" data-og-image="https://scrap.kakaocdn.net/dn/cLgjBA/hyGTs9nLew/Zq7WmASBO0cppW6CbJMBZK/img.png?width=950&amp;height=499&amp;face=0_0_950_499,https://scrap.kakaocdn.net/dn/yqs3a/hyGUOXioJJ/pvnZcZnVkibLkISidZuhWK/img.png?width=950&amp;height=499&amp;face=0_0_950_499,https://scrap.kakaocdn.net/dn/buE0wv/hyGUJIrKiM/0K4R25LjrBMPQvwtwhqOD1/img.png?width=946&amp;height=789&amp;face=0_0_946_789"><a href="https://velopert.com/3425" target="_blank" rel="noopener" data-source-url="https://velopert.com/3425">

<div>
<p>react-router :: 3장. 서버사이드 렌더링 | VELOPERT.LOG</p>
<p>이 튜토리얼은 3개의 포스트로 나뉘어진 이어지는 강좌입니다. 목차를 확인하시려면 여기를 참고하세요. 3장. 서버사이드 렌더링 이번 장에서는 리액트 어플리케이션을 서버사이드 렌더링 하는</p>
<p>velopert.com</p>
</div>
</a><img src="https://scrap.kakaocdn.net/dn/cLgjBA/hyGTs9nLew/Zq7WmASBO0cppW6CbJMBZK/img.png?width=950&amp;height=499&amp;face=0_0_950_499,https://scrap.kakaocdn.net/dn/yqs3a/hyGUOXioJJ/pvnZcZnVkibLkISidZuhWK/img.png?width=950&amp;height=499&amp;face=0_0_950_499,https://scrap.kakaocdn.net/dn/buE0wv/hyGUJIrKiM/0K4R25LjrBMPQvwtwhqOD1/img.png?width=946&amp;height=789&amp;face=0_0_946_789"></figure>

</div>

                                                    
                                                        
                                                        <div>
                                                            <h2>TAG</h2>
                                                            
                                                        </div>
                                                        
                                                    


                                                    
                                                        
                                                        
                                                        
                                                    

                                                    
                                                    
                                                    

                                                </div>
                                        </li>
                                    
                                
                            </ul>
                        </div></div>

SaDevelog

Harang

✌ 라운드 트립 애플리케이션(round-trip)
오랫동안 웹 앱은 라운드 트립 모델을 따랐다.
먼저 브라우저는 첫 HTML 페이지를 서버에 요청하고 수신하고 링크 클릭이나 폼 제출 등 사용자의 행위가 일어나면, 브라우저는 다시 완전히 새로운 HTML 콘텐츠를 요청하고 수신한다.
이런 방식은 애플리케이션에서 브라우저는 본질적으로 HTML 콘텐츠의 렌더링 엔진일 뿐이며, 모든 애플리케이션 로직과 데이터는 서버에 존재한다.
브라우저는 일련의 stateless(무상태) HTTP 요청을 보내고 서버는 그에 따라 HTML 문서를 동적으로 생성해 처리하는 식이다.
웹 브라우저의 사용률이 낮은 대신 다양한 종류의 클라이언트를 지원할 때 라운드 트립 방식의 웹 개발을 많이 채택한다.
❗ 라운드 트립 애플리케이션의 단점
사용자가 다음 HTML 문서가 요청되고 로딩될 때까지 기다려야 한다.
모든 요청을 처리하고 모든 애플리케이션 상태를 관리하기 위해 서버 측에 대형 인프라가 필요하다.
각 HTML 문서가 독립적으로 동일한 콘텐츠를 각자 포함하므로 더 넓은 대역폭이 필요하다.
  이러한 이유로 리액트는 라운드 트립 애플리케이션에 적합하지 않은데, 서버로부터 수신한 새로운 HTML 문서마다 브라우저가 초기 준비 작업을 수행해야 하기 때문이다.
✌ 싱글 페이지 애플리케이션(SPA, single-page application)
라운드 트립 애플리케이션과 다른 접근법을 사용한는데 첫 HTML 문서의 로딩은 동일하다.
그 다음 사용자의 행위는 HTML의 작은 조각이나 데이터 집합에 삽입할 일부 데이터만을 위한 HTTP 요청을 발생시킨다.
따라서, 초기 HTML 문서는 다시 로딩되거나 대체되지 않으며, HTTP 요청이 비동기 방식으로 수행되는 동안 사용자는 계속 현재의 HTML과 상호작용할 수 있다.
리액트는 SPA가 잘 어을리는데 애플리케이션을 초기화하는 브라우저 작업은 처음 한 번만 수행되며, 애플리케이션이 실행된 후에는 데이터나 콘텐츠에 대한 요청과 사용자 행위에 대한 응답이 모두 백그라운드에서 수행되기 때문이다.
SPA는 때문에 말 그래도 단일 페이지로 구성되며 기존의 라운드 트립 애플리케이션과 비교할 때, 배포가 간단하며 네이티브 앱과 유사한 사용자 경험(UX)을 제공할 수 있는 장점을 가진다.
이러한 장점으로 인해 부가적으로 애플리케이션의 속도의 향상도 기대할 수 있어서 모바일 퍼스트 전략에 부합한다.
❗ 싱글 페이지 애플리케이션의 단점
초기 구동 속도
SPA는 웹 애플리케이션에 필요한 정적 리소스를 최초에 한번 다운로드하기 때문에 초기 구동 속도가 상대적으로 느리다.
하지만, 애플리케이션에 적합한 기술이므로 트래픽의 감소와 속도, 사용성, 반응성의 향상 등의 장점의 생각한다면 결정적인 단점이라고 할 수 없다.
앱 규모가 커지면 자바스크립트 파일이 너무 커진다.
페이지 로딩 시 사용자가 실제로 방문하지 않을 수도 있는 페이지의 스크립트도 불러오기 때문이다.
하지만, 코드 스플리팅(code splitting)을 사용해 라우트 별로 파일들을 나누어서 트래픽과 로딩 속도를 개선할 수 있다.
SEO(검색엔지 최적화) 문제
자바스크립트를 사용하여 라우팅을 관리하는 것은 자바스크립트를 실행하지 않는 일반 크롤러에서는 페이지의 정보를 제대로 수집해가지 못한다는 잠재적인 단점이 따른다. (서버 렌더링 방식이 아닌 자바스크립트 기반 비동기 모델이기 때문.)
그렇기 때문에 검색 엔진의 검색 결과에 페이지가 잘 나타나지 않을 수도 있다.
하지만 리액트에서는 서버 사이드 렌더링(server-side rendering)을 통해 해결할 수 있다.

SPA(싱글 페이지 애플리케이션)

댓글