서버 측 페이지 렌더링을 사용하면 어떤 이점이 있습니까?

웹 응용 프로그램을 개발 중이며 현재 전체 웹 사이트를 html / js / css로 작성했으며 백엔드에는 RESTFUL 서비스를 호스팅하는 서블릿이 있습니다. 모든 프리젠 테이션 로직은 json 객체를 가져오고 javascript를 통해 뷰를 수정하여 수행됩니다.

응용 프로그램은 기본적으로 검색 엔진이지만 역할이 다른 사용자 계정이 있습니다.

Play 및 Spring과 같은 일부 프레임 워크를 연구하고 있습니다. 웹 개발에 익숙하지 않아서 서버 측 페이지 렌더링을 사용하면 어떤 이점이 있는지 궁금합니다.

그것은 속도입니까? 더 쉬운 개발 및 워크 플로우? 기존 라이브러리에 액세스 할 수 있습니까? 더? 무엇보다도?

서버 측 HTML 렌더링 :

• 가장 빠른 브라우저 렌더링
• 빠르고 까다로운 성능 향상으로 페이지 캐싱 가능
• "표준"앱의 경우 많은 UI 기능이 사전 구축되어 있습니다.
• 구성 요소는 일반적으로 컴파일 타임 유효성 검사를 받기 때문에 더 안정적인 것으로 간주되는 경우가 있습니다.
• 백엔드 전문 지식에 의존
• 때로는 더 빨리 개발 *

* UI 요구 사항이 프레임 워크에 잘 맞는 경우

클라이언트 측 HTML 렌더링 :

• 낮은 대역폭 사용
• 초기 페이지 렌더링 속도가 느려집니다. 최신 데스크탑 브라우저에서는 눈에 띄지 않을 수도 있습니다. IE6-7 또는 많은 모바일 브라우저 (모바일 웹킷이 나쁘지 않음)를 지원해야하는 경우 병목 현상이 발생할 수 있습니다.
• API 우선 구축은 클라이언트가 독점 앱, 씬 클라이언트, 다른 웹 서비스 등을 쉽게 만들 수 있음을 의미합니다.
• JS 전문 지식에 의존
• 때로는 더 빨리 개발하기 **

** 더 흥미로운 상호 작용을 통해 UI가 크게 사용자 정의 된 경우 또한 브라우저 에서 컴파일 및 서버 다시 시작을 기다리는 것보다 해석 속도가 현저하게 빠릅니다.

mustache 와 같은 프론트 엔드 / 백엔드 템플릿 시스템을 사용하여 라이트 백엔드 구현이 포함 된 하이브리드 모델을 고려할 수도 있습니다 .

서버 측 HTML 생성 :

• 디버그하기 쉬움;
• 브라우저 호환성에 문제가 없습니다.
• 고전적인 전체 페이지 서버 측 생성에서는 가변 부분이 크더라도 HTML을 캐시하기가 더 어렵습니다. (해결책은 AJAX 호출을 통해 HTML 조각을 가져 오는 것입니다);
• 동적 HTML을위한 캐싱 프록시 및 CDN을 활용하지 않습니다.

클라이언트 측 HTML 생성 :

• 디버그가 더 어렵다;
• 더 이상 사용되지 않는 브라우저의 일부 문제;
• HTML을 캐싱하는 데 아무런 문제가 없습니다.
• HTML 템플릿 및 JS 코드를위한 캐싱 프록시 및 CDN 활용
• 훨씬 낮은 네트워크 사용량;

클라이언트 측 생성은 성공적인 모바일 사이트의 경우 수행되는 방식이며, 최신 브라우저에서는 더 효율적입니다 (WebKit 기반 브라우저는 모바일 시장의 약 70-80 %).

LinkedIn에는 dust.js 를 예로 사용하여 클라이언트 측 접근 방식의 장점에 대한 기사가 있습니다 . "먼지에서 JSP를 떠나기 : LinkedIn을 dust.js 클라이언트 측 템플리트로 이동"

요구 사항에 따라 다릅니다. 많은 작은 작업에 의존하는 고성능, 대기 시간이 짧은 솔루션이 필요한 경우 설명하는 것과 유사한 구조를 사용할 수 있습니다. Java, PHP 및 C #에서 가장 일반적인 솔루션은 기본값이 아닙니다.

대부분의 웹 응용 프로그램은 데이터베이스에 크게 의존합니다. 대부분의 웹 응용 프로그램은 한 번 이상의 호출없이 페이지를 렌더링 할 수 없습니다. 분명히 몇 가지 이유로 데이터베이스를 공개적으로 노출하고 싶지 않습니다.

• 보안 ( Oded 언급 한 것처럼 )- 네트워크를 공개적으로 노출시키고 싶지 않습니다 ! 이상적으로 외부에서 시스템에 대한 유일한 인터페이스는 서버에 대한 https 여야합니다.
• 당신이 정말로, - 개발의 용이성 정말 , 정말 자바 스크립트에서 쓰기 SQL 싶지 않아, 웹 프리젠 테이션 용으로 설계된 언어는 RDB에 잘 작동하지 않습니다. 예를 들어 국가 개념이 없습니다.

따라서 데이터베이스가 필요할 때 Java, C #, PHP 등과 같이 잘 작동하는 언어를 사용합니다. 페이지를 생성하는 가장 쉬운 방법은 다음과 같습니다. 템플릿 언어 (대부분 PHP, 그러나 JSP와 ASP는 페이지를 구성하는 다른 두 가지 일반적인 언어입니다. 이 언어는 다른 모듈을 호출하는 구문을 제공합니다. PHP에서 이것은 일반적으로 MVC 패턴을 사용하여 페이지 또는 다른 PHP 파일에 있습니다. JSP에서는 스크립틀릿 또는 JSP 표현식 언어를 사용합니다. 이러한 다른 모듈은 DB에 연결하고 로직을 수행하며 값을 뷰 계층으로 반환하는 많은 작업을 수행 할 수 있습니다. 최종 결과는 서버에서 렌더링되어 클라이언트로 전송 된 생성 된 HTML 페이지입니다.

데이터베이스가 페이지 렌더러와 동일한 네트워크에 있으면 성능도 향상됩니다. 클라이언트는 하나의 요청 만 수행하고 페이지를받습니다. 사용자가 필요한 모든 정보를 얻기 전에 10-15 개의 DB 요청을 수행해야 할 수도 있습니다. 클라이언트가 모든 작업을 수행해야하는 경우 네트워크에서 대기 시간 (밀리 초)은 몇 초에서 몇 분입니다.

시스템이 커지면 우려와 핵심 역량의 분리가 중요해집니다. HTML은 표시하기에 좋습니다. 자바 스크립트는 동적 콘텐츠에 적합합니다. SQL은 데이터베이스 쿼리에 적합하고 다른 언어는 비즈니스 논리에 능숙합니다. 개발자로서 우리의 임무는 유지 관리 가능한 시스템을 구축하는 데 사용할 수있는 모든 도구를 사용하는 것입니다. 손쉬운 개발은 좋은 시스템 의 큰 부분입니다. 제 생각에는 성능과 유용성만큼이나 중요합니다. 훌륭한 시스템은 시간이 지남에 따라 진화합니다. 불쌍한 시스템은 처음부터 잘못 작성되었으며 결코 개선되지 않았습니다.

모바일 클라이언트는 일반적으로 전력, 대역폭 및 메모리 제약이 있습니다. 서버에서 페이지를 렌더링하는 것이 좋습니다.

데스크톱 클라이언트의 경우 클라이언트에서 페이지를 렌더링하고 동적으로 업데이트 가능하도록 js + json을 보내는 것을 고려할 수 있습니다.

서버 측 렌더링의 큰 장점 중 하나는 접근성입니다. 자바 스크립트 기반 앱은 여전히 ​​시력이없는 사람들에게 큰 문제입니다. 그리고 "googlebot"이라는이 맹인이 있습니다. 그는 자바 스크립트도 잘하지 않습니다.