Migration to Angular: micro frontend w/ web components vs lazy loaded modules?

user_6647188 0
Viewed 240

We have an large application spread across multiple teams, built with Java Server Pages. The goal is to migrate to Angular. A monolithic migration/launch was deemed not practical, so a gradual migration is preferred.

The idea is to use a Webpack 5 Module Federation app shell to load Angular micro frontend remotes into the existing JSP app. The question is whether to load the remotes as Angular apps or Web Components. The thought is that Web Components might allow them to embed a reusable microfrontend fragment into the JSPs in cases where they can't migrate an entire page at once, or they have components that will exist in both the unmigrated JSPs and the new Angular pages.

After the migration, they'll either keep the micro frontend architecture if it's justified, or abandon it and merge the remotes into one Angular app.

Another alternative might be lazy loaded modules rather than opening the pandora's box of micro frontend architecture. Just informally split the app up into lazy loaded modules per team. Downside here is possibly more teams stepping on each others toes in the repository, but that's no different than how they've been operating. Their concern about lazy loading modules is they don't think they'll be able to do something like this:

<!-- my ancient JSP site. LOL page load with every click -->
<JSP-header></JSP-header>

<myAngularComponent></myAngularComponent>
<script type="text/javascript" src="https://lawlcats.com/myAngularComponent.js"></script>

<JSP-footer></JSP-footer>

All in all, the proposed solution is incredibly complex. These teams are brand new to Angular and are already considering combining different frameworks within a micro frontend architecture, AND implementing web components. Sounds like a huge lift to me. I'm also unsure if they've considered how they'll manage the repository across teams.

Does anyone see room for improvement or flaws in this plan? I'd love suggestions for the micro frontend remotes being Angular vs Web Components, vs abandoning micro frontends altogether in favor of lazy loaded modules.

angular typescript jsp javascript java
1 Answers

Well, it would be good if your team first fully grasped what are the implications of MFEs or WebComponents as tools.

Micro Frontends are self-contained, stateful, full-fledged, and fully black-box applications. Maybe it would help your team to think about them as iframes.

You stick a MFE app somewhere on your page, and that is it. It does its own thing. The host app just hosts all the MFE apps on all the different http ports, but it doesn't know anything about what's going on inside of them.

In the simplest classic example, there is no communication between the host and the apps, and the apps also never ever talk to each other. AFAIR, if you wanted them to communicate, it's theoretically possible to do that via http (since they do actually live on specific ports), or wild shenanigans like utilizing LocalStorage. But it's generally not easy.

WebComponents, on the other hand, are just raw components that do one specific thing. They are also black boxes, but usually super tiny and thin. You can think of them as something like input.

An input knows how it should be styled, it knows which raw browser Web APIs it should talk to, it knows that it should render text in response to the user typing on their keyboard, and how to expose a couple values and events to the external world. But ultimately, an input in itself is pretty dumb and can hardly be called an "application". It's just a small building block of the actual modern JS app.

inputs also don't talk to each other - why would they - but they expose clear, native html APIs for input and output, so the host app can very easily talk to them and make use of them. The host is still responsible for actually knowing how to do that though.

As for your use case, your options depend on your team's technical and business needs.

  1. MFE Federation is a pretty strictly defined type of architecture. It might work in your use case, but you'll need to consider that trying to organize any kind of communication between these separate apps later on is asking for trouble.

  2. On the other hand, if you really want to just have a bunch of modern JS components that you could stick anywhere in your existing JSP code, then WebComponents might be your best bet. IIRC, Angular components can be built and used as WebComponents like in your example, so it could be viable to write them in Angular (and then possibly migrate the entire app to an actual Angular SPA sometime later). The problem is that these components won't do anything by themselves, they still need the host page to actually use them.

  3. It might also viable to write just one application with a bunch of lazy-loaded modules - which the standard straightforward case in modern Angular - and let it live under some specific routes. You would then just start rewriting pages in Angular one by one. Nobody likes that, but sometimes it's just what has to be done. As an upside, in that case at least you would have an actual modern Angular app as the host for all the JS components, instead of whatever JSP thing you currently have.

  4. In theory you can mix-and-match approaches 2. and 3., with some pages only partially using the new shiny WebComponents, and some pages fully rewritten. It's probably what will have to eventually happen, but I'd try to initially stick to just 2 or just 3, to make the first steps of the migration simpler for your inexperienced devs.

Whether you choose Webpack MFE Federation, JS/Angular WebComponents, or a simple Angular SPA, I would strongly recommend looking into NX, which is a very powerful, framework-agnostic JS monorepo toolset. Among other features, it should help you solve the problem of managing the code between teams.

With NX, you can add arbitrary tags to all of your modules, and make the linter track and ban the dependencies between specific tags. As a simple example, your could say that modules tagged team-a cannot be used by team-b or team-c, so that Team A can safely do whatever they want in them without breaking anything that other teams actively use.

user_35692460
Related