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.
But for whatever reason, the microservices religion has not seen many converts among frontend web and mobile developers — those who wrestle with providing a smooth and dynamic user experience using Vue, React, Angular or any one of other JavaScript frameworks, often using Single-Page Application (SPA) principles.
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.
Today the DAZN site operates as a set of SPAs, with each SPA owned by a different development team. The SPA could be rendered browser-wise, or, Mezzalira prefers, by the server. Server-side, JavaScript is compiled during the continuous integration phase, and loaded into an Amazon S3 storage bucket. Lambda@Edge does the microrouting for each page. This approach allows for candidate test releases, where, for instance, German Internet Explorer users, getting one configuration, while everyone else gets another.
“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 OpenTablegoes 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.
A number of microfrontend JavaScript frameworks are also available to support the idea of microfrontends, including Single-SPA, which ties together different SPAs with a tiny app runtime. Frint is another package that offers this approach.
Microfrontends do come with a number of potential downsides, as ThoughtWorks consultant Cam Jackson described in an explanatory post on Martin Fowler’s site.
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:
Its already hard enough to optimize a large JavaScript SPA so that it runs well on mobile devices — are we really suggesting that its a good idea to ship a UI to users device containing N different versions of React, Angular, Redux etc. all built using different build tools/pipelines with the final UI cobbled together and have it give a comparable experience to a native application? Microservices work on the backend because it’s effectively hidden from the user — their device hits and endpoint and gets a response. On the frontend it is a different story, the user’s device has to download and execute all that duplicated code.
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.”
Source: https://thenewstack.io/microfrontends-the-benefits-of-microservices-for-client-side-development/