2 ms·

Bridging server side and client side rendering is going to be really tricky, and it may be fairly jarring from a UX perspective. Routing is going to be your bi

Bridging server side and client side rendering is going to be really tricky, and it may be fairly jarring from a UX perspective. Routing is going to be your biggest challenge, as the SPA will be effectively reinitialized when you route back to it if you keep it as-is. I would try switching the SPA to render on the server entirely/for specific components if possible, knowing there will be angular code changes to support this, then do a progressive blazor rewrite of individual paths. Your app is going to run like hot garbage during this transition though, so you'll need plenty of buy-in to attempt this.

shireboy 2y ago
Well, in this case I'd be fine with client-side Blazor (WASM mode), as there is a mature REST API and it is an internal app where SEO etc is not important. But yes, routing is one hassle as well as the complexity for developers etc. We had this issue some when we did the api: ie say an issue was reported - developers would first have to figure out "is this a problem in apiv1 or apiv2, or in the way apiv2 proxies to apiv1?" Absolutely needs to be buy in that we're going to commit to finishing the migration in a reasonable time. I still like that we did strangler pattern for the API vs the "rip the bandaid off" pattern, but it does carry some baggage that can be glossed over in some articles about it.