Why apply micro-frontends approach?

[datanguyen]

Hi,
I have just been researching about micro-frontends for 2 months and it is really an exciting topic. Thank for your informative material.

I know that monolith & micro-frontends have their own strength and weakness, there is no silver bullet, but I want to ask you a question. "How can you convince people to use micro-frontends instead of monolith?"
I just want to know your ideas as a consultation, nothing more.

Thank in advance.

[DenisBiondic]

Isn't the first diagram at https://micro-frontends.org/ (organization in verticals) kind of self-explanatory, or do you mean something else? Basically micro frontends are like a special way of building verticals, where integrating multiple verticals via links is not enough, and for better UX you want to have multiple verticals (teams) integrated on the same page -> hence micro frontends aka. good old fashioned UI composition.

Also check https://scs-architecture.org/ for the broader explanation.

[ChristianUlbrich]

I always try to use two motifs to convince the management from the need for micro frontends:

1. time to market - scale, build, test and deploy your features faster
2. agility - no more vendor lock in
3. It has happened before and it will happen again - micro frontends are the brethren of micro services. Nearly all the arguments for the introduction of micro services do apply for micro frontends as well

[romainl]

@xdvarpunen micro-frontends are just like microservices: an architectural pattern. And just like microservices, that architectural pattern doesn't prescribe any specific technology. The frontend part of your micro-frontends can be ES6 + DOM4, or WebAssembly, or Flash, or whatever, and it could be served via Express, or Tomcat, or Apache, or whatever.

The author chose Custom Elements for his examples because… he had to choose something and he felt more comfortable using a standard technology—even if it's not yet widely available—rather than a fly-on-the-wall framework. It doesn't mean that you or anybody should do so.

I use React, she uses Vue, you use Angular, they use Custom Elements, and we all implement our own variant of the micro-frontend pattern.

[ChristianUlbrich]

@xdvarpunen I don't get, what your point really is. CustomElements is just an API; it can be reasonably polyfilled for all other browser in a very performant way. Angular+React are also using custom elements (i.e. angular-app), they just do not use the CustomElements API.

Available polyfills for CustomElements are production ready and support a wide range of browsers.

Maybe you are mixing up CustomElements with ShadowDOM. Because you need ShadowDOM for isolating styles and the actual DOM from the rest of the page. ShadowDOM can't be polyfilled, however if you are using a recent framework to actually build your WebComponents, such as AngularElements or StencilJS they will emulate the style encapsulation that you get with ShadowDOM automagically.

@romainl
You are right. However using CustomElements and thus WebComponents to implement a micro-frontend architecture there will be no vendor lock-in. Using React, Vue.js or Angular as the composition framework for your micro-frontend architecture, you'll have a vendor lock-in and you will impose certain technology constraints on the other teams and thus your architecture is not fully technology-agnostic anymore.

Which does not necessarily means, that it won't work.I saw in a recent presentation, that wix.com is implementing a micro-frontend approach by using React as the composition frameworks and it means, that all of the components need to be wrapped as React components.

[romainl]

@ChristianUlbrich Yeah, I totally get your vendor lock-in angle and fully agree with it. I was just trying to convey it in… different words.

FWIW, we too are doing it in React but if I were to write a reference I would do it in CustomElements.

[chchrist]

Only one question. How do you develop a performant and visually consistent product with micro frontends?

[ChristianUlbrich]

@chchrist
...or how to get a good Job
Let me answer it like that: How would you do it without using micro frontends? :) The real life behemoth monster monolith frontend apps I have seen, never touted a great performance nor where they visually consistent across the board.

Performance and visual consistency are non-functional requirements. They have to be specified. What is performance in general? What is it for you personally? What does performance mean for your (business) use cases. Achieving great performance for a landing page is trivial with or without micro frontends. Achieving great performance (whatever that might be) for a SPA with 100k+ LoC is not trivial with or without micro frontends.

Performance can mean, reactivity of the current "page", i.e. as less DOM manipulation as possible, to benefit from as few redrawing as possible. This is usually a problem not on the compositional architecture level but on the component implementation level. Use a frontend technology that does only necessary re-renders, fetch only incremental data. With micro frontends you can use React. You can use Vue.js. You can mix them all. Apply whatever floats your boat.

Visual consistency is also not hindered by micro frontends. Use a consistent visual design language, stick to the corporate identity, use proven and well-defined frameworks. Material Design has implementations for all the major big frontend frameworks. There are other UI libraries out there. OnsenUI provides UI re-usable web components that can be used in the major frameworks as well.

Micro frontends are just an architectural pattern, as micro services are. You can build fast or slow micro services, yet the mere move from a monolithic architecture will not automagically result in a faster overall service and guess what - it's the same with micro frontends.

[MartinDevillers]

The biggest advantage of this approach is not a technical, but an organizational one. Micro frontends enable an organization to split different features of an application across multiple teams, where each team is fully responsible for one specific feature. The value of a team is no longer defined as "Team Basket provides the market basket API" (low value), but as "Team Basket provides the best shopping basket experience." (high value).

In other words, organizing teams around technology (e.g. Team Backend; Team Frontend; Team Database) will get you technology-centered teams, who focus on doing just that: optimizing tech. Their responsibility will be limited to just providing a working API or database, which is nice but only one part of the puzzle.

Whereas, organizing teams around features (e.g. Team Marketplace; Team Order Placement) will get you feature-centered teams, who focus on optimizing features. Their responsibility will be providing a fully functional feature that delivers direct value to the business. While it's easier to organize around tech (just dump all frontenders in one team and the backenders in the other); the payoff of organizing around features is much more powerful.

The question I have is whether this approach will payoff for smaller applications developed by a single team (or maybe two). For instance with micro-services, it's trivial to split any API into a series of independent deployables. If you take it to the extreme, each method could live in its own GIT repo (or monorepo package), have its own tiny database, its own tiny Docker container (or lambda) etc. In reality, you probably wouldn't because of the added overhead of managing all these separate artifact. So I'm trying to find out what makes the most sense for micro-frontends.