A Primer on Microfrontends

Application development has been centered around monolithic design for a long time, and it’s been successful for a variety of reasons. Monolithic frameworks allow developers to create a consistent experience across an application and enable business leaders to control what kinds of technologies are allowed to operate within their organization’s IT environment. However, as more businesses rely on sophisticated application designs and technologies, it’s created a need for some organizations to break up the application development process into a combination of sub applications / services that work together to create the larger piece of software. Most have heard about microservices in recent years – an architectural concept in which a collection of back end services (generally APIs and databases) are developed independently, albeit loosely connected, to represent distinct business functionality. On the frontend side of development, this process is referred to as microfrontends.

Microfrontends can seem like a good idea generally because it makes it easy to service individual pieces of an application without needing to take its entirety offline, but assuming that microfrontends should be applied to all situations can lead to serious issues in your IT department down the line.

Here’s what you need to know if you’re thinking about implementing a microfrontends strategy:

What Are Microfrontends?

A microfrontend framework in frontend development is like microservices on the back end: you’re essentially developing code for individual components of your application as if each were a separate application.

For example, some large ecommerce companies might have an entire team dedicated to maintaining the cart section of their application, and an entirely different team (perhaps in another part of the world) to manage the latest deals of the day. Organizing their teams in this way allows each component of the site to rely on different technology and hyper focuses the support team on maximizing the performance of a single piece of functionality without needing in-depth knowledge about the pieces that other teams are working on.

When Should a Business Use Microfrontends?

When comparing the value of microfrontends to their potential costs, it’s important to note that the positives are sometimes also the negatives of this kind of framework.

Microfrontends are useful when dealing with a large, complex application architecture that relies on many moving parts to work. Breaking up the functions into distinct pieces allows an organization to distribute responsibility across a network of teams, often across the globe. This allows a business to take advantage of a diverse set of skills and compartmentalize maintenance so no one issue can bring down the entire application. Further, compartmentalization of responsibilities enables organizations to expedite deployment of new features and servicing of old ones because teams don’t have to necessarily wait for features to be completed before working on their own.

This type of architecture also allows an overall solution to be made up of various technologies with no need to be consistent in development language, technology stack, or technology version. Though many IT managers would consider such a “wild west” approach to maintaining IT assets as pure chaos, the concept is that technologies and developmental practices change so frequently, it may be better to not deal with upgrading / rewriting an entire monolithic solution, and instead work with maintaining and updating a particular microfrontend codeset only when a change / update is required.

However, the decentralized nature of microfrontend development can be the very reason why it may not be the best option for an organization’s application project.

The Downside of Microfrontends

Applications using microfrontends can be good if the application is complicated, but it also means leaders will need to account for more technical debt than they might otherwise contend with. A microfrontend framework ties together the many different “applications” that make up the components of the overarching application, and that frequently means that each relies on a different technology stack than other pieces. When this is the case, businesses need to find ways of securing each individual piece against a cyberattack or other threats. In a monolithic framework, this is relatively easy because teams will need to know the best practices for securing a React, Angular, plain JS, Vue, or other framework only, whereas microfrontends can require the team to know how to secure all of those frameworks to keep their environment secure.

Additionally, microfrontend architecture’s ability to disperse component development across teams means that organizations will have to deal with varying degrees of skill in executing on a project. In a monolithic framework, business leaders are able to set the standards for code quality, technology used, and more, but once governance is decentralized, it’s hard to mandate any of that. A consequence of this inability to govern means that an application could function, but every team may not be using the best practices for achieving the end-user functionality being aimed for.

Microfrontends in DevOps

In an organization managing their software development efforts according to DevOps principles, speed is a key benefit business leaders would see, and microfrontends lend themselves well to this model. By breaking up frontend development into small, manageable components, organizations are able to streamline their development efforts by narrowing the focus of teams to a few key functions and technologies. The obvious benefit to such a system is that each team can be really good at handling a few key functions within the overarching framework of the application, without being burdened with understanding the entire architecture, data interaction, and security / entitlements mechanisms.

However, as noted before, this is only beneficial if the organization has the resources (including DevOps automation) to coordinate a large group of teams for a complex application project. Microfrontends may lend themselves well to DevOps practices, but that doesn’t mean they’re the best approach for an organization in the small to medium size.

So…Should I Pursue Microfrontends for My Project?

If your organization has the resources necessary to employ and coordinate so each can work on a single piece of a complex application, then microfrontends may be a good consideration for adoption. However, if the application isn’t complicated or your organization lacks resources necessary to field several teams and skillsets of developers, then there isn’t much lost in sticking with a traditional monolithic framework. It fundamentally comes down to what the goal / vision is for the project and the organization’s IT department, and what resources are available to achieve it.

If you’re interested in finding out more about microfrontends or have questions about application development, visit the contact us page to get in touch.