100% agree with how confusing it all feels. Smudging data and code back together feels like a massive step backwards. I can't but be reminded of the disaster that was ASP.NET Webforms.

It took me a while to grok that in SSR frameworks, you shouldn't treat the SSR backend as a data backend. The best mental model is that the "SPA" just now has a client-server boundary in the middle of it. You should have a normal data API servicing the SSR backend.

With this approach, this does mean that client-server auth can now either live in the SSR backend or as normal on the data api. Arguably doing it on the SSR backend makes the most sense since that is now your server boundary. In this context the resurgence of auth in the SSR space make sense.

In my, arguably limited experience compared to some other folks, completely agree. It feels lite the correct solution here is to treat it as another kind of backend. I always keep the truth-keeper backend separate and with much higher quality requirements.