Задать вопрос
@mrcatmann
Fullstack webdev, art brut coder

Объединение SSR и бэкенда, подводные камни?

Планирую делать SSR-приложение, но пугает то что всё может быстро повалиться из-за двойного оверхеда (юзер делает запрос к приложению, SSR-движок делает запрос к бэкенду). Пришла в голову идея объединить фронт и бэк:
- если юзер заходит на страницу в первый раз (т.е. срабатывает SSR), то сервер подгружает нужный контроллер и напрямую вызывает его метод вместо HTTP-запроса;
- а если юзер уже перешел в режим SPA-навигации, то запросы к бэку идут стандартно по HTTP.

Есть ли какие-то неочевидные минусы у этого подхода?
  • Вопрос задан
  • 176 просмотров
Подписаться 1 Простой 1 комментарий
Пригласить эксперта
Ответы на вопрос 2
Sanasol
@Sanasol Куратор тега JavaScript
нельзя просто так взять и загуглить ошибку

- если юзер заходит на страницу в первый раз (т.е. срабатывает SSR), то сервер подгружает нужный контроллер и напрямую вызывает его метод вместо HTTP-запроса;
- а если юзер уже перешел в режим SPA-навигации, то запросы к бэку идут стандартно по HTTP.

Оно и так работает по этой схеме. Поэтому на SSR сервер нагрузки как таковой достаточно мало.

Кроме части про
сервер подгружает нужный контроллер и напрямую вызывает его метод вместо HTTP-запроса

Непонятно что вы имеете в виду напрямую вызывает какой-то метод. SSR же фронт отдаёт, а бекенд данные. Так о каком прямом запросе вообще речь идёт непонятно.
Ответ написан
@abberati
frontend-разработчик
Неочевидные минусы есть. Если захочется масштабировать, то отделять ssr от настоящего бэка будет больно. Смешение разных зон отвественности в одном приложении (и генерация статики, и контроллеры, и прямые вызовы контроллеров — всё в одной куче) порождают тяжело поддерживаемую систему
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы