We embarked on an exploratory journey to map the progress of micro-frontends so far. We delved into the labyrinth of challenges that teams grapple with the stubborn anti-patterns that inevitably weave a web of coupling, and the recurring solutions that often break this weave. Our exploration unveiled the potent capability of micro frontends in empowering teams to independently contribute to mid-to-large scale applications, thereby fostering an iterative evolution of our applications and effectively shrinking the impact zone of potential issues.
But it was not enough to only look back and bask in our accomplishments. The quest demanded a gaze into the future, a leap into the possibilities yet to unfold. We identified the missing fragments in this intricate jigsaw of architecture and envision what could elevate this approach to new heights of innovation.
Design exploration of micro frontends
A critical question that plagues the world of micro-frontend architecture is defining the “micro” in micro-frontend. This question reverberates through many organizations, and in reality, the answer is far from singular. It’s crucial to comprehend the context, the organizational structure, its size, and the dynamic flow of communication within the team.
Our interactions with various teams sculpting distributed architectures revealed a common scenario: ‘distributed components’ often overshadow the presence of a micro-frontend implementation.
The domain knowledge was often splattered across the container and the ‘micro-frontend,’ causing confusion about the true boundaries of the micro-frontend architecture and its implementation.
To mature in this field, it’s imperative to cultivate a deep understanding of the application we’re developing.
Remember, it’s essential to reassess our initial assumptions regularly to ensure they are still aligned with our end goals. The connection between organization structure and software architecture is critical and should be considered in our design decisions.
Enhanced communication
With multiple micro frontends cohabitating in the same view, communication among them is inevitable. We propose a publish-subscribe pattern for micro-frontends to communicate, thus enforcing the boundaries between them and reducing design-time coupling, which ultimately leads to more autonomous teams.
Implementing this technically could involve multiple options such as Custom Events, an event emitter library, or reactive streams. With micro-frontends forming a distributed architecture, a more formal API or events management system is critical to streamline team interactions.
Simplifying the developer’s experience with large applications that heavily use loosely coupled communications strategies is a future challenge we look forward to tackling.
Server-side rendering (SSR)
SSR architectures have been a hotspot for innovation in recent months, with significant advancements like Next.js or React 18 server components.
However, for SSR micro-frontend applications, several aspects need deeper exploration. These include the need for micro-frontends discovery, reference architectures on the cloud, leveraging the serverless paradigm, and a framework-agnostic React server components approach.
Each opportunity offers exciting potential, with my attention gravitating towards developing a reference architecture and investigating the use of serverless paradigms with micro frontends.
The power of partial hydration
Performance is a cornerstone of every frontend application, including micro-frontends. The concept of “islands architecture” has introduced the possibility of improving performance by leveraging partial hydration, a technique that should gain more popularity in optimizing SSR micro-frontend applications.
Micro frontends at the edge typically recall the Edge-side Includes (ESI) markup language. However, edge computing, particularly technologies like AWS Lambda at the edge or Cloudflare workers, have the potential to greatly improve latency and scalability. Nevertheless, edge computing isn’t a panacea; it requires careful consideration and application.
Deployment
In the realm of microservices, practices such as feature flags, blue-green deployment, and canary releases have been instrumental in mitigating the risks associated with deploying new microservices versions. Similar strategies should be adopted for client-side rendering micro frontend applications as well.
Routing
Linked closely to deployment strategy, client-side rendering micro-frontend applications currently lack a robust routing strategy. Innovative approaches are needed that take into account new versions, different environments, and even user roles.
The ecosystem of micro-frontends is vast and unchartered in many ways. However, the strides we’ve made over recent years have been substantial. For us, the opportunities to mold a nascent architecture, gaining traction across global enterprises, are exhilarating.
As the rapid adoption of this architecture continues, we are hopeful that it will yield new insights and further refine our understanding of distributed UIs architectures.
