Overview
Picture this – you’re building a house. Instead of trying to do everything yourself, you get a team of experts: someone for the kitchen, another for the bedrooms, and yet another for the stunning, resort-style pool. Each crafts their space with finesse and, in the end, they all come together perfectly to form your house. This, in a nutshell, is the magic of micro-frontend design.
Just like our house example, today’s web apps are getting bigger and more complex. There’s just too much stuff for one team to handle. That’s where micro-frontends step in. They split up a monolithic frontends app into smaller, manageable and independent pieces, each with their own design, code, and team – it’s like having a bunch of mini-apps, each doing their own thing, but working together to form a cohesive user experience.
This design approach is all about decoupling and autonomy. It’s about scaling development by enabling different teams to work simultaneously on different parts of the app. The name of the game is speed, efficiency, and a smoother workflow.
Now let’s dive into the guiding principles of micro-frontend design: each micro-frontend should be independently deployable, technology agnostic, and fully owned by a team. If that sounds exciting, buckle up, as we’re about to delve deeper into these key principles and explore the benefits and challenges this new frontier of frontend architecture brings.
Design Principles
Micro-frontend architecture it’s more than just slicing your front-end applications into tiny pieces. There’s a whole world to discover beneath the surface.
First up, we’re going to unpack the essential design principles that make this architecture tick. We’ll take a deep dive into each principle, from why micro-frontends need to run as independent features, to the significance of team ownership in shaping our micro-frontend.
Next, we’ll explore the perks of keeping our micro-frontend applications technology neutral as an option
We won’t stop there though. We’ll also review the importance of a user-experience and value-driven approach as key design principles in micro-frontend architecture. Because let’s face it, it’s not just about tech superiority, it’s about delighting the end user and enhancing product quality.
Along these microfrontend articles we mentioned before that micro-frontends are like an extension to the microservices architecture. We’ll break down what that really means and how it influences your overall design.
Autonomous Features
The central idea of this section is to emphasize the importance of autonomy within micro frontends. In a typical web or mobile application, multiple micro frontends coexist and each must function as an autonomous unit. This autonomy means that each micro frontend can be independently altered without affecting other parts of the application.
Each micro frontend is responsible for its own business logic, user interface, and interactions with backend services. Therefore, each unit effectively functions as a self-contained, end-to-end application within the larger application. If one micro frontend encounters an issue, the rest of the application remains functional.
The autonomy of micro frontends allows separate teams within an organization to own, develop, and deploy them independently. This independence extends to the release cycle, with each micro frontend team having the flexibility to deploy enhancements at any time.
Isolation of code is also critical, and strategies should be in place to prevent unintended interference from other micro frontends. For instance, the use of the browser and the DOM as an API can enable communication between micro frontends without coupling them. If two micro frontends become too interdependent, it may indicate that they should be combined into a single micro frontend.
A base application acts as the container for all micro frontends. It handles the parent DOM, shared JavaScript and CSS, routing, and user session management. Despite using the base application for shared dependencies, each micro frontend should still function as an independent feature, akin to an API with its own inputs and outputs.
Micro frontends should communicate independently, mirroring how backend APIs interact in a decoupled manner. Communication between micro frontends can be facilitated using the base application to raise events that other micro frontends can listen to. Additionally, the services supporting each micro frontend can share information, thus promoting decoupled interaction.
In the user experience, changes in one part of the application will propagate throughout the application, but from the user’s perspective, everything functions as a seamless whole. This is achieved by having a mechanism for micro frontends to communicate changes among themselves, whether via DOM-level events or communication between backend microservices.
This principle of decoupled communication is key to ensuring that each micro frontend remains an autonomous feature that can be independently modified and deployed. The subsequent part of the discussion will delve into the importance of team ownership in micro frontends architecture.
TEAM OWNERSHIP
Team ownership plays a vital role in managing micro frontends architecture. As each micro frontend operates as an autonomous feature, it allows teams to have ownership and responsibility over their respective sections. This approach fosters a sense of accountability, encourages efficient development practices, and facilitates quicker, independent deployments.
Micro frontend architecture empowers teams to choose their tech stack based on the specific needs of the micro frontend they’re developing. This approach offers more freedom and fosters innovation as teams aren’t constrained by a single, monolithic tech stack.
In an ideal scenario, team members are cross-functional, capable of contributing to both frontend and backend development, thereby enhancing the efficiency and effectiveness of the project. This approach fosters a team commitment to the functionality of their micro frontend and develops domain expertise over time.
This end-to-end team ownership also simplifies coordination. If a UI change needs backend optimization, the same team can handle it, ensuring a harmonized result. This improved communication and coordination enhance the company’s agility, enabling quicker changes, which ultimately benefits the customer experience.
From a deployment perspective, the decoupled nature of micro frontends allows teams to implement Continuous Integration/Continuous Deployment (CI/CD) independently. This can speed up the deployment process, enable more frequent updates, and reduce the risk of issues that might arise when deploying a monolithic application.
Despite the advantages, it is crucial to maintain consistent user experience across all micro frontends. It’s essential to have a standardized set of UI/UX guidelines to ensure consistency. Additionally, a cohesive design system will keep the visual elements and user interactions consistent across the application.
Moreover, it’s necessary to balance autonomy and consistency when it comes to shared components and services. While isolation is fundamental in a micro frontend structure, some level of sharing is beneficial, especially for common components and utility services. This necessitates well-structured governance over shared resources.
It’s also crucial to remember that while the micro frontends are autonomous, they are still part of the bigger picture, i.e., the overall application. Thus, a shared vision, collaborative planning, and regular inter-team communication are critical to prevent siloed work and ensure the application evolves cohesively.
In conclusion, team ownership in a micro frontends architecture enables autonomy, promotes efficient development practices, and facilitates faster deployments. However, the balance between autonomy and consistency is key, with strategies in place for shared resources, user experience consistency, and regular inter-team communication. In this way, a micro frontends architecture enables both independent development and a cohesive end product.
Value Driven
Another crucial design principle for micro frontends architecture is that each micro frontend should be value-driven. This means each micro frontend should provide a feature that brings value to the end user, offering functional advantages and operating as an end-to-end feature.
If a micro frontend doesn’t contribute visible value to the application or the user experience, it defeats its purpose. For instance, JavaScript code tracking user behavior or counting users in your application does not need to be a separate micro frontend. Functions like these should be part of the base application.
When a micro frontend focuses on delivering customer value, the whole team working on it aligns their efforts towards creating value for the customer. This alignment is in line with Agile principles, ensuring that every change, whether on the frontend or backend, is driven by the goal of delivering value to the user.
Such a focus on value prevents “gold-plating” or adding unnecessary features or complex architecture that doesn’t directly benefit the user. This approach contributes to overall business efficiency because every change enhances the customer experience and avoids unnecessary backend architectural alterations.
From a technical perspective, being value-driven ensures that the micro frontend system is always optimized to provide the most value to the customer, in terms of both backend API performance and data storage performance.
In esence:
- Each micro frontend should be a feature
- Features should bring value to final users
- End to End Value driven means
- Backed APIs are optimized for frontend
- Data Storage is also optimized for frontend
User Experience
User experience (UX) is also a fundamental design principle for micro frontends architecture. The goal is to ensure that while you reap the benefits of splitting a monolithic frontend into smaller micro frontend applications, you do not compromise the user experience.
Micro frontend architecture requires a thoughtful strategy to avoid performance issues that could damage the user experience. Each micro frontend should be performant and load quickly, which can be challenging as the application is composed of multiple independent micro frontends. This can result in more activity within the browser to render the illusion of a single application.
Making smart technology choices can help manage these issues. While developers should have freedom to choose their technologies, you should consider the impact of using too many different heavy frameworks. If every micro frontend downloads a different heavy framework, it could slow loading and performance. Combining heavy frameworks with lighter, faster techniques where suitable can help maintain a responsive UX.
Maintaining a consistent corporate identity is another crucial aspect of UX for micro frontends. Despite developing the UI using multiple micro frontends, your application shouldn’t appear disjointed or inconsistent. This can be achieved by using the base app to centralize styling across all micro frontend applications or implementing strict style guides for each team.
User interaction is another important facet of UX. Users expect a cohesive and responsive UI that provides clear feedback. If a user clicks a “Buy Now” button, they expect immediate feedback, like their cart updating. The application flow shouldn’t feel disjointed or disrupted because it’s built using micro frontends; it should be seamless and smooth, with micro frontends invisible to the user.
Technically, your micro frontend application should function consistently across all browsers and browser versions. In summary, the UX design principle for micro frontends emphasizes that a micro frontend application should be indistinguishable from any other web or mobile application. It should feel consistent, fast, responsive, and seamless.
Tech Agnostic
Technology agnostic implies that each micro frontend should /can be free to utilize the technology best suited to its specific needs, allowing the overall application not to be tied to a specific technology. This flexibility applies to both frontend and backend aspects, as well as storage mechanisms.
Being technology agnostic helps future-proof an application. Instead of investing in one technology—like using Angular for the entire application—and risking it becoming obsolete in a few years, each micro frontend can adopt the technology best fitting its needs. This strategy allows the application to evolve organically with changing technology trends, without needing a full revamp when a particular technology falls out of favor.
For instance, in a shopping website, the adverts micro frontend might require a lighter-weight approach, and a different JavaScript framework might be chosen. If it needs faster storage, a NoSQL database could be selected over a relational database used by other micro frontends. The ability to select the right technology for each problem promotes optimal performance.
However, caution is necessary when introducing micro frontends into legacy applications, as forcing them into a monolithic application not designed with micro frontends in mind could cause more problems than it solves.
Being technology agnostic also has a positive impact on the development team. They are not bound by potentially stagnating technology. With each new micro frontend, they can choose the most relevant and up-to-date technologies, keeping the technology stack—and their careers—current and vibrant.
Despite these benefits, there can be challenges with truly technology agnostic micro frontends, especially with web-based frontend technologies. Global variables declared in one framework might collide with variables in a different framework if both micro frontends live on the same page simultaneously. Version conflicts might occur if two micro frontends use the same framework but different versions. Later in the course, we’ll explore strategies to mitigate these issues by using separate runtimes for each micro frontend.
Sometimes it may seem more convenient to use one framework for the entire application due to these challenges. However, the advantages of adhering to the technology agnostic principle are significant. It ensures the longevity of the application in the rapidly evolving technology landscape by allowing for gradual migration to more modern frameworks as they emerge.
Microservices Driven
Microservice driven design is the final fundamental principle in a micro frontend architecture we are going to review. Each micro frontend should be supported by a corresponding microservices infrastructure in the backend to cater to its functionalities. The micro frontend architecture is, in essence, an extension of the microservices architecture, where the micro frontends act as front-facing components powered by backend microservices.
Micro frontend applications typically interface with these backend microservices through either an API Gateway or a Backend-for-Frontend (BFF) API. These patterns provide a bridge for the micro frontend applications to communicate with the microservices infrastructure, encapsulating the complexity of the backend.
Besides offering backend support for micro frontends, the concepts from microservices architecture can also help define the scope of micro frontend applications. Techniques like the bounded context, a key principle from Domain-Driven Design, can be utilized to outline precisely what functionality a micro frontend includes, thereby preventing scope creep.
By aligning both architectures, we create a system that features modular frontends with a modular backend. This integration facilitates better scalability, maintainability, and flexibility, which are hallmarks of a well-designed system.
Understanding microservices architecture is crucial to the success of a micro frontend architecture due to the interdependence of these architectural styles. Therefore, it’s recommended to delve deeper into the principles and design patterns associated with microservices. You can refer to my Microservices Architecture articles in this blog for a comprehensive understanding
Conclusion
In this article, we’ve delved into the fundamental design principles that underpin an effective micro frontends architecture. We’ve discussed the significance of creating self-contained, autonomous micro frontends that can be independently modified and deployed.
The principle of end-to-end ownership was also highlighted, emphasizing that a team should manage all aspects of a micro frontend—from the frontend component itself to the supporting microservices in the backend.
We further explored the benefits of not confining our micro frontends to a particular technological standard, thereby granting teams the flexibility to select the most fitting technology for the problem they’re addressing.
User experience was underscored as a key aspect of micro frontend architecture. This encompasses not only UI performance but also consistency in UI design. We stressed that the drive behind micro frontends shouldn’t be purely technical but should prioritize delivering value to the customer. This perspective should permeate all aspects of a micro frontend, right from its conceptualization to final implementation.
Finally, we rounded off the module by recognizing the crucial role played by microservices in supporting and enabling micro frontends. Each micro frontend should ideally have corresponding microservices in the background to enhance its functionality.
Moving forward, in the next article, we will employ these design principles to evaluate various methods and technologies that facilitate the implementation of a micro frontends architecture.
That´s all for today, Happy building !