Blog

Microfrontends - Catalyst for Digital Transformation

At smapiot we are always concerned with cutting edge architectures and technologies that can be helpful for projects. A special case are projects in the digital transformation space, where certain criteria need to matched. Especially speed of development and the capability of scaling is important to our customers from that area. Usually, these customers do not have dedicated development teams, but rather hire external service suppliers to develop one or the other functionality.

In environments with distributed teams the classical monolith cannot be sustained. While actually beautiful for many projects, the speed of development especially regarding release cycles is far too slow, when distributed teams are involved. But actually, decentralizing the application brings other challenges. One of the challenges is creating a decentralized frontend.

Challenges of a Decentralized Frontend

A decentralized frontend comes with many benefits. Faster time to market, simplified rollout of new features with respect to personalization, as well as decoupled functionality. However, development of such distributed solutions is usually more cumbersome than a monolith. The architecture and the general solution need to be thought out end-to-end.

One of the major challenges of a decentralized frontend is the user experience. Especially UIs tend to fragment visually with growing size. Decoupling components introduced an easy way for fragmentation to appear. How can this be mitigated?

Another challenge is performance. While inefficient algorithms and unnecessary abstractions can be hidden or at least cascaded in the backend by proper scaling, the frontend will always run on the current client of the user. This could be a phone. This could be a tablet. This could also be a modern PC, of course. A decentralized frontend will more likely be wasteful with respect to performance. How can we ensure that performance is still great?

Last, but not least we need to look into the development cycle. A monolith comes with all patterns and convenience functions defined. While the learning curve for a large codebase may be high, the integrated debugging experience and availability of all source code could make this a breeze. How can we ensure that development of a decentralized frontend is at least as good as the monolith?

Introducing Microfrontends

Around three years ago the idea of microfrontends was born. One of the major issues with the term microfrontends was the classification. What does it actually cover? Are we still splitting UI and API? Are we back at "classic" webservers that perform server-side rendering (SSR)? It turns out there are many variations of microfrontends.

In any case the general idea behind the microfrontend architecture is that the development and deployment of an application part can be done by an isolated team. This enables many team allocation scenarios, incl. real full-stack teams that are capable of shipping a single feature in isolation without any need to align or coordinate with other teams. As these microfrontends should also be independent of each other, the different microfrontends can also be turned on or off per user - tailoring an individual experience from the beginning.

Right now around, six patterns evolved that can be considered for an implementation. While some of these patterns are quite trivial (e.g., just having microsites with links in between), others require the introduction of a new component in the backend (e.g., an intelligent reverse proxy). In any case, there seems to be solution for all the possible problem scenarios when going for microfrontends.

Quite often microfrontends are confused with "using multiple technologies in one application". While such scenarios can occur (e.g., using a legacy web app with another technology as a microfrontend) it should not be the norm. Instead, the same principles as in backend development need to be considered with an even stronger tendency towards simplification and performance. The capability of bringing in existing applications without much change is certainly great for a migration scenario that allows a quicker go to market. This is ideal for portal solutions that occur quite often in the space of digital transformation.

A portal allows end-users to consume a variety of resources and services in a single coherent user interface. While portals could also provide jumping points to other solutions, they should primarily cover all the needs within one UI. Ideally, a portal contains already all services that are likely to be used or needed by customers, however, as long as the portal is capable of being scaled with features, a simpler initial version (like a MVP) can be launched, too.

Our Solution

In the past we developed custom tailored microfrontend solutions for our clients. After implementing the same architecture over and over again, we came to the conclusion that the architecture is not only sound, but that it actually provides development efficiency and introduces a high degree of scalability.

This year we started to develop an open-source solution called Piral. Piral is an implementation of our architecture for modular frontends. We regard this kind of architecture as a pendant to serverless computing, which is why we label it Siteless UIs.

Why are siteless UIs a pendant to serverless computing?

Serverless computing reduces time to market by providing a shared infrastructure that covers scalability and security. In the same way siteless UIs reduce time to market by providing a shared runtime that covers performance and design consistency.

Serverless computing requires a developer-first experience by allowing standard tools (e.g., standard code editors) to be used together with custom tooling for local debugging (e.g., an emulator). Likewise, siteless UIs are created using the same technologies that developers already know - together with an emulator for the application shell itself this provides an outstanding debugging experience.

Serverless computing places all infrastructure needs in the hands of a trusted vendor, essentially requiring no logical backend (or "servers"). In the same fashion siteless UIs require no logical backend (or "sites") for serving the content. The only requirement is a static storage hosted somewhere - which could be a CDN.

Serverless computing reduces the complexity of a whole web service down to individual functions, which are then wired up by a shared routing engine. Siteless UIs do the same - by reducing a whole web app down to individual components, which are then wired up by a shared app shell instance.

In Piral we solved many of these aspects by the introduction of two components.

1. A powerful platform-independent tooling called the Piral CLI. This is the one stop for scaffolding new microfrontends called pilets, but also for building and debugging.
2. A backend component known as the feed service. The feed service knows what pilets are available (to the current user) and returns how to obtain these pilets.

By default, Piral is an approach that makes heavy use of client-side rendering. While SSR is possible, too, the main target applications are highly interactive tools and portals.

While we try to improve the usability of our solution in all areas (e.g., development, documentation, flexibility), we also see that the solution is already good enough to fulfill all requirements already. Right now some companies picked up Piral and went from zero to a fully functioning microfrontend architecture within hours to days.

Conclusion

Microfrontends provide a faster time to market and more efficient development approach when done right. We believe that Piral is a solution that may help, however, depending on the exact needs another pattern may be more adequate. In any case, the tendency to leverage microfrontends for becoming more flexible and create future proof solutions is slowly becoming a hype that will become the norm.

The only question left is: When will you start adopting microfrontends?