Масштабирование SSR-приложений

[OlegSpectr]

Олег, привет!
Начал читать статью, увидел про tramvai, понял, что уже видел эту статью у тебя в ТГ)
Есть такой вопросик: допустим есть сайт с динамикой, но без какой-то персонализации. Есть ли вариант использования SSG в этом случае, или хватанём больше проблем, чем профита?

[SuperOleg39ru]

Привет!

Если есть возможность динамику выполнять только на клиенте, и не пострадает SEO - кажется SSG вполне подойдёт.

Но надо заранее продумать как планируется обновлять контент, добавлять новые страницы - тут уже есть кейсы когда без сервера не обойтись)

[OlegSpectr]

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

[SuperOleg39ru]

Incremental Static Regeneration у некста в этом плане хороший

[noodles]

Присылайте ваши варианты оптимизации и масштабирования SSR-приложений

• Всё что за авторизацией - на отдельный поддомен, чистый client-side rendering, отдельный репозиторий. Как правило там вся настоящая динамика. Туда ставим работать отдельную команду фронт-синьоров-помидоров.

• Всё что до авторизации - любой хороший "бекенд-движок" с генерацией шаблонов. Например Symfony. Там же пусть и будет апи жить к первому проекту. Динамика здесь как правило не сильно сложная, джиквери должно хватить. Если не хватает то можно выделить "очень динамичный" div и в него рисовать реактом. Также отдельный репозиторий. И на фронт-twig-шаблоны отдельная недорогая команда\человек с опытом поменьше (aka верстальщик).
  
  Ну да, придётся однаждый два раза сверстать хедер\футер. Невелека проблема, по сравнению с теми что могут быть при ssr на node.
  

[SuperOleg39ru]

Почему кстати считаешь что у node.js с ssr больше проблем чем у Symfony с шаблонизатором?