Introduction
Achieving a highly optimised frontend development is by no means an easy task. The process can become even more complex when scaling up frontend development to multiple teams that have to work in tandem on large and intricate products or systems. This can be an especially common scenario for many online operators that use a checkout service, a basket service, an ERP service, or some (or all) of these at once.
There has been a recent and emerging trend of breaking up these frontend monoliths into smaller and more manageable pieces, which are referred to as microservices. Such an approach to frontend architecture has exploded in popularity given its effectiveness and efficiency for teams that work exclusively on frontend code.
There is ample information about the application of microservices for server-side software, but many companies are still not clear about how this can also be applied to monolithic frontend codebases.
This article will cover the main benefits of distributed micro-frontend architecture, some key considerations to keep in mind when implementing such a system, and also a review of how MeDirect has implemented such a system with success.
Shifting Micro Services to the Frontend
Micro-frontend is a relatively recent term in the field of development architecture, first gaining prominence in late 2016 after microservices gained a sharp increase in popularity. As the name implies, it focuses on extending microservices to frontend codebases. There has been a longstanding practice to build complex monolith structures that sit on top of a microservice architecture. This is most notable when considering single page applications such as those commonly seen in feature-heavy browser applications.
These frontend monoliths grow in capacity over time, and since these are developed by a separate team, become very difficult to upgrade and manage over time. In order to circumvent this issue, micro frontends have been tailored to rethink the way in which websites and digital services are designed – as opposed to having a bulky frontend, a website or application should be designed as a composition of different features that are owned by independent teams.
This gives each team a distinctive approach and specific goals, allowing them to focus on the feature and specialise in it. This also allows each feature to be developed end-to-end, from database to user interface, giving the team a cross-functional approach.
Refining an existing concept
As with most concepts, micro-frontend is not an entirely new concept but can trace its roots to the Self-contained Systems (SCS) concept. This type of architecture has a clear focus on the segregation of functionality into many independent systems, creating an ecosystem that is logical and also in alliance with many smaller software systems.
SCS was a pioneering approach towards avoiding large monoliths that grow consistently but eventually become impossible to maintain. In fact, SCSs have been successfully employed for several mid-sized and large-scale projects, as breaking a large system into more manageable self-contained systems is more feasible.
The use of microservices for frontends has also been referred to as Frontend Integration for Verticalised Systems. The ‘Vertical’ in this type of architecture refers to a different ‘feature’ on a website or application, such as ‘Order’, ‘Search’, ‘Product’, ‘Cart’, and so on. Each vertical will have its own presentation layer, persistence layer, and separate database, which means that each component is developed and implemented by a single team with no code being shared between different systems.
Why should you invest in Micro-Frontend Architecture?
Micro-frontend is an easier term to explain as opposed to frontend integration for verticalised systems. But linguistic differences aside, there are some key benefits as to why you should consider investing in this type of architecture.
Progressive upgrades to your system
Irrespective of their size and complexity, frontends require constant monitoring and maintenance. Most businesses fail to understand that websites and applications should be treated as dynamic tools rather than static ones. Large frontend monoliths can become held back by past tech stack, or by code delivered by previous employees or service providers. In some cases, most businesses are tempted to simply rewrite the entire thing from scratch just to avoid going through the entire bulky frontend.
It is far easier to decipher your system piece by piece, allowing your business to continue delivering new and existing features to your customers without compromise. In addition, by applying microservices to the frontend, your organisation can use different frameworks and still retain part of the legacy system without being weighed down by the monolith.
This also has many benefits from a human resources perspective – it is much easier to upgrade a system in parts as opposed to undertaking an entire development of a whole system. This speeds up the development cycle as different teams tackle different components of the system. In reality, once a team dips their toes into the experience of micro-frontend architecture, it will incentivise other teams to jump on board.
Easier decoupling of components
When considering a large frontend monolith, its large source code should be the first thing that comes to mind. In micro-frontend architecture, every component has its own individual source code, which is simpler and easier for teams to work with. This means that there is less chance of any unintentional or inappropriate coupling between different components that should not be related to each other.
As such, it can be easier to decouple components in micro-frontends since the segregation is more apparent, reducing the chance for any accidental coupling. This can allow developers to work efficiently and at the right confidence level, as it will be easier for them to process a single scope operation rather than a huge process.
Despite this, it is tempting to assume that micro-frontends can be used in lieu of clean code – this should not be the case! It is imperative that the source code is of superior quality, no matter its size. The issue here is that it makes far more sense to create an environment where easy and correct decisions are made, rather than bad decisions that can have significant repercussions.
Autonomous deployment
When speaking of microservices in general, autonomous deployment is imperative, as it significantly reduces any risks involved. As such, the same concept can be applied for frontends – each component should have its own continuous delivery pipeline that builds, tests, and deploys it all the way to production.
The key here is that each component can be deployed safely without having to consider the delivery pipelines or codes of other frontends. When a team approves that a micro-frontend can go to production, they should not have to be weighed down by lateral teams or those working on the old monolith. Rather, they should be able to decide since they built the frontend and will maintain it.
Overall, autonomous deployment improves time to market for new features and for upgrading existing ones, and MeDirect is a keen proponent of speed to market.
Multiple teams working independently
As already indicated above, micro-frontends are managed by multiple teams that work independently of each other. Some monolith systems can be huge and will require a considerable amount of information and resources to manage.
With micro-frontend architecture, human resources do not need to be intimately acquainted with the entire complex system, but rather develop their own expertise on a specific component without upsetting the whole ecosystem. Teams should be set up vertically along with aspects of business functionality, rather than grouped on their individual technical skills.
It can be very motivating for a team of developers to get a feature all the way to production with little changes to the legacy system. It is also very convenient for different teams to be able to make key decisions on individual components of a system and to make upgrades to its architecture, dependency, and user experience. Such an approach can also open your organisation to experiment with new technologies and features, without having to stop everything as a result of a large monolith.
Some key considerations
Every form of development architecture does come with its own set of drawbacks, and micro-frontend does present some key considerations for adoptees.
Operational Complexity
A complex website or application will still remain complex irrespective of whether a large frontend monolith or micro-frontends are employed. In general, a well functioning frontend ecosystem has become very complex given the modern requirements businesses and organisations have – most of these no longer use static files but complex build systems with large frameworks.
As such, the orchestrating of all the micro-frontends together can become a cumbersome process since all of these components depend on each other. This is not to say that there is coding dependency between the frontends, but rather a coordination between these components and the tools that are needed to stitch them together.
The benefits of micro-frontends have been outlined in detail above, but there is a veritable trade-off from the simplicity of a single monolith frontend to the complexity of an overall modular system. Developers may come across quite a bit of common challenges, such as tracking and debugging problems, dealing with versioning across the system, and needing to have multiple teams on board to have their applications running in development to test a complete user experience.
Limited Performance
Splitting teams on the basis of their vertical components is a positive approach to more efficient human resources. And yet, it is important to consider that different teams employ different decision-making processes. This can lead to situations where browsers might end up downloading multiple frameworks, and where code may be duplicated.
Communication between the different teams is imperative in this regard – change to one frontend may end up breaking features in other frontends if teams operate in complete isolation.
Incoherent UX
Issues of user experience have already been hinted at above, as most developers tend to forget that website or application users do not experience a frontend or component in isolation, but rather as a complete package. This is one of the most common arguments against micro-frontends, as different scoping styles for every component worked upon by separate teams can lead to an incoherent UX.
Additionally, it should be noted that frontend users tend to pick up on a lot of accessibility issues that are often overlooked by backend developers. This can be very common when implementing some micro-frontends, such as when embedding inline frames.
MeDirect Implementation
Micro-frontend architecture can indeed be a powerful approach for your business or organisation. At MeDirect, we adopt a scope-based ecosystem to our implementation.
- Instead of using a large system that integrates all the possible features required in banking into one monolith, MeDirect has built a sophisticated set of base components with shared schemes that have a common source code. This can be used for both web and native applications, together with separate components and libraries that handle the different microservices.
- Secondly, MeDirect defines and builds micro-frontends around its business scopes. This allows for better separation of concerns and avoids vendor lock-ins. The overall benefit of this clear definition is a smaller scope for each microservice, and faster time to delivery.
- One of the key frameworks that MeDirect has been using is Luigi, which was employed ever since it was in beta version 0.6. Luigi provides a top bar and left side menu bar, a dashboard micro-frontend, and a transfers micro-frontend.
Luigi is an open-source micro-frontend framework that is backed by SAP, a highly reputed company that has invested considerable resources into this library framework. Luigi makes it possible to allow for a seamless transition from a large frontend monolith to a micro-frontend architecture. This framework allows developers and administrators to build overarching business user applications and reuse the functions and views of the applications currently installed.
Furthermore, Luigi also allows businesses to take third-party modules or entire applications and integrate them directly into their websites or applications. In fact, MeDirect has already committed its own code to Luigi, as the firm strongly believes in this framework.
Luigi has been a great choice for MeDirect as it supports an independent distributed UI team to develop, deploy, maintain, and operate modules and end-to-end features. It handles both authentication and micro-frontends, making it extremely lightweight and agile, but still very robust. In fact, MeDirect is also using Luigi internally by way of a set of tools that are provided to our employees for onboarding processes, loan handling, account management and more.
Commenting on our collaboration with SAP in the Luigi project, Product Owner Philipp Pracht said,
“The collaboration with the MeDirect Team when applying Luigi to their product was an excellent example of how Open Source is done right, for the benefit of everyone. They were highly engaged from the beginning, gave very valuable feedback and even contributed various parts to Luigi, from small enhancements to key features.”
Final Thoughts
With every form of architecture, there are a number of trade-offs to consider before adopting one framework over another. Overall, there are many benefits that can be attributed to micro-fronted architecture.
Time to Market – since the scope of each component is contained, the development lifecycle is quicker, which makes more business sense.
Centralised Gateway – even though components are developed, deployed and maintained vertically, there is clear communication between and to microservices in an authenticated and secure manner
Autonomous teams – different teams can focus on different microservices from end-to-end, but can still retain a cross-functional approach.
Granular Health Checks – every individual microservice in the architecture will present issues that are easier to identify, debug, and fix.
Business capability oriented – microservices can be built around business scopes, so there the development team can always deliver to business requirements.
Scalability – the framework is scalable horizontally based on load.
The choice of whether your business should micro-frontend or not depends entirely on its situation. A small team working together on a simple product might prefer an old bulky frontend end. But a business with multiple distributed teams and with a large and complicated product might see the benefits of micro-frontends as outweighing the drawbacks.
At MeDirect, we firmly believe that micro-frontend architecture has been an important upgrade to our systems, with Luigi proving to be a reliable and flexible framework that continues to allow us to serve our clients with efficiency and confidence.
A little about Luigi
Luigi is an Enterprise-Ready Micro Frontend Framework, designed purposely to transform digital products from a monolith to a micro-service and micro-frontend architecture, exactly as described above. Backed by SAP, Luigi is ready to use out of the box, and comes loaded with features for UI, security, notifications, forms, and multi-lingual support. More about Luigi - https://luigi-project.io
A little about us…
