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

Эбиа

www.ebia.ru

21
YAGLA

YAGLA

yagla.ru

20
2.0

2.0

twozero.ru

17
Venyoo

Venyoo

venyoo.ru

15
Enlite

Enlite

enlited.ru

14
E-Commerce and Venture projects

E-Commerce and Venture projects

Продажа товаров от производителей оптом и в розницу

14
Extrimtour

Extrimtour

extrimtour.com

14
likearea

likearea

smm.li

13
SE Ranking

SE Ranking

seranking.ru

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

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

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

Вступление

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

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

Проблемы

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

Выводы

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

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