LogicFlow AG
Office 2005
Technoparkstrasse 1
CH-8005 Zürich
Switzerland
VAT No.CHE-445.455.310 MWST
Times of single web pages are a thing of a forgotten past. These days web applications are becoming complex that delivers us better experiences that are enriched by user interactions and flows. However, these complex apps need large developer teams as well as sophisticated deployment systems. In this article, we are going to discuss the pros and cons of Micro Frontend Architecture. And next week we will show you the implementation in the upcoming blog.
SPA or single-page application is the most commonly used pattern for modern web applications. The main function of SPA is to build a single web application that is then delivered to the user. It rewrites the content of the page with regards to each data change or user interactions. Mostly SPA has a router that helps deep linking as well as page navigation that can consist of multiple components.
The standard steps that SPA follows: first, the user visits the web app after which the browser requests CSS and Javascript. Second, after JavaScript has been started, it adds the primary content to the browser document. Then via acts like clicking a navigation link, the user interacts with the app, which makes the application to rewrite some parts of the browser document to show the changes.
Commonly, the JavaScript framework is utilized to obtain the functions mentioned before. Whilst Angular, Vue, and React frameworks have patterns that help to build an SPA.
Even though SPAs are quite modern, they are far from perfect as it has a lot of setbacks. Shortly, it lacks the framework complexity and due to the loss of search engine optimization, the app is not being presented until the user sees it in the browser (which leads to losing many keywords that will stand in the way of your attempts of going up the search ranks). The other con is the browser performance that prevents you from delivering a smooth user experience. It all adds up to the main issue that is a scale, and the solution to which is Micro-frontends!
Micro-frontends consist of small applications that work together to present a bigger application. But why do we need them? Shortly, this is due to the reason that projects vary in their requirements and sizes. Micro-frontend can be excluded if your project can be handled by a single team and consists of only two to three pages. They can be implemented by one of the frameworks such as Vuejs, Angular, and React.
However, if some sections and features of your frontend app were developed by different teams or your app is just a part of a bigger application, then that’s where micro-frontends come into play.
In order to deliver this large app, smaller applications must communicate with each other. It can be done via window object, event bus, and publish or subscribe method. Every app can communicate all the way to their backend separately and each app also can be realized by any of the frameworks as well as teams. Depending on the routing or user interaction, there is a launch or bootstrap app that loads these apps and assembles/unassembled in the DOM.
So what are the advantages of such architecture?
Apps are small and independent
As large apps are split by pages, features, and/or sections, apps become much smaller. And thus, they are independent of each other.
Ease in development, execution, and testing
It’s way easier to develop and deploy these apps as they are small and developed by a single team. Each app in micro-frontends has few unit tests and implements its tests that can be done independently, which makes it way faster in comparison to larger apps that have thousands of unit tests.
Faster development of apps
Due to separate teams, the development process is faster as well as easier.
Change in CI/CD process
As each app is integrated separately, the CI/CD process becomes so much simpler and easier. By integrating a new feature, the whole application won’t be disturbed as all features are independent.
No more shared code
If in the large application the same code is shared, this can introduce a lot of bugs and the dependency across will be higher as the app becomes larger. But this is not the case with Micro-frontends as they don’t share the code (excluding the case of a dumb component)
Altering architecture without disturbing the old one
Micro-frontends allow us to develop new features with the newest stack and supply them independently.
Although micro-frontends seem like the most perfect solution. Nonetheless, it does come with certain setbacks:
Duplicated dependency
Webpack is able to deal with shared Node modules but what if one of the team is using Lodash while the other one is using Ramda? Then we are combining two functional program libraries in order to achieve the same thing.
The other side of testing and deployment.
Although we have discussed the advantages of faster testing and easier deployment in micro-frontends, managing and keeping track of micro-frontends comes as a challenge itself. If you’re not completely positive about what’s being loaded into the application during at execution time, deployment can become difficult and risky. Thus, it becomes harder to test, because in order to get a full picture as a real-world user must be conducted to know certainly if the application is working as it is supposed to be.
Standards
Like we have discussed before, as one large application is broken down into small apps, it’s certainly a challenge to make sure that all developers working by following the same standards. There certainly can be a case that one team is more advanced than the other ones, where they have improved the code quality or something along that nature. Nonetheless, it introduces its own set of problems of making sure that everyone operates on the same level in order to provide a high-quality user experience.
Although micro-frontends are not invincible, it is really great for modern web apps that are becoming even more complex day by day. Generally, micro—frontends are easier to test, deploy and understand larger applications. One of the great things is that each app can be developed independently, they don’t need to share logic, you can add new features without disrupting the whole thing, and it either can be managed by single or multiple teams. Even though it seems that micro-frontends are like a silver bullet, it’s not ideal to use for every kind of app, for instance with small applications. And lastly, it’s recommended to use a different framework for every app, therefore, simplifying it for yourself as much as possible.
Reach the automation level you are aiming for
Leverage no-code and write custom code where needed
Visualize your end-user experience all in one place
Make your deployment decisions easy