In the world of desktop interoperability, the value of an individual application is in the functionality it contributes to the overall business workflow. It’s not the application itself,
but the interactions between them that eliminate rote tasks, allow for creative problem solving, and empower users to focus on creating new value. In this paper, we discuss how micro frontends (with the coordination of microservices on the back end) are the future of desktop interoperability.

Just as we have benefitted from a microservice architecture approach that breaks backend services into discrete functions, we can leverage “micro frontends” to compose flexible business workflows.

The current trap of monolithic frontends.

Over the past decade, we’ve successfully made the move from monolith to microservices on the back end, but the same has not been true for the frontend. Our user interfaces are still monolithic.


Take a look at the above sample application.

  • It’s stuck in a single browser tab, locked in a single window.
  • It can only display one chart.
  • It has five different grids and blotters, but users can’t move any of them.
  • Two hamburger menus is too many.
  • It’s drowning in side panels.
  • Users can’t customize which set of components is in use at once.

Single page applications (SPAs) have pushed beyond the boundaries of what the web browser was designed for, delivering complex, feature-rich applications that tie visual components into rigid, monolithic solutions. This is where micro frontends come to play. How can we break these components out into standalone modules that can be reused by different teams across the enterprise, and reassembled into custom workflows?

How do we decompose our SPA into micro frontends?

Single Page App to Micro Frontend

How do we decompose our SPA into micro frontends?

The example above combines a number of different elements: a chart from a vendor like ChartIQ, several instances of grids from open-source libraries, and a native custom built WPF control, all configured at runtime. The modular architecture separates visual components from workflow business logic that is unique to this application. Development teams can focus on the novel solution that needs to be written from scratch and benefit from a library of reusable micro components to build the UI.

The dilemma is, if we decompose this to reap the benefits of loosely coupled, reusable components, we have to start bringing the pieces back together. To achieve this, we need a container that can load and configure both web and native components, manage interop, and provide software teams a way to create and manage custom business logic. More on that later.

Discovering benefits—and challenges—of microservices.

Fifteen years ago, applications were typically built as monolithic client side software managing business logic and connecting directly to a database. Web platforms like Rails and Django introduced self-contained web applications, automated code generation and ease of deployment, at the expense of tight coupling and a tendency to grow sprawling and complex. Most of these solutions were isolated silos, with little in the way of shared code or functionality, often integrated with an Enterprise Service Bus to provide for quick data sharing.

As services became more granular and atomic in their design, the microservice architecture was born, with the benefit of smaller code bases, loosely coupled software, and autonomous development teams. However, challenges quickly emerged around deploying, scaling, and integrating a hive of independently running services deployed across clusters of servers.

Distributed systems are complex, requiring comprehensive end to end testing and involved deployment processes that span disparate services and multiple teams. Service versioning and discovery is critically important, and in the days before Docker and Kubernetes, managing deployment environments and server infrastructure was a massive challenge.

Even in a microservice environment, user applications tend to be monolithic, with tight coupling to service interfaces and complex aggregation code to manage asynchronous connections. Dedicated aggregation layers can solve for some of the complexity, allowing client code to focus on core business logic, and providing a degree of usability.

A monolithic frontend creates a ripple effect towards backend micro services.

We often work with partners who struggle to realize key benefits of microservices, even with a level of abstraction in an aggregation layer. Changes to frontend applications require a ripple of changes to the aggregation layer and some number of microservices, along with the associated testing and deployment costs. Coordinating across standalone microservices to deliver business functionality to end users essentially becomes another incarnation of a monolith. Even though microservices function as discrete standalone applications, they are tightly integrated at the client, and the promised advantages of independent development, deployment, and management of those microservices is never achieved.

The solution is to break the frontend apart to mirror backend architecture and reduce coupling and coordination of service calls in client applications.

For microservice architecture to truly succeed, it must be paired with micro frontends.

Pairing discrete, atomic units of micro frontend functionality with analogous microservices on the back end immediately delivers on much of the promise of microservice architecture. See diagram below. You can keep legacy applications that users depend on while simultaneously rolling out new frontends on the desktop.

Benefits include:

  • Independent, autonomous development teams and release cadences.
  • Flexible testing and deployment of discrete pieces of functionality.
  • Seamless integration regardless of technology or underlying infrastructure.

Rolling out new independent frontend components while maintaining legacy tech.

The final piece needed is a way to tie together individual microservice-connected UI elements to create complete solutions. Just as backend services need a framework to coordinate interoperability and discoverability, micro frontends need integration to deliver fully realized business workflows. To bring all the pieces together, you need an orchestration layer.

An architecture layer for micro frontends.

Just as we use orchestration tools for microservices, a smart desktop platform like Finsemble allows you to do exactly the same with micro frontends. Finsemble provides robust discovery and integration of native and web based applications. It’s an entirely new way to think about frontends and desktop strategy.

The real game changer is when you go beyond connecting micro frontends to the backend microservices—and when you start connecting micro frontend pieces to each other. The result? Incredibly powerful workflows.

Micro Frontends in Finsemble

We believe there are four very minimum required capabilities to implement in order to recompose applications built in micro frontend architecture.


Finsemble provides a simple framework, allowing micro frontends to be composed into reusable applications, which can themselves be assembled into custom workspaces across multiple monitors and displays.

Interop and Workflows

Components and applications deployed in Finsemble can communicate through abstractions to share data and interoperate, regardless of what technology they use, be it native or web. Integration is seamless and non-intrusive.

Shared Services

Finsemble manages a shared services layer to proxy microservices locally that deliver common functions used across the spectrum of application components, including: authentication and authorization, notifications, and logging.

Shared Enterprise Connectors

Finsemble coordinates core infrastructure concerns like data persistence, network synchronization and connection pooling through a shared managed services layer. Components leverage these and other infrastructure functions through Finsemble’s abstractions, enjoying security and efficiency, agnostic of the underlying complexity and implementation details of these systems. Component and workflow authors focus on core business challenges, and Finsemble handles the rest, saving teams time and money, while empowering them to deliver value to users more quickly.

I’m not building applications anymore, I’m building workflows.

This results in a new way to think about applications. When we say “applications of the future” we are talking about a shift in a way of thinking. With Finsemble, software teams can focus on core business logic, creating novel solutions by building workflows out of reusable micro frontends. Legacy applications gain new utility when combined with web components that extend their original design goals. The result is a dramatic shift in frontend application strategy and desktop development approach. It’s not about building applications anymore, it’s about building workflows.

In Conclusion

Micro frontends can transform the way that we build applications, but orchestration, security, and infrastructure functions remain real challenges. A robust integration framework should handle these concerns and more, providing a non-intrusive path to integrate existing applications with new native and web components. Finsemble empowers developers to quickly deliver purpose built end user experiences as flexible, custom workflows.

Learn more about Finsemble, the smart desktop and integration framework

Micro Frontends and the Future of Applications whitepaper cover

Download full PDF version now.

Share “Micro Frontends and the Future of Applications” with your team. Save to your desktop.

Download Whitepaper
Micro Frontends and the Smart Desktop webinar

Finsemble + Adaptive Webinar

Micro-frontends: the future of web applications for the smart desktop. In this webinar, Adaptive joins us to explore the benefits of micro-frontends for both development organizations and users.

Watch webinar here