Microfrontends: The Benefits of Microservices for Client-Side Development
Good for the goose, good for the gander?
Chief architect Luca Mezzalira is on a quest to bring the idea of microservices to frontend development, after seeing the benefits it brought to the rapidly-growing sports video streaming site DAZN (pronounced “Da-Zone”) where he worked.
The benefits of microservice architecture for developing and maintaining large-scale applications have been embraced by at least a by a percentage of backend developers and architects: Breaking a complex “monolithic” application into smaller components allows development teams to work on different features at their own pace, with their chosen tools. It allows the application itself to be updated and enhanced more frequently. It more naturally fits the DevOps-paced development workflows: Components can grow independently of one another by drawing strong boundaries around them, allowing the platform as a whole to scale without a corresponding logarithmic growth in complexity.
Scalability still tends to be a problem with the front-end community, not only with growing codebase and dependencies, but even how development teams are managed. Yet, it doesn’t have to be this way, Mezzalira argues.
When Mezzalira signed on to DAZN as the company was rapidly growing, he recalled in an interview with The New Stack. He needed a way to onboard new developers (the company now has several hundred) while still innovate and build new services, on top of a growing number of platforms (30 at last count). He liked what he saw from the microservices camp, and figured when it could be applied to client-side design, where each visiting browser could get only the services that it required.
“You can break apart the SPA monolith,” Mezzalira has said. “You can have part of your application written in Vue.js, and part with React and part with Angular. It is totally feasible.”
Domains and Subdomains
Speaking in terms of domain-driven design, Mezzalira defines microfrontends as “the technical representation of a business subdomain.” They provide strong boundaries with clear contracts, and avoid sharing logic or code with other subdomains.
A domain is a problem to be addressed with software. The domain of DAZN, for instance, is to stream sports video. The domain breaks down into multiple subdomains, discovery and playback, customer support, authentication, and so on. A software team can be assigned to each subdomain, creating an organizational structure, one that minimizes cross subdomain communication. Critical decisions are made locally, not globally. Ideally, then, the components should be reflected in the developmental organizational structure of the service itself.
When a browser visits the DAZN site, a runtime is downloaded (nicknamed “Bootstrap”) which starts the application, sets up I/O as well as routing and shared configuration across the sub-domains. Bootstrap collects information about the user’s specific configuration and fetches the appropriate components.
Microfrontends appears to be technology-agnostic, and several different approaches are being taken.
One is to use the basic HTML iFrames element, where each frame its own subdomain. Spotify used this approach for its web-based music streaming services. An event bus coordinates events across different iFrames. In short, the company is using web technologies for the frontend, while the backend logic is written in C++.
Another approach is to use components. Online reservation service OpenTable goes this route, with the OpenComponents stack. Here, a registry houses all the components needed to build the application. “Each team can pick up the registry the components that they want,” he said.
A third approach involves server-side composition, where all the elements for a web application are assembled not by the browser but by the server. Fashion e-commerce site Zalando uses this approach, with the help of Project Mosiac, a framework of services, libraries, and a specification for how components should work together. One component, Tailor creates a tiny runtime layer for each page rendered, assembling each of the HTML fragments needed. Written in Go, Tailor was inspired by Facebook’s BigPipe.
“In this case, we are talking about components that are assembled at runtime on the server,” he said.
One is the issue of payload size. With each component bringing its own technology, invariably there will be a lot of duplication of code, slowing the user experience and potentially creating a dependency hell when components need to be updated, Jackson argued. Responding to the post, one Hacker New commenter elaborated on this view:
Another issue is, like with microservices themselves, one of inherent complexity. “Microfrontends will inevitably lead to having more stuff to manage — more repositories, more tools, more build/deploy pipelines, more servers, more domains, etc.,” Jackson wrote.
Microfrontends will also bring their own set of requirements, Jackson noted. More automation will be needed to provision and manage the infrastructure. Also, it will be up to the chief architect to ensure that “a minimum level of quality, consistency, or governance” will be met by all the frontend projects.
But microfrontends can have unexpected upsides as well, such as… developer happiness. In London, where Mezzalira is based, frontend developers tend to change jobs every year or so, in many cases, they move just to try something new. Microfrontends could provide a way to experiment with new technologies and frameworks without leaving the company.
“Microfrontends provides them with what they are looking for inside the organization,” he said. “It could be a good way to retain people.”