Why we chose Angular SSR for a real-time product

When people hear "SSR" they usually think of blogs and landing pages. Our product is neither — it is a realtime conference tool with sockets, auth cookies, and a workspace that reshuffles every time a session is added. So why go through the trouble of rendering it on the server at all?

First paint that feels instant

Attendees click a conference link and expect to see the agenda, not a skeleton. With SSR, the first HTML payload already contains the schedule. By the time the client bootstraps, the user is scrolling real cards instead of waiting on a spinner.

Cookie-forwarded API calls

Authenticated resolvers use the same /api endpoints as the browser. A small HTTP interceptor forwards the inbound cookie header on the server so the SSR render sees the logged-in user. The workspace loads pre-populated — no post-hydration flicker as the session resolves.

It is not glamorous plumbing, but it is the difference between "the app is fast" and "the app feels slow even though it is fast".