Common Pitfalls to avoid when Building Microfrontends

We’ve come a long way! We’ve learned how to build microfrontends, how to deploy them to the native cloud, and how to manage them in production.

As we start working with microfrontends, we will make mistakes, but we will learn from them and eventually build our own set of best practices, discovering what works best for our use cases. However, it is always a smart thing to learn from others’ mistakes as well. In this chapter, we will cover some of the pitfalls earlier teams faced when working with microfrontends.

We will teach you about some common pitfalls and how to avoid them, which are as follows:

• Not making your microapps too small
• Avoiding the overuse of common shared code/libraries
• Avoiding multiple frameworks within a microfrontend
• The inability to deploy individual micro apps
• Excessively relying on state
• Avoiding build-time compilation to assemble Microfrontends
• Avoiding...

Don’t make your micro apps too small

We touched upon this at the start of the book, but it’s important to stress it again. Way too many developers think that, in a microfrontend architecture, the micro apps need to be really small. This is not true, as creating very small microapps greatly increases the complexity and maintenance headaches, without achieving any benefits.

In trying to identify what the right size is for your micro app, we’ve seen it helps if we take into consideration the following points:

1. Is it the largest possible micro app that can independently exist?
2. Is it the largest possible micro app that’s owned by a single agile scrum team?
3. Does this app undergo changes and updates that are at a pace different from the rest of the application?
4. Another point to consider is thinking in terms of domains, based on domain-driven design principles, to determine what business features a given micro app should support or not support...

Avoiding the overuse of Shared Component Code

When it comes to building microservices or microfrontends, team independence is the highest priority. Anything that makes a team dependent on another team should be strongly discouraged.

In our experience as software developers, we’ve always come across principles such as reusability, Do not Repeat Yourself (DRY), and so on. In fact most senior developers are constantly looking how do they create common utilities, helpers shared components, and so on, to help the teams be more productive.

However, when it comes to the world of microservices and microfrontends, overuse of these shared libraries can lead to what is called “dependency hell” or a “distributed monolith,” which is the worst of both worlds.

This is bad for microfrontends because using shared libraries or code immediately takes away the independence of teams, as now two or more teams are dependent on updates or bug fixes to be made for...

Avoiding using multiple frameworks in your microfrontend

One of the benefits of microfrontends is that, technically, it’s possible to have each app built using a different framework. However, just because it’s possible doesn’t mean you have to. There are numerous drawbacks to using multiple frameworks within a single microfrontend:

• The cognitive overload for team members as they potentially switch from one team to the other over time is very high.
• Since every framework comes with its own JavaScript bundle, and since every framework will have a different set of NPM modules that the team uses, the amount of JavaScript code transferred to the user’s devices will be high. Therefore, we will not be able to take full advantage of browser caching or service worker caching, since each app uses its own bundle.
• Different frameworks will have different performance challenges and issues, and each team will have to deal with them individually and not...

An inability to deploy an individual micro app

One of the primary reasons to adopt a microfrontend architecture is to allow certain parts of an application to be independently updated without impacting the rest of it.

This obviously means that we need the ability to build and deploy each micro app independently. If your DevOps build and release pipeline can’t do this, then it’s better to go with Single-Page Application (SPA) architecture.

In the past, many DevOps tools weren’t sophisticated enough to work with monorepos or microfrontends; however, most of the latest tools are better equipped to detect which folders have changed and only trigger the necessary app builds.

Hence, when working on a microfrontend architecture, it is critical that you’ve thought it through and through, including how it will be deployed, as this will impact the choice of tools you select for the DevOps pipeline or the monorepo.

For example, if your DevOps pipelines...

Excessively relying on state

With the advent of React, state management became a thing, and with it rose the popularity of tools such as Redux that advocated a single central data store to manage state. Over time, developers seem to have become obsessed with state management, relying far too much on these state management libraries. When developers make the shift from SPAs to microfrontends, they continue their obsession with state and spend a lot of time trying to persist state, making it work across different micro apps. With SPAs and also microfrontends, it is important to sparingly use these application-level states. When working with microfrontends, we encourage exploring concepts around Pub/Sub or an event emitter approach to sharing data between different micro apps. Alternatively, look at native browser data stores, such as session storage, IndexedDB, or local storage to manage persistent state, or if none of these is an option, then explore lightweight state management libraries...

Avoiding build-time compilation to assemble Microfrontends

There is a current trend in the frontend community to move as many tasks as possible to the build time phase of application compilation, rather than the runtime. Good examples of these are static site generation, where the HTML pages are generated at build time, or Ahead of Time (AoT) compilation in Angular, which improves the overall performance of an application.

While, in general, build-time compilation is a good practice, reducing the load on the browser and JavaScript engines during the runtime phase, it doesn’t help when assembling the microfrontend. This is because every time any microfrontend changes, you need to rebuild the assembly layer as well, defeating the principle of independent micro app deployments.

We can choose to have individual micro apps do more work during build time (e.g., generate static pages), but the assembling of micro apps or module federation should always be done on the server or...

Avoiding packing your micro apps into NPM packages

Another common trend within the SPA world is to convert any sharable modules into NPM packages for easier distribution and then import them into other apps.

In our experience, we have seen a few teams package and version their micro apps into NPM modules before importing them into the host or assembly app. We strongly discourage this practice for the primary reason that every time a new version of a micro app is published as an npm module, all the hosts using that micro app will need to update their package.json files and rebuild and redeploy their apps, defeating the primary principle of independent deployments. We covered this in a bit of detail in Chapter 2, Key Principles and Components of Microfrontends, in the Prefer runtime integrations section.

Summary

With this, we come to the end of this chapter. Being a relatively new architecture pattern, the concepts and best practices around microfrontends are constantly evolving.

In this chapter, we saw some of the common pitfalls that teams have fallen into while building microfrontends – namely, things such as not being able to identify the right level at which to break down an app into a micro app, overuse of state management libraries, using multiple frameworks within a micro app, the inability to individually deploy a micro app, overuse of shared common code, and ending up with a build-time integration. Hopefully, this chapter will prevent you from repeating the same mistakes your peers have made in the past.

Another important point to remember is to understand the reasoning behind these best practices, looking at them through the lens of your specific use case. Follow the best practices that apply to your use case and tweak the ones that don’t quite fit it...