В течение очень долгого времени все веб-приложения, которые я создавал с нуля, были спроектированы как API, и все взаимодействие человека с приложениями осуществлялось через клиентов к API. Так, например, обычно есть клиент для Интернета через веб-браузеры и различные клиенты для разных моделей карманных компьютеров. При разработке веб-клиентов я всегда предпочитаю делать большую часть рендеринга на клиенте. Однако недавно я принял решение использовать подход рендеринга на стороне сервера. Это заставило меня задуматься о двух подходах.

Отрисовка на стороне клиента - это подход, при котором, когда пользователь делает первоначальный запрос к веб-приложению, ему отправляется большая часть HTML, CSS и JavaScript, которые могут им понадобиться и что пользователь видит на странице. в данный момент контролируется через JavaScript. Этому подходу способствуют такие веб-фреймворки, как EmberJS, EmberJS, BackboneJS и т. Д. Я считаю, что рендеринг на стороне клиента имеет следующие преимущества:

  • Смягчение снова долгой задержки сети. Большая часть моего кода обслуживается оборудованием, расположенным в очень удаленных местах, учитывая типичного пользователя. Это означает, что данные должны пройти большее расстояние, чтобы добраться до пользователя, чем если бы оборудование, обслуживающее запросы, было расположено в непосредственной близости. Из-за этого я должен убедиться, что мои сетевые вызовы минимальны, чтобы обеспечить терпимое взаимодействие с пользователем.
  • Смягчение при низкой пропускной способности сети. Во многих местах, где находится много моих целевых пользователей, неразвита Интернет-инфраструктура. Интернет-ссылки обычно имеют низкую пропускную способность. Это означает, что мне нужно передать только те данные, которые мне нужны, и не более того. Использование клиентского рендеринга с небольшими полезными нагрузками JSON позволяет мне добиться этого.
  • Время отклика на уровне приложений. Поскольку большая часть отрисовки контролируется кодом JavaScript, который уже загружен, время отклика приложений лучше для пользователей, чем было бы, если бы каждый ответ от приложения отрисовывался на сервере.
  • Более четкое разделение логики представления от данных. Рендеринг на стороне клиента позволяет мне иметь меньше беспорядочного кода, чем при противоположном подходе. Это связано с тем, что рендеринг на стороне сервера всегда создает соблазн добавить логику доступа к данным в логику представления.

Я считаю, что рендеринг на стороне клиента имеет следующие недостатки:

  • Для разработчика требуется больше времени. Написание кода, который использует рендеринг на стороне клиента, занимает намного больше времени, чем написание кода, который выполняет рендеринг своего ответа на сервере.
  • Крутая кривая обучения. Для разработчика полного стека подход к рендерингу на стороне клиента представляет собой сложную кривую обучения. Это связано с тем, что традиционно веб-приложения разрабатывались с использованием подхода рендеринга на стороне сервера.

Обработка на стороне сервера - это когда почти каждый запрос к службе пользователю отправляется только HTML, CSS, JavaScript и изображения, которые ему нужно просмотреть. Другими словами, сервер анализирует запрос, выполняет необходимый доступ к данным, строит ответ в виде HTML и отправляет его обратно клиенту. Это подход, при котором создается приложение на базе Django, Rails, Flask и т. Д. В этом подходе почти каждый бит взаимодействия с приложением требует сетевого вызова. Я обнаружил, что мне приходится применять этот подход, потому что мне нужно написать функциональное приложение за очень короткий период времени, чтобы продемонстрировать свои навыки инженера полного цикла веб-приложений. Как видите, несмотря на все ограничения этого подхода, он способствует быстрой разработке приложений. Я считаю, что проекты с рендерингом на стороне сервера имеют следующие преимущества:

  • Более быстрое время разработки. Поскольку это более старый подход, существует множество зрелых инструментов, поддерживающих его. Они также меньше переключают контекст во время разработки, что способствует быстрой разработке приложений.
  • Не крутая кривая обучения. Это также связано с тем, что это более старый подход, поэтому большинство разработчиков приобретут свои навыки, используя этот подход.