Планирую делать SSR-приложение, но пугает то что всё может быстро повалиться из-за двойного оверхеда (юзер делает запрос к приложению, SSR-движок делает запрос к бэкенду). Пришла в голову идея объединить фронт и бэк:
- если юзер заходит на страницу в первый раз (т.е. срабатывает SSR), то сервер подгружает нужный контроллер и напрямую вызывает его метод вместо HTTP-запроса;
- а если юзер уже перешел в режим SPA-навигации, то запросы к бэку идут стандартно по HTTP.
Есть ли какие-то неочевидные минусы у этого подхода?
- если юзер заходит на страницу в первый раз (т.е. срабатывает SSR), то сервер подгружает нужный контроллер и напрямую вызывает его метод вместо HTTP-запроса;
- а если юзер уже перешел в режим SPA-навигации, то запросы к бэку идут стандартно по HTTP.
Оно и так работает по этой схеме. Поэтому на SSR сервер нагрузки как таковой достаточно мало.
Кроме части про
сервер подгружает нужный контроллер и напрямую вызывает его метод вместо HTTP-запроса
Непонятно что вы имеете в виду напрямую вызывает какой-то метод. SSR же фронт отдаёт, а бекенд данные. Так о каком прямом запросе вообще речь идёт непонятно.
abberati, ну так в этом и суть ssr, что вас не устраивает-то? Откуда здесь двойной оверхед если вместо юзера сервер сам к себе обращается, тут наоборот выигрыш в скорости загрузки как минимум. Юзер эе не стучит в итоге на сервер по запросам которые ssr сделал при загрузке страницы.
А еще у ssr есть кеш, так что совсем не каждый раз он отрабатывает по полной программе.
Неочевидные минусы есть. Если захочется масштабировать, то отделять ssr от настоящего бэка будет больно. Смешение разных зон отвественности в одном приложении (и генерация статики, и контроллеры, и прямые вызовы контроллеров — всё в одной куче) порождают тяжело поддерживаемую систему