Какие преимущества дает использование рендеринга страниц на стороне сервера?

Я занимаюсь разработкой веб-приложения, и в настоящее время я написал весь веб-сайт в формате html / js / css, а на серверной части у меня есть сервлеты, на которых размещены некоторые службы RESTFUL. Вся логика представления выполняется путем получения объектов json и изменения представления с помощью javascript.

Приложение по сути является поисковой системой, но оно будет иметь учетные записи пользователей с разными ролями.

Я исследовал некоторые фреймворки, такие как Play и Spring. Я довольно новичок в веб-разработке, поэтому мне было интересно, какие преимущества дает рендеринг страницы на стороне сервера?

Это: скорость? Более простая разработка и рабочий процесс? Доступ к существующим библиотекам? Больше? Все вышеперечисленное?

HTML-рендеринг на стороне сервера:

• Самый быстрый браузерный рендеринг
• Кэширование страниц возможно как быстрое и грязное повышение производительности
• Для «стандартных» приложений многие функции пользовательского интерфейса уже встроены
• Иногда считается более стабильным, потому что компоненты обычно проходят проверку во время компиляции
• Опора на бэкэнд-экспертизу
• Иногда быстрее развиваться *

* Когда требования пользовательского интерфейса хорошо вписываются в рамки.

HTML-рендеринг на стороне клиента:

• Более низкая пропускная способность
• Медленная начальная страница рендеринга. Может даже не быть заметным в современных настольных браузерах. Если вам требуется поддержка IE6-7 или многих мобильных браузеров (мобильный веб-набор неплох), вы можете столкнуться с узкими местами.
• Создание API в первую очередь означает, что клиент также может быть проприетарным приложением, тонким клиентом, другим веб-сервисом и т. Д.
• Опирается на экспертизу JS
• Иногда быстрее развиваться **

** Когда пользовательский интерфейс в значительной степени пользовательский, с более интересными взаимодействиями. Кроме того, я нахожу кодирование в браузере с интерпретированным кодом заметно более быстрым, чем ожидание компиляции и перезапуска сервера.

Вы могли бы также рассмотреть гибридную модель с легкой реализацией серверной части, использующей систему шаблонов внешнего / внутреннего интерфейса, такую ​​как усы .

Генерация HTML на стороне сервера:

• легче отлаживать;
• нет проблем с совместимостью браузера;
• при классической генерации на всю страницу на сервере сложнее кэшировать HTML, даже если он имеет большие неизменяемые части; (решение заключается в получении фрагментов HTML через вызовы AJAX);
• не использовать преимущества кэширующих прокси и CDN для динамического HTML;

Генерация HTML на стороне клиента:

• сложнее отлаживать;
• некоторые проблемы с устаревшими браузерами;
• нет проблем с кэшированием HTML-шаблонов на стороне клиента;
• использование кеширующих прокси и CDN для HTML-шаблонов и кода JS;
• значительно меньшее использование сети;

Обратите внимание, что генерация на стороне клиента - это то же самое, что и в случае успешных мобильных сайтов, поскольку, очевидно, это более эффективно с современными браузерами (браузеры на основе WebKit занимают около 70-80% рынка мобильных устройств).

В LinkedIn есть статья о преимуществах подхода на стороне клиента, использующего dust.js в качестве примера: «Оставить JSP в пыли: переместить LinkedIn в шаблоны клиентской стороны dust.js»

Это зависит от ваших требований. Если вам нужно высокопроизводительное решение с малой задержкой, которое зависит от множества небольших задач, вы можете использовать структуру, аналогичную описанной. Однако наиболее распространенные решения в Java, PHP и C # не соответствуют этому.

Большинство веб-приложений очень сильно зависят от баз данных - большинство из них настолько сильно, что страницы не могут отображаться без хотя бы одного вызова. Очевидно, что вы не хотите раскрывать свою базу данных публично по нескольким причинам:

• Безопасность (как упоминает Одед ) - вы определенно не хотите раскрывать свою сеть публично! В идеале единственным интерфейсом к вашим системам извне должен быть https для вашего сервера.
• Простота разработки - вы действительно, действительно , действительно не хотите писать SQL на Javascript, а языки, предназначенные для веб-презентации, плохо работают с RDB. У них нет понятия государства, например.

Поэтому, когда вам нужна база данных, вы используете языки, которые хорошо с ними работают, такие как Java, C #, PHP и т. Д. Самый простой способ создания страницы заключается в следующем: вы используете язык шаблонов (наиболее известный PHP, но JSP и ASP - два других очень распространенных языка) для создания страницы. Язык предоставляет конструкции, которые вызывают другие модули. В PHP это обычно на странице или в другом PHP-файле, используя шаблон MVC. В JSP вы используете скриптлеты или язык выражений JSP. Эти другие модули могут выполнять тяжелую работу по подключению к БД, выполнению логики и возвращению значений на уровень представления. Конечным результатом является сгенерированная HTML-страница, отображаемая на сервере и отправляемая клиенту.

Когда ваша база данных находится в той же сети, что и средство визуализации страниц, вы также получаете лучшую производительность. Клиенту нужно выполнить только один запрос и получить страницу - вам может потребоваться выполнить 10-15 запросов к БД, прежде чем вы получите всю информацию, необходимую пользователю. Задержка в миллисекундах в вашей сети будет от нескольких секунд до нескольких минут, если клиенту придется все это делать.

Когда системы разрастаются, решающее значение приобретает разделение интересов и основных компетенций. HTML хорош для отображения. Javascript хорош для динамического контента. SQL отлично подходит для запросов к базе данных, а другие языки хороши для бизнес-логики. Наша работа как разработчиков заключается в том, чтобы использовать все доступные нам инструменты для создания обслуживаемой системы. Легкость разработки - огромная часть хорошей системы. На мой взгляд, это почти так же важно, как производительность и удобство использования. Великие системы развиваются с течением времени. Плохие системы были написаны плохо с самого начала и никогда не были улучшены.

Мобильные клиенты обычно ограничены по мощности, пропускной способности и памяти. Вероятно, лучше сделать страницы для них на сервере.

Для настольных клиентов вы можете отправить js + json, чтобы отобразить страницу на клиенте, сделать ее динамически обновляемой и т. Д.

Одним из огромных преимуществ рендеринга на стороне сервера является доступность - приложения на основе javascript все еще остаются большой проблемой для людей, не имеющих представления. Это и есть этот слепой парень по имени "googlebot", которого вы можете удовлетворить. Он не так хорошо делает JavaScript.