Delivering faster with better use of micro-frontends in financial services

Micro-frontends are hot and happening, so many companies want to move to micro-frontends now. However, they are doing it wrong! In short, micro-frontends are similar to micro-services: the monolithic code base is split up in smaller pieces, so it can be delivered independently.

Despite the fancy name, as we often see in tech, the use is not optimal – for example, by mixing up multiple frontend frameworks on the same page. But is it desirable to combine multiple tools, languages, or frameworks? It might be technically possible to have multiple frameworks such as Angular, React, or Vue on the same page, but it’s far from advisable to do this. It will affect performance and you will end up making a lot of code just to make it possible.

Single Page Application 2.0

So how will you get the benefits of micro-frontend architecture so your DevOps teams can deliver independently and not get into undesirable situations? And how do you make sure your app does not lose performance or that you don’t have multiple frameworks existing in a single page application (SPA)?

The answer is to change your DevOps team’s responsibilities. Instead of it becoming the owner of a certain topic and having to knock on every door to implement a piece of the puzzle, you should make the team the owner of a complete small app that exists in the larger architecture. What works well is multiple SPAs owned by specific DevOps teams that can decide what happens inside these SPAs – with, of course, the enterprise overseeing the overall view. This way, SPAs 2.0 are created.

You will still have all the benefits of DevOps teams deploying independently. Additionally, the developers have the freedom to choose the right tool for the job. Practically, this also means that the time to deliver improves. So actually, it’s a win-win situation!

How to move into this new direction?

The approach has already been tried at some of our financial services clients, showing the challenges of moving in this direction. The biggest challenge is the fact that not only the application code has to be changed, but also organizational change is needed. In addition, it is also to keep in mind that giving developers more freedom might lead to a reduction of consistency of your app. Luckily, there are several solutions, such as creating style guides, design systems, or static code analysis tooling.

If you are ready to start, it is important to map and break-up your app in small, micro-frontend eligible pieces. Try to find the pieces that can be properly separated from the rest as a single application. The granularity that fits your app can be quite difficult to find as there are many factors that influence your process, including team composition, the products you sell, etc.

Freedom and agility to deliver faster

As we see it, micro-frontends are the best choice for larger-scale applications. However, the way micro-frontend architecture is created needs to change. It should be done by properly splitting up your monolithic codebase and making sure the enterprise oversees all the small apps to keep the consistency in place. With the right mindset, tools, and people, a large organization can still be in control while giving developers the freedom and agility they need to deliver features even faster.

Sven van Straalen – Software engineer and community lead

Vincent Fokke – CTO FS Netherlands and Belgium