On a recent episode of The InfoQ Podcast, Section VP of Technology Wesley Reisz chatted with Luca Mezzalira, VP of Architecture for DAZN, to discuss how their team has approached micro frontend development. This interview really brought into focus the parallels between the progression of micro frontend development and the evolution of edge compute.
Building on the concept of microservices, the micro frontend movement has gained a lot of momentum in recent years. As organizations like Spotify, Upwork, and HelloFresh have harnessed this popular frontend design pattern, we’re seeing growth in adoption rates within the wider technology community, particularly among organizations with larger teams and code bases. By migrating away from monolithic structures, larger teams are able to iterate more quickly without stepping on each other, ultimately resulting in higher velocity.
What is a micro frontend architecture?
A micro frontend architecture is an approach to building an application modeled after some of the benefits found in microservices. Many organizations have adopted microservices to avoid the limitations of large, monolithic backends and to enable teams to scale the delivery of independently deployed and maintained services (each with potentially their own velocity, release pipeline, and technology).
Today, microservices is a well known style of building server-side software; however, many companies continue to struggle with monolithic frontend codebases, which can offset the benefits that microservices offer.
Furthermore, for web applications, the frontend is continually increasing in importance. Weld (a web app/creation tool), for instance, is 90% frontend code with an extremely light backend. Its CEO, Tom Söderlund, says having a monolithic approach to a large frontend app becomes unwieldy.
Good frontend development is not easy. Scaling frontend development to allow multiple teams to work simultaneously on the same large and complex product is even more difficult. Micro frontends have recently emerged as a way to emulate the success of microservices, splitting frontend monoliths into a set of loosely coupled applications which can act independently. These applications can then be assembled together to create a single, user-facing application.
What are the benefits of micro frontends?
There are various benefits that can accompany micro frontends, including:
- Breaking frontend monoliths into multiple smaller pieces can reduce coupling of frontend components and improve overall management of the system;
- Smaller codebases are typically simpler and easier for developers to work with, avoiding the complexity that can develop from unintentional and inappropriate coupling between components that shouldn’t know about one another;
- A micro frontend architecture can enable decoupled teams to develop frontend code autonomously, increasing their efficiency and effectiveness;
- Independent deployability of micro frontends reduces the scope of a set deployment and accordingly, associated risk;
- Technology choices, codebases, teams, and release processes should be able to operate independently of one another and evolve under their own steam instead of requiring excessive coordination;
- Upgrades, updates, or even rewriting parts of the frontend, including architecture, dependencies, and user experience, can be achieved incrementally and performed when it makes sense instead of having to stop everything and upgrade all at once.
A word of caution
Micro frontends, much like the microservices on the backend that they’re modeled after, suffer from some of the same challenges. While the use of micro frontends come with the benefits described above, they can also increase the complexity and coordination requirements of your app. Just as you should be using microservices to solve a specific problem (such as enabling independent velocity of different backend teams), implementing micro frontends should also be leveraged to solve a specific problem they’re designed to address. The phrase “use the right tool for the job” is particularly important in microservices and micro frontends.
A real world micro frontend example
To break micro frontend architecture down further, it’s helpful to relate these concepts to a real world example. This article from Cam Jackson describes a practical micro frontend example – a website on which customers order takeout. There are multiple pages: a home page where customers can browse and search for restaurants; a page for each restaurant with a menu, discounts and special requests; and a profile page for customers that lets them see their order history, track delivery time, and select their payment options.
Each page is complex enough to justify a separate team for each one, and each of those teams should be able to work on their page independently of the others. They want to be capable of developing, testing, deploying, and maintaining code without having to be concerned about conflicts or coordination with the other teams. The customer experience, however, should be of one single, seamless website.
There is typically a micro frontend for each page in the application, and there is a single container application, which takes care of common page elements and cross-cutting concerns. The container application also brings the different micro frontends together onto the page and tells each one when and where to render itself. The container application and the micro frontends integrate together using JavaScript. You can see the end result deployed live at https://demo.microfrontends.com, and the full source code can be seen on Github.
Micro frontends at the Edge
When components are decoupled, it makes them easier to move around independently and you can, therefore, more easily act on optimization decisions.
Edge computing promises better user experiences by processing workloads in closer proximity to end users. However, not every workload in an application is an ideal fit for the Edge. For example, complex processing that is not latency sensitive, such as long-term analytics and modeling, is typically more suitable to run in centralized infrastructure (i.e. cloud, data center). In micro frontend architectures, developers have more flexibility to make determinations around where workloads are most suitable to run.
Case Study: Deploying a Nuxt app at the Edge
Adore Beauty, Australia’s longest running online beauty store, started to work with the Section platform several years ago to optimize performance and reliability during the busy holiday sales season. Following impressive sales lift results using simple site acceleration techniques and queueing, the tech team at Adore Beauty began to work with Section on running their Nuxt application at the Edge, closer to their end users.
With Magento at its core, the Adore Beauty application is broken into various microservices that allow them to decouple functionality between frontend display, product information, shopping cart functions, etc. As such, they have the flexibility to move components independently to optimize application performance, security, and scalability.
As a result of leveraging Section’s completely containerized Node JS module, the Adore Beauty technical team could focus on writing code that optimizes the user experience instead of worrying about the complexities associated with hosting, deploying, and scaling. “It means our team can stay lean and focused,” says Gareth Williams, CTO, Adore Beauty. “We can add value to the customer by pulling together all of our microservices and relying on Section to do the scaling.”
Getting the Nuxt app deployed as close to the end user as possible allowed the Adore Beauty team to benefit from increased speed with lower redundancy, and gain access to Section’s engineering expertise. Going forwards, Adore Beauty want to migrate as many of its microservices as possible over to Section for hosting and scaling.
Edge compute platforms, like Section, abstract the backend complexities of managing deployment of these components along the edge continuum. The benefits are similar to those gained by a micro frontends approach: increased flexibility, scalability, and greater autonomy for your team.
