Working on a single-page application (SPA) can result in many people working on the same code trying to make changes and causing conflicts.
Micro frontends can help you solve the problem. However, it may bring about challenges too.
We have gathered significant advantages and disadvantages of micro frontends to help you make an informed decision whether you should adopt them.
In the article, you will learn:
- What are micro frontends;
- Advantages of micro frontends;
- Disadvantages of micro frontends;
- Best practices to build micro frontends;
Micro frontends are basically an extension to a microservices pattern, where the functionality is extended to the front-end. As a result, micro frontends bring a wide range of advantages, including deployment independence, easier testing of features, etc.
No wonder that micro-frontends are becoming a trend for building web-based applications. Some of the business giants, including IKEA and Spotify, have already embraced micro frontends.
For a better understanding of this notion, let’s compare the microservices and micro-frontend architecture of a web application.
Simply put, a typical web application architecture looks like the following:
So, the web application consists of components or features. What’s important is that each of these components has its own codebases, CI/CD pipelines, and DevOps practices. Also, depending on their size or organizational structure, they may be developed by separate teams. However, it is still a SPA, which means that teams can distract each other while developing their features.
So, if we take the e-commerce platform as an example, the shopping cart service provides API methods, such as list cart contents, add an item, remove an item, etc. All these features are connected to the same page, thus, are interdependent.
In the case with micro frontends, the architecture looks more like this:
Unlike a previous option, features in the form of micro frontends are independent. Let’s again take the e-commerce platform as an example. Let’s say the page contains the following features: variant selector (shows different colors of the available item, for instance), buy button, and mini basket (leads to the checkout).
The page consists of components owned by three separate teams. Let’s call them the checkout team, product team, and recommendations team. The first team is responsible for the process of purchase, namely the buy button and mini basket. The second owns the page itself (decides on the features and the layout of the page). At the same time, the third team places products that can also interest a customer on the page.
So, the micro frontend application becomes an aggregation of smaller independent applications.
But why do you need micro frontends? What benefits can they bring? Let’s find out together.
Some of the key benefits you can get from micro frontends are:
- Better scalability;
- Faster development, as teams can work independently. This benefit, however, is applicable only if your project is big and has more than one front-end team;
- You can use multiple frameworks in your application. However, it should be done mindfully and transparently to avoid confusion. Nevertheless, you have a choice of what to use for a particular task. What’s more, a development team can choose their own technology;
- Deployment independence. The delivery of your micro frontend will not affect the entire application. The changes will affect precisely that part of the business process that it has covered;
- With micro frontends, you can upgrade, update, or even rewrite parts of the frontend more smoothly than was previously possible;
- It's easier to ensure that rest of the app remains stable, as it's independent. With micro frontends, you no longer need to keep track of the whole app. A team reviews a specific micro frontend, which has been changed or expanded;
- Codebases are smaller and more manageable;
- Easier hiring of experts. With micro frontends, you look for professionals to work on a specific part of an app where a particular tech stack is used, so you do not need them to know technologies that other teams use;
- Easier testing, as you test just separate features;
However, apart from benefits, micro frontends can bring about some disadvantages and challenges. Let’s view them in more detail.
- Complex testing of the application as a whole. Now that your application dynamically loads content, it can be harder to have a complete picture of the application. Each front end can be tested in isolation, but getting a real-world user test is critical to ensure the application works for the end-user. You can utilize usual black-box end-to-end testing with tools like Selenium or Cypress, as it's agnostic to the implementation details;
- The wide variety of standards you have to keep up with. The application is broken into smaller parts; thus, it can be challenging to keep all developers working off the same standards. Keeping everyone on the same page is essential to delivering a high-quality user experience;
- Adopting micro frontends is a good idea for your business if your project is big and has more than one front-end team. With a small team, it is not worth the struggle;
- The deployment, assembly, and configuration process for each micro frontend will be different, which requires additional effort.
Nevertheless, you can overcome all these challenges and more by following these best practices.
One of the essential things about micro frontends development is to enable your teams to deliver independently. To do so, you should create responsibilities and goals with roles that everyone can agree on. Also, you need to ensure that you have well-designed and consistent API contracts (documents where you declare how your API will behave) between teams.
Once you do so, your teams will be able to move independently to accomplish their goals.
Also, it is a good idea to align business requirements with modular delivery. If your business requirements demand everything to be designated at once, you’re not getting the most out of your micro frontends. Basically, you have a micro frontend architecture but a monolithic organization.
Micro frontend architecture requires build and deployment automation. Otherwise, you risk gridlock. This is certainly true in any environment, but it’s vital in a highly modular architecture. So focus on building CI/CD.
Test automation is the key, and so is testing at multiple levels. Your testing process aims to ensure that you can move components of your architecture without issues arising on the production. Therefore, focus on building testable dependencies for micro frontends that are clear and are validated automatically.
Don’t overuse micro frontends
If you over-apply the micro frontend, you can end up over-fragmenting your application and creating things that don’t have any real value. There’s a great deal of literature that discusses the right size of micro frontends and what should or shouldn’t be built at a service. You don’t want to over-optimize.
When deciding how to split micro frontends, watch for potential challenges. For instance, module architectures require different testing strategies for each module. So look for applications that require independent deployment. The features that need to be dynamic and adaptable over time should be made a micro frontend.
Find the right size of your micro frontends
Finding the right size for your micro frontends is similar to thinking about how to size microservices. They need to be just right. If they’re too big, your application is too tightly coupled. If they’re too small, your application is fragmented. Consider how you might strike a balance.
Unfortunately, there’s no golden rule when it comes to this. Everything depends on a specific application. However, remember that each micro frontend should have a definable business purpose in isolation.
For instance, you probably can build an individual micro frontend for every icon in a menu bar. But it would be wiser to make the entire menu bar as one micro frontend.
As you consider a micro frontend architecture, be sure to make these decisions in advance. How you divide your app should be pretty well defined.
In N-iX, for instance, Solution Architects are the professionals that make such decisions in the team.
It heavily depends on your business case, whether you should or should not adopt micro frontends. If you have a small project and team, micro frontend architecture is unjustified. At the same time, large projects with distributed teams and a massive number of requests benefit a lot from building micro frontend applications. That is why today, micro frontend architecture is already widely used by many large companies, and that is why you should opt for it too.
Why choose N-iX for building your micro frontends?
- N-iX has over 18 years of experience in various industries, including healthcare, telecom, fintech, manufacturing, and others;
- The company has 1,400+ top-notch professionals on board that can help you develop your solutions;
- We boast strong cloud expertise. Our experts built cloud-agnostic and cloud-native solutions for over clients from the US, the UK, and Europe;
- N-iX complies with international regulations, such as ISO 27001:2013, PCI DSS, ISO 9001:2015, GDPR, and HIPAA, so your sensitive data will always be safe;
- N-iX has a robust portfolio of data projects, including big data, data science, and data analytics.