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

19

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

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

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

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

user1303881
источник
4
Безопасность важна. В частности, когда приложение является динамическим и нуждается в связи с базой данных.
Одед
2
@Oded - Почему безопасность проще сделать, когда вы отображаете страницу по сравнению с API? Я всегда думал, что то, что вы должны программировать, в любом случае эквивалентно, но психологически легче (по крайней мере для меня) помнить, что нельзя доверять клиенту при выполнении API. Я спрашиваю, потому что, если я пропускаю что-то, я действительно хочу знать.
PSR
1
@psr Возможно, он имеет в виду не столько безопасность данных, сколько безопасность пользователей (например, эксплойты MITM). Просто предположение, хотя.
maple_shaft
1
@psr - Согласен. Однако только вчера я ответил на вопрос, где у ОП была строка подключения, встроенная в JS ...
Одед
1
@maple_shaft - MITM - это то, о чем нужно подумать, но опять же я не уверен, почему это имеет значение для API и HTML, генерируемого сервером. Я полагаю, что API удобнее программировать, так что это будет немного проще, но я сомневаюсь, что вы это имеете в виду.
PSR

Ответы:

16

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

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

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


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

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

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


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

peteorpeter
источник
1
Ого, совсем забыл про возможности кеширования!
Майкл К
«Для« стандартных »приложений многие функции пользовательского интерфейса уже готовы». Это не имеет значения, это есть и на сервере, и на клиенте.
Raynos
@Raynos Он не упомянул об использовании клиентской среды, но если он ее использует, это хороший момент.
2012 года
1
Спасибо, это в основном ответ, который я искал. Я не слишком много сделал для клиентских фреймворков, но я занимался исследованием dust.js на основе выбора LinkedIn. Я знаю, что усы - альтернатива, но я буду исследовать это больше. Я, скорее всего, сделаю что-то вроде гибрида, в первую очередь я бы хотел отодвинуть вещи на сторону сервера, если это может улучшить производительность. Еще раз спасибо.
user1303881
Я бы не стал рассматривать что-либо из перечисленного для «рендеринга HTML на стороне клиента» как преимущество. «Иногда быстрее развиваться» вылетает из окна еще раз, чем считаются передовыми браузерами (IE 8 и т. Д.).
ноль
3

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

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

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

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

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

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

Vartec
источник
1
+1 На современных смартфонах (в первую очередь использующих webkit mobile) JS вряд ли станет узким местом, тогда как пропускная способность сотовой сети равна .
2012 года
1

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

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

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

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

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

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

Майкл К
источник
you can't write SQL in Javascript В самом деле?! Вы когда-нибудь рассматривали вопросы StackOverflow для Javascript? Я бы просил отличиться, к сожалению. Конечно, это самое худшее, что вы могли бы сделать в клиентском коде, но ...
maple_shaft
... также я забыл о Node.JS, но тогда это сервер JS, который является совершенно другим животным.
maple_shaft
Видимо, вы можете - TIL! Просто ... вау, хотя. Разговор о злоупотреблении языком, хотя!
Майкл К
2
Интерфейс REST - это то, как клиент в настоящее время получает доступ к данным базы данных через объекты json. Он не раскрывает все, и это приложение является частью сети частного предприятия. Одним из преимуществ интерфейсов является возможность для других приложений на предприятии использовать любую услугу, которую они хотят. С точки зрения разработки, я могу позволить фронт-энду разработчикам делать что угодно в html / js / css, а затем они могут просто пропинговать интерфейс RESTful, разработанный java-разработчиками. Однако, у большинства из нас есть смешанный набор навыков, и это разделение, возможно, не является необходимым.
user1303881
3
-1: @MichaelK: вы обсуждаете с соломенным человеком, которого вы вообразили, но не имеете абсолютно никакого отношения к реальной жизни. RESTful использует HTTP. Никто не должен писать SQL на JS, для этого и нужен интерфейс RESTful. Кроме того, RESTful не означает, что есть сопоставление 1-к-1 с запросами БД. Ваш ответ мог быть действительным в 1990-х годах, но сейчас мы в 2012 году.
vartec
0

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

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

9000
источник
Однако на практике все наоборот. Фактически, проект jQuery Mobile полностью основан на идее рендеринга на стороне клиента.
Заостренный
@Pointy: да, это может быть наоборот. Нужно проверить, как ведут себя определенные страницы на конкретных клиентах. Предоставление ссылки на альтернативу (например, ссылки на версии для мобильных и настольных компьютеров) также может быть полезным для пользователя.
9000
Мобильная связь сегодня характеризуется гораздо большей задержкой, чем низкая пропускная способность или вычислительная мощность. В проекте, над которым я недавно работал, нас больше интересовал размер страницы, чем скорость рендеринга - современные телефоны довольно хороши.
Майкл К
@Pointy Проект jQuery Mobile также представляет собой большую кучу ужасного кода, который не должен использоваться. Популярность! == значение
Райнос
@Raynos На самом деле мы используем Jquery Mobile, и тоже довольно успешно. Вы знаете что-то, чего мы не знаем? ;)
Майкл К
0

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

Уайетт Барнетт
источник
Хороший вопрос, хотя это приложение не требует SEO, потому что оно является частным, я также разрабатываю некоторые персональные приложения, и это рассматривается в этой области.
user1303881
Googlebot ли интерпретировать JS / AJAX в течение некоторого времени: searchenginewatch.com/article/2122137/...
Vartec
@vartec: Я думаю, что ключевой смысл этой статьи - «теперь можно читать и понимать некоторые динамические комментарии, реализованные с помощью AJAX и JavaScript». Я подозреваю, что это касается disqus и facebook, но не вашей пользовательской настройки ajax.
Уайетт Барнетт