Recently, microservices have emerged as a promising solution for the inefficiencies and limitations of working with large, monolithic backends. Doing so allows the scope for greater autonomy, testability, and scalability.
Despite a tremendous leap in progress in server-side backend development, the inability to simplify frontend codebase remains to be a significant pain point for the software industry. Even Single Page Applications (SPA), which promise better performance and conversion, are built on traditional, monolithic frontend architecture.
Consequently, their deployment, upscaling, and maintenance are difficult. Even the slightest change needs thorough testing, or worst, re-coding. Furthermore, this increases the risks of making errors and misutilization of resources.
Micro Frontends can help the software industry overcome these issues. However, there exists much prejudice and misinformation regarding this approach, stunting the implementation of this promising solution.
This blog gives an overview of micro frontends, covering pertinent questions such as what they are and how they might help. Also, we would explore some of the common ways of micro frontend development.
What is Micro Frontend?
As a microservice-oriented approach to frontend development, this is an architectural style in which independently deployable (and maintainable) frontends constitute the application. That is, the method breaks down monolithic frontends into fragments, each of which can be developed, deployed, and tested independently. The end-user, however, interacts with the application as a single entity.
With more accessible codebases, scaling such applications is easy. Moreover, a part of the application, i.e., a micro frontend can be completely re-written without affecting the remaining parts at all.
The Benefits of Micro Frontends
An exploration of their major benefits is imperative for a better understanding of this frontend architecture.
Often, organizations working with monolithic frontends deal with a back-dated technology stacks, inefficient and irrelevant codes, and more. They tend to encounter situations in which a total rewrite seems inevitable.
Micro frontends implementation offers a smoother way of upgrading, which rules out complete re-coding. While one part of the application upgrades, the other parts function unhindered. This facilitates decision-making as teams can now focus on the issues more precisely.
Mistakenly or unnecessarily coupled codes are a common issue with monoliths, and they pose related problems that hinder the overall functioning of apps and user experience. As individual micro frontends involve much smaller codes than the monolith, they are simpler and easier to work with.
These applications have tightly bound contexts, ruling out the interactions between parts that are supposed to work in isolation from one another. Micro frontends make it more difficult to continue undesirable coding habits while making the desirable ones imperative. For instance, this method demands extreme focus on aspects such as the system’s event flow.
Every micro frontend involves an autonomous system, with a dedicated production and deployment pipeline, and involves testing as well. Most importantly, this method functions completely independent of the overall system state, the nature of the existing monolith, as well as the states of peer teams.
From the organization’s perspective, this translates to more autonomous teams that are agile, flexible, and ultimately more efficient within their limited scope. With vertical teams that cover all the aspects of end-to-end frontend development (styling, form, and validation), each team is fully responsible for its section of the overall application.
Single SPA Micro Frontend
However, irrespective of the language used, the micro frontends architecture usually comprises the individual micro frontends and a container application binding them together into a single UI.
The container is responsible for the rendering of common elements (headers, footers, etc.) and navigation.
Furthermore, it also delivers the relevant micro frontend upon the users’ request.
Micro Frontends Implementation
Alongside the variety in development methods, there are several possible approaches to micro frontend implementation and integration. This section discusses some of the major ones.
This method employs multiple templates to render the HTML code on the server. Here, an index.html contains the common elements and performs a server-side integration of specific aspects contained in fragmented HTML files.
Moreover, this method emulates the micro frontend quite closely as each piece of the split-up code contains its own domain concept and can be deployed by an individual team. Similarly, updating one page doesn’t affect others.
However, despite enabling the de-duplication of common dependencies, this method is highly problematic. Just like monoliths, changes to any part require that every other part is re-compiled and released again.
In fact, the deployment process of such applications, i.e., re-introducing undesirable coupling at the release stage, ultimately negates the very purpose and essence of using a micro frontend architecture.
Integrating micro frontends at run-time may well be considered the best way. In itself, this method may be divided into, at least, three sub-methods.
Using iFrames – iFrames enable browsers to build composite applications using multiple sub-pages. It is the simplest micro frontend integration method. Yet, it offers much scope for isolation as styles and global variables don’t interact. The method is somewhat similar to ‘server-side integration’ (discussed above).