Когда нужен SSR?

Хороший вопрос для собеса, между прочим.

Хотя ответ очень простой. SSR нужен для быстрой отдачи персонализированных данных. И это очень редкий кейс. Уточню, SSR - это новый рендер страницы на каждый запрос каждого пользователя. Но чаще всего в интернете вы открываете контент, который создается статически, а не генерируется на лету под каждый запрос. Блог пост, список элементов или карточка товара - все это можно формировать во время появления в CMS и такой подход называется Static Site Generation (SSG). Генерить html нужно для каждой версии контента один раз и отдавать на всех пользователей одно и тоже. В таком разрезе не важно какую технологию вы будет использовать, вы можете никак не ограничивать себя в клиентском коде, а на сервере использовать headless browser.

Конечно, иногда специфичность данных такая большая, что всю ее сгенерировать заранее невозможно. Например, у нас есть интернет магазин и ML’ки, которые на каждый запрос пользователя генерят самые подходящие похожие товары. Возможно, у вас есть часто меняющийся список с большим количеством фильтров и сортировок, комбинаторику которого не эффективно покрывать через SSG. В этих случаях SSR может быть хорошим решением.

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

И проблема не только в DX. Производительность с SSR падает! При клиентском рендеринге вам нужно отправить странспиленный JSX и отрендерить его. При SSR вам нужно сделать то же самое, но сначала подождать рендер сервера и отправить HTML, а в самом конце провести регидратацию. В итоге, вы скорее всего выиграете (не факт) на скорости показа первого экрана, но точно проиграете на времени когда ваше приложение становится интерктивным.

Тут важно заметить, что проблемы которые решает SSR не всегда нужно решать именно им, можно оставить просто клиентский рендеринг. По производительности выигрышь лучше получать оптимизацией используемых зависимостей, а CEO в указанных случаях нужен далеко не всегда. Зачем вам SEO на список элементов, каждую конфигурацию которого может увидеть только один пользователь?

Для меня SSR - это деньги и нервы в трубу, я всегда буду стараться его избегать для профита бизнеса.