In anticipation of Manfred Steyer's session, Micro-Frontends With Module Federation: Beyond the Basics, Richard Wallintin (WPS - Workplace Solutions) had a number of questions for Manfred about his enthusiasm for module federation, the future with micro-frontends and what challenges teams can face with frontend frameworks.
You expressed a lot of excitement around module federation and the massive advances that have happened in the last year. Are you still excited, or does the rush start to fade?
For me, Module Federation is really a game changer. It not only gives us an implementation for loading separately compiled and deployed code like Micro Frontends or plugins but also a mental model that makes it easy to reason about such systems.
Micro-Frontends are becoming more feasible now. Will we soon see enterprise user interfaces seamlessly mixing Angular, React, Vue and You-Name-It? Follow-Up: Are there standards around to mediate between frameworks?
Well, Micro Frontends make such “Frankenstein-Solutions”, as I call them, possible. However, it should never be the upfront goal to mix and match all the possible technologies. Just because we can do it does not mean we should. I see it more as an insurance for the mid- and long-term: If we need to switch over to another stack little by little, Micro Frontends make this possible. Hence, Micro Frontends are especially interesting for enterprise-scale applications that are actively developed by several teams for several years. If you only have one team that works on a piece of software for some months or a tiny number of years, Micro Frontends are very likely an overkill. As everything in this world, they come with several consequences – obviously, not all of them are beneficial. I would not go that far to say that there are standards for the mediation between Micro Frontends. But there are for sure standards that make it easier to deal with them. Examples are Web Components – including Custom Elements, Shadow DOM, and Custom Events – but also Import Maps and EcmaScript Modules in general. Also, Module Federation with its mental model can be seen as a de facto standard that help here.
One more prediction question: Another long-anticipated recent innovation are standalone components. Will Angular modules disappear in consequence?
I would not say „disappear”, because this would be a breaking change. The Angular team’s goal is to prevent breaking changes. But – and I’m really excited about this – they became optional with Angular 14. Beginning with this version, you can use so called Standalone Components that are – more or less – self-sufficient. I say “more ore less” because each piece of software can depend on other pieces like services. With Version 14 they are in developer preview, but they give a nice outlook to (one aspect of) the future of the framework.
Rich frontends running in browsers (using Angular or other frameworks) are well established and popular. What are the hard problems teams face today compared to 3 or 4 years ago? Or is it all recurring issues?
This one more time shows that in Software Architecture (and very likely also in life) everything has consequences. Sometimes we don’t see these consequences anymore because we that used to them. SPAs are no exception here. SPAs are a good solution for enterprise applications. But, as you say, for public web sites where conversion and hence start times is a topic, there is some room for improvement. When looking at the mentioned new generation of frameworks, we see indeed a comeback of Multi Page Applications and server-side rendering. However, not in a classical sense, but more in a way where the server-side and the client-side grow together. If they know about each other, we can better combine the benefits of both worlds. Currently, these frameworks are in early stages and primarily focus public content-rich websites.
Which other talks are you curious about?
There will be several sessions about DDD-related topics. For me, this is quite an important topic because it gives us a methodology for bridging the gap between the user’s requirements and our software architecture/ design. Technologies come and go, but Domain-thinking sticks. Hence it can guide us in the long-term.