A good frontend is tough to develop, but scaling frontend development for several teams to work at the same time on a large and complex project is even tougher. In this blog, we will understand Micro Frontends in Action, Architecture and Integration Approaches and the current trend of breaking frontend monoliths into multiple smaller, manageable, and independent pieces and how the micro frontend architecture approach can help operation managers to improve the efficiency and effectiveness of their team working on frontend code. Apart from this, we will also discuss different ways to integrate this architecture into the frontend.
What are Micro Frontends?
In recent years, microservices popularity has incredibly increased. Many organizations have adopted microservices as their application’s architectural style to break free from large, monolithic backends. It has been labelled as server-side architecture and many companies struggle with monolithic frontends.
Maybe you want to develop a progressive web application and use JavaScript language features but can’t find an easy place or the needed build tools in your existing build process. Or perhaps you want to scale deployment so that multiple teams can work simultaneously but the complexity and coupling of monolithic applications make it impossible to do so.
Read: Microservices vs API
Hence, attention is being paid to the overall organization and architecture structures required for modern, complex web applications development. Now we are seeing patterns arising for breaking frontend monoliths into smaller, uncomplicated pieces that can be developed, deployed, and tested independently, while still emerging as a single cohesive product. And this technique is what we refer to as Micro frontends.
Read: Tools for Monitoring Microservices
A micro frontend architecture is a style of architecture that combines independently developed front-end applications into a larger whole. The term micro frontend first arrived in ThoughtWorks Technology Radar, 2016. Simply put, a micro frontend extends the microservice architecture into the frontend world.
The idea behind micro frontend is to think of a web application or website as a blend of features owned by independent development teams where each team has a different mission it handles and specialises in. In a micro frontend architecture, a team is considered to be cross-functional that develops its features from databases to user interfaces.
What are the Benefits of Micro Frontend Architecture?
Now you have an idea of what micro frontends are. It’s time to emphasize the technical and organizational benefits micro frontend architecture has to offer.
-
Simple, decoupled codebases
By definition, the source code for each micro frontend will be much smaller than the source code of the monolithic architecture based frontend. The application with its frontend will be divided into smaller systems where each team will own its smaller frontend. Being smaller, these codebases become simpler and easier to work with. Besides, small codebases help developers to avoid the difficulty of unintentional and inappropriate coupling among components that don’t need to know each other.
-
Optimize for better feature development
In the layered monolithic architecture, multiple teams are involved in creating a new feature leading to several team discussions, meetings, and written specifications that consume a lot of time.
Read: API VS Web Services VS Microservices
However, one of the crucial benefits that micro frontend architecture offers is the ability to incline the speed of application feature development. In the micro frontend model, every developer who is involved in developing a feature works in the same team which reduces time consumption and makes the development process less formal and faster.
-
Incremental Updates
Unlike monolithic applications that are held back by old tech stacks and written under pressure for delivery where a complete rewrite of the source code seems tempting, micro frontend architecture allows developers to make decisions independently on an individual part of the product.
Read: Service Oriented Architecture
With micro frontend in action, you get the ability to make incremental changes to the dependencies, architecture, and user experience. Whenever there is an important change in the main framework, each micro frontend can be upgraded individually instead of upgrading everything at once.
-
Autonomous Teams
An important benefit of micro frontend’s decoupled codebases and release cycles is that we achieve a completely independent team that owns a section of the product where they can make any moderations and updates as required to deliver value to the customers while moving efficiently and faster.
Read: Monolithic vs Microservice Architecture
-
Independent Deployment
As mentioned above, micro frontends are just like microservices, thus, independent deployment of several micro frontends is its key feature. Despite where or how your frontend code is hosted, every micro frontend should have a continuous delivery pipeline where developers can build, test and deploy updates or changes to the application. This reduces the scope and associated risks of any given deployment.
Micro Frontends Architecture Integration Approaches
Integration between the host/container and the Micro-Frontends is the key to Micro-Frontends. There’s a natural architecture that arises across all the approaches. There is a micro frontend for each page in the application, and there is a signal container application that renders common page elements, addresses cross-cutting concerns, and brings many micro frontends together on a page while informing the micro frontend where and when to render itself. So, let’s take a look at different micro frontend architecture integration approaches that can be used by developers.
Read: Using Docker for Microservices
-
Server-Side Composition
Server-side composition caches micro frontends at Content Delivery Networks (CDNs) and composes them in a view that is later served at build time or client runtime. It retrieves the micro frontend, organizes the view and assembles the final page. If the page is highly personalized, there will be various requests from multiple clients, so it becomes important to ensure the server can handle and accommodate scaling.
Read: API vs Web Services
With the server-side approach, you need to delegate caching to the CDN whenever possible to take care of the runtime page composition, generate server-side templates, and integrate web pages with personalised services.
-
Build-time Integration
We sometimes publish each micro frontend as a package and have the container application indulge them all as library dependencies. It generates a deployable JavaScript bundle enabling developers to deduping common dependencies from applications. In this approach, we have to release and re-compile every micro frontend to release a new part of the product.
Read: Pros and Cons of Microservices
But as with microservices, this approach can cause a lockstep release process, hence, this method of integration is not much recommended. As it will be better to find a way for micro frontend integration at run-time instead of build-time.
-
Run-time Integration via JavaScript
The most flexible approach that teams often adopt while using micro frontend is run-time integration via JavaScript. A <script> tag incorporates each micro frontend into the page, and on load reveals a global function as its entrance. After the container application determines which micro frontends should scale, a function is called to notify the micro frontends where and when to render their content.
-
Run-time Integration via iframe
Run-time integration via iframe is among the simplest methods to compose applications together in the browser. Iframes make it easier to build pages from autonomous sub-pages. With iframe, developers also get better isolation in terms of global variables and styling.
Read: Microservices vs Web Services
-
Run-time Integration via Web Components
Another variation to the previously mentioned approaches to run-time integration is web components. In run-time integration via web components, each micro frontend defines an HTML element for the container to represent an instance, rather than defining a global function for the container to call.
Why Micro Frontends?
Micro frontend architecture was introduced to solve different problems faced by developers with the current SPA frontend development. Sometimes programmers have to experience the growth of a web application or website to the limit where it becomes complicated to modify, scale the application or even train new developers to be a part of its development process.
Read: Why Microservices Architecture?
Although we have already discussed the benefits of using micro frontends. There are a few major reasons why you as a developer should be using micro frontend architecture.
-
It allows multiple teams to work independently and contribute to multiple systems.
-
Micro frontend enables every team to have ownership of the components they build.
-
With micro frontend comes reusability through shared component libraries. A component built by one team can be easily used by other teams whenever needed.
-
With smaller micro frontend systems of the application, it becomes easier for new developers to learn and understand the source code.
-
Just like microservices, micro frontend architecture is independent of technology. It allows developers to use different technologies for different components without worrying about their build or deployment.
Read: Benefits of Microservices Architecture
Challenges in Micro Frontend Architecture
Micro frontends can be fantastic, but they aren’t silver bullets. Based on the project, team and business, you might not be able to take full advantage of micro frontend architecture. In some cases, it can undermine the application architecture. So, here is the list of challenges one can face while using micro frontend in action.
Read: SOA vs. Microservices
-
As the entire system gets split into multiple micro frontends and your application loads content dynamically, it becomes complex and difficult to test the entire application.
-
You should only implement the micro frontend architecture if you have large scale projects with more than one frontend team. In the case of smaller teams, the struggle will become insufferable and costlier.
-
Keeping several developers working off the same standard and on the same page can be challenging, thus, it can impact delivering an incredible user experience.
-
Micro frontends are divided into smaller components, so the assembly, deployment, and configuration processes will not only differ but also require extra effort.
Conclusion
Developing an environment where you can easily scale development and empower multiple teams to build, deliver and use tech independently screams success for large scale projects. As we often have to sacrifice one of these due to monolithic architecture, impacting productivity and project delivery. That’s why understanding the right way to build and integrate micro frontends in your application is the key to attaining balance. I hope the information shared in this article seems useful to you. So, before opting for micro frontend architecture for your application make sure you need it otherwise it will become more of a disaster than a blessing to your business.