Hacker News Reader

Comment by shireboy | Hacker News Reader

I’ve done strangler pattern for a large api and it worked well. I would like to use it for migrating a large Angular spa UI to Blazor. But that seems more daunting. Even if I did find a way to bridge and host Angular code inside the Blazor app, it just seems like it would be pretty complex. Has anyone done similar?

View on HN

You may have some luck moving Angular components into Web Components first. Even if those Web Components are still using Angular inside at first, it possibly creates API boundaries that you can more easily bridge/have a better idea what to replace in your component rewrites.

Yeah, I looked into lit as a possible way to do this, but was left feeling like then I had 3 things to juggle - lit, angular, and blazor. Should possibly revisit, though.

Yeah lit and angular have very different approaches. I was thinking along the lines of @angular/elements [0] which is closer to a "lift and ship". It is a very heavy solution to building web components (especially compared to lit code golf), especially if you are going to pair it with Blazor wasm, but if you are already using Angular in a large enough application and looking toward the path to Blazor wasm, you probably are in a bandwidth situation where you can afford the transitional steps.

[0] https://angular.io/guide/elements

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.

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.

Reply on news.ycombinator.com