Micro frontends — from tribes to nations and back

Pros, cons, techniques and the impact on UI/UX

Micro frontends idea introduces the concept of microservices architecture to the frontend layer. It brings us all this legacy. All principles, approaches, consensus and, of course, concerns developed under that name.

It spreads the idea beyond the world of programmers. Includes all members of the team responsible for this layer. Requires UI and UX design to deal with the pros and cons of a micro service architecture. That makes the issue more relevant.

Micro frontends is a set of frontend applications in a browser window. They conform the following paradigms:

1. Technology agnostic. Any application can use any technology with an unlimited set of tools. HTML5 limits the possibilities to JS and CSS. That’s the only sure thing we can expect from any micro frontend.
2. Run-time integration. The process of developing, building and deploying each micro application should be independent. The focus here is on deploying. Updates, rollbacks and patches should not need any action in the main application. When such a main application exists, it is only a dumb container loading its elements dynamically.
3. Single business capability. “Do one thing and do it well”, says the unix commandment. This is of course relative, especially when it comes to the frontend. But it is a direction for planning an application.

This distinguishes it from an ordinary modular website. Each service is an independent instance responsible for its job. They should not care about each other’s existence. Only the browser window displays them together.

The key benefits of Micro Frontends:

• Teams working on different features have independence. They don’t need to synchronize their processes or maintain continuous communication. “Any piece of software reflects the organisational communication structure that produced it.”, says Conway’s law. The divisions between the responsibilities of the teams are visible in the application. This strong split is a good way to sort this out.
• Code can be rewritten app by app. Rewriting codes is a temptation that is always there. Especially in Agile software development, where the requirements are evolving. Breaking the system down into smaller parts helps to keep the code clean. Here, too, the larger reconstructions are less troublesome. Refactoring or updating the technology does not have to cover the entire system at once.
• Applications can compose any set. This is achievable with component-based frameworks. But when the boundaries are so strict, it forces the app’s design to serve exactly that purpose. Moreover, technological agnosticism opens up the possibility of consumption by third parties.

Iframe approach

The first thought on how to achieve it is Iframe. A solution to do exactly that — display many sites in one window. The safest and most stable way to achieve our goal. And this could be the end of the article, if not for the limitations that unfortunately Iframes have. They are not as flexible as we used to when designing the layout. It forces us to forget such popular features as overlays.

That’s why I mentioned UI designers earlier. Working with these constraints would be a challenge. Even more difficult would be to convince users to switch to the new style. But going back to using Iframes as intended may lead to some progress on this neglected feature.

Single document approach

The second approach is to use a single main HTML code. Load the JS micro frontend code there and render it to the specified place in the document. This eliminates the limitations of the layout, but has other drawbacks.

Here we lose the safe boundaries of the default framework configuration. It requires custom build, bundle and deploy. All the optimizations made there are now our problem. We cannot rely on future updates.

Working in the same context may lead to collisions. Requires some naming convention. HTML identifiers, CSS classes, cookies, or events must have prefixes. The namespaces should be all the more unique when you consider third party sites.

Speaking of CSS, the convention should be blocking global selectors. But that’s only a part of the problem. For layout consistency, CSS should be somehow global. The solution may be a shared presentation library. But, it must take into account the paradigm of technological agnosticism.

This is not the end of the difficulties for the UX and UI departments. The interface as a whole often has to assign a view to a global state. It can break the autonomy of micro applications. The strict approach allows micro applications to communicate only through the browser’s native functions. Dispatching and listening to custom events can do much of the work. Yet, it’s a specific type of communication that designers need to feel.

Technical concerns of Micro Frontends

• Bundle size. Each micro application includes its own copy of the framework and the entire toolkit. It multiplies the amount of data downloaded by the user. Vendor packages can solve this problem. However it violates the idea of ​​team independence.
• The complexity of maintenance. Pipelines, repositories, and all the infrastructure needed also multiply with each micro-application. Keeping this in order requires extra effort and resources.
• Change of shared parts. The exact flip side of the advantages of granulation. Problems arise when some common part of the system changes. It can be a small detail that applies to any micro frontend. In this case, you have to go through each micro application one at a time to add it.

Many micro frontend frameworks are available. They all use one of the methods mentioned with greater or lesser overheads, i.e.:

• FrintJS
• Single SPA

If you don’t use any of them, you have to write one. Which is not complicated and many tutorials introduce nice patterns, i.e.:

• Micro Frontends Tutorial
• Martin Fowler — Micro Frontends

Still, when implementing micro frontends, we leave the safe area. For now, it is at the pioneering stage and all the ways seem wacky. It recalls the chaos of pre-framework scripts mayhem.

With any solution you choose now, you’ll have to adapt to a professional tool once the topic becomes solid.