Вступление

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

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

Проблемы

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

Выводы

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