The adaptation of microservice architecture has been on the rise over the last few years. Building microservices to control different business domains becomes a norm for server-side/backend development. Client-side frontend development is still driven mainly by monolithic applications.
While most applications benefit from a single, coherent codebase when it comes to the client-side, using a monolithic architecture starts showing its pitfalls when dealing with multiple deployments of the same codebase with some delta per deployment. Developing for these multiple deployments and adding that delta is not a difficult task. However, maintaining it release-by-release or incremental addition of new features becomes a serious pain point.
At WealthDesk, our backend follows a highly decoupled architecture running on top AWS services that form AWS Serverless. However, our front ends had been monolithic applications making it difficult to maintain and ship new software with an ever-expanding list of new broker-partners, SEBI Registered Advisers & Analysts, and distributors. Typically, these partners were provided with their microsite. What followed was varying customisations ranging from partner-specific integrations to brand identity changes to make a partner’s brand stand out.
While looking for a solution to this problem, our front end team came across micro frontends. In a nutshell, micro frontends are the front end counterparts to the backend side microservices architecture. Here is more from the source – Micro frontends | Technology Radar | Thoughtworks
In microservices, we split the business domains on the server-side into small but cohesive pieces. In micro frontends, we take a similar approach in front end development with additional consideration of the user journeys.
Deconstructing a monolithic frontend into micro frontends
When we decided to rewrite our frontend application as a micro frontend, we had more than 20 revenue-driving partners using the platform. More partners were coming on board every day. These partners and the customer behaviour on their microsites helped us get crucial insights into how the platform is used by the customers and the major touchpoints in the user journey. Based on these insights and how the user interfaces already consume the microservices, the connecting dots fell into place for our micro frontends. We arrived at a division or micro-applications that look very similar to the ones below.
This micro-app handles the onboarding of the user through various workflows. The experience might vary based on the type of partner, i.e. broker, SEBI Registered Professional or distributor.
Through this micro-app, users can browse through WealthBaskets and WealthBasket Managers. Here, we have different variants of the discovery components which partners can pick and choose from. This essentially helps build a product catalogue for the partners and end customers.
Users can go through the details of the WealthBasket and look at the various metrics, understand pricing, go through the SEBI professional’s disclosures, terms and conditions, etc. This micro-app helps build a landing page for SEBI Registered Professionals along with different data points that they share with the WealthDesk platform.
KYC & Agreements
As WealthDesk operates in a highly regulated space, the platform has to provide tools for compliance and provenance. This micro-app has different workflows and tools to obtain KYC for a user as well as generate and execute agreements between SEBI Registered Professionals and end customers.
WealthDesk helps brokers, SEBI Registered Professionals, distributors to distribute WealthBaskets and end customers pay the subscription fees for the same. These subscription fees can be paid through different modes of payments such as regular bank payments/UPI payments, setting up auto-debit, from the broker ledger, etc. This micro-app helps partners set up their choice of payment modes and methods and controls the payment journey in a compliant manner.
WealthDesk provides an aggregate view of the portfolio for the end customers. It allows customers to add a lump sum, set up SIP, rebalance the WealthBaskets, partially or fully withdraw and retry failed orders for their WealthBasket portfolios. The motivation behind abstracting this micro-app is to build a clear boundary between the rest of the components and order management.
Carrying out a risk assessment for an end customer is a mandatory activity from the compliance point of view and for the WealthBasket Managers to better assist the customers. We decided to create a micro-app for this. It ensures that if there are any changes to be made to adhere to compliance, we don’t disrupt the rest of the user journey.
Embedded WealthDesk Gateway (EWG)
EWG is perhaps our most complex and most interesting micro frontend. It is a plug and play widget made to authenticate and authorise users, setting up their sessions, allowing them to place orders and look at the order status. This is a very generic use case that can be used anywhere. The micro-app is carved out separately.
Over time, EWG has evolved from the WealthDesk platform using it for our internal WealthBasket use cases to partners using the authentication and order placement capabilities using the gateway in the most creative ways possible. We now have a wide range of use cases, from news apps placing “Trade Now” buttons on their news articles about a particular company to flexible execution channels for analytics companies that do not want to reinvent the execution wheel.
How it all comes together
Breaking frontend applications into these many applications may look like overkill, but based on inputs from Customer Success and Business Development teams, each one of these applications houses partner-specific integrations. Even though we want to standardise the software running across different partner microsites, we want to provide the flexibility for partners to pick and choose from different frontend components to make their microsite suitable for their own customer base.
We started building on top of webpack 5 right from the beginning. Thus, we were able to take advantage of the module federation plugin, which seamlessly connects the micro frontends. More on this here Module Federation | webpack. With these considerations, we chose React to build the frontend applications. For compiling and building the applications, we decided to build our own toolchain using webpack.
Our micro apps can now run independently and serve their purpose. However, it needs to be presented as a single unit from an end-user perspective. To achieve that, these micro frontends are connected to another application called container. This container is responsible for holding deployment-specific configurations and connecting these micro frontends to provide a cohesive user experience. The container application is where partner-specific integrations and customisations are maintained and passed to the individual micro frontends.
We covered decent ground in the past few months as a foundation to build and maintain multiple use cases. We are now working on building a solid regression test suite, thus building a robust automated test suite on such a distributed architecture. Technically, adding a regression suite or a CI/CD is not a part of micro frontend architecture. But, having those pieces running on top of distributed micro frontends helps realise the full potential of micro frontends at a scale with multiple partners, use cases and all future enhancements. Another goal followed by the regression suite is to bring meaningful automation in CI/CD. We have set up CI/CD pipelines. But, we are coming across opportunities to optimise it further with every release.
Summing it up
A micro frontend is a design principle, and there’s no opinionated way of building it. There are micro frontend “frameworks” out there. But, they come up with their own baggage. From the get-go, we wanted to keep the overall architecture and choices of the technologies very flexible. As mentioned before, there’s no single way to do it right. We know that the setup and architecture that we started building will evolve and optimise over time.
We are already working on some exciting use cases such as stock contextualisation and portfolio optimiser. Like the others from our micro apps catalogue, these are going to be the plug and play artefacts. As we evolve and learn new ways to add value to partners and customers, we will keep adding these micro apps, making it easier to unlock the massive value WealthDesk platform can bring.