Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Разработка бизнес решений
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
26
Битрикс24

Битрикс24

www.bitrix24.ru

16
Отследить-посылку

Отследить-посылку

B2B-сервис трекинга посылок

14
myPreza

myPreza

mypreza.ru

13
WebResidentTeam

WebResidentTeam

webresident.agency

12
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Expresso

Expresso

www.expresso.today

10
YAGLA

YAGLA

yagla.ru

10
Reader

Reader

Интернет-журнал о современных технологиях.

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

Увеличение кликабельности на сайте

55 0 В избранное Сохранено
Авторизуйтесь
Вход с паролем
Одностраничные приложения обеспечивают работу с сайтом без перезагрузки и имеют существенный недостаток – отрисовка сложных шаблонов браузером...

Вступление

Django является классическим и проверенным веб-фреймворком, одной из сильных сторон которого являются его шаблоны и обилие встроенных элементов управления. Однако, прогресс не стоит на месте, и уже давно разрабатываются JavaSсript библиотеки, которые берут на себя всю работу по отрисовке интерфейса на клиенте. Такие приложения называются одностраничными, обеспечивают работу с сайтом без перезагрузки и имеют существенный недостаток – отрисовка сложных шаблонов браузером может проходить довольно долго, особенно на слабых машинах, что не даёт желаемого эффекта “мгновенного” перехода и вынуждает облегчать шаблоны, при этом увеличивая их количество и количество кликов мышкой пользователем.

Решением этой проблемы может быть только отказ от рендеринга на клиенте и перенос этого процесса на сервер.

Проблемы

  1. Типичное одностраничное приложение загружает шаблоны и обрабатывает их самостоятельно на клиенте. Ему не важно, кто отдаёт ему эти шаблоны, и на каком языке реализован API для работы с данными. А для того, чтобы шаблоны обрабатывались на сервере, JS-код, который этим занимается, должен быть изоморфным. Он должен запускаться на сервере, но вести себя так, как будто он запускается в браузере. Значит, всё, что связано с браузерным взаимодействием, должно быть логически отделено от остального и замокано так, чтобы при исполнении на сервере не падать с ошибкой.
  2. Если мы хотим использовать при разработке бэк-энда что-то кроме Node.js, то нужно будет смириться с тем, что рабочий сервер превратится в зоопарк приложений на разных языках, которые должны как-то общаться друг с другом. Деплой подобного веб-приложения превратится в трудоёмкий процесс, включающий в себя запуск нескольких пакетных менеджеров, установку кучи зависимостей, виртуального окружения (если это Python) и так далее. Логику для всего этого придётся где-то хранить, например, в виде конфигураций Chef.
  3. Другим подводным камнем станет отлавливание багов. Веб-сервер нужно будет дебажить отдельно, и отдельно приложение для рендеринга. Это значительно повышает стоимость поддержки, не говоря о стоимости начального этапа разработки.

Выводы

Серверный JS рендеринг действительно может помочь сделать крутое и быстрое веб-приложение. Но, реализуя его, мы связываем фронт и бэк, что лишает общую архитектуру гибкости и усложняет её. А чем сложнее архитектура, чем больше её части отличаются друг от друга, тем сложнее проводить горизонтальное масштабирование и обеспечивать качественную техподдержку.

-1
Добавить в избранное Сохранено
Авторизуйтесь
Вход с паролем
Комментариев еще не оставлено
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать