At Meesho, the mantra "User First" serves as the compass by which we navigate the process of building our mobile and web applications. What goes into making an app is spelt out in detail in its architecture, which includes design and development patterns and techniques — it provides a road map and prescribed practices to follow throughout development.
In light of this, our primary goal as software architects is to create a solid codebase architecture around which to construct our apps and website. We define what constitutes acceptable quality and verify that the code meets these standards by analysing it for performance, resilience, reuse, readability, scalability, security and technological limits, among other features.
As a front-end engineer at Meesho, I have a first-person perspective of the rationale behind the implementation of the new architecture for our mobile and web applications that we have deployed this year. In this blog, I will be speaking at length about this.
Functionality of a traditional single-page application
Meesho's initial phase of development was marked by the usage of a single-page application (SPA) architecture, and we've used this for almost seven years, up until this year. Single-page apps are well encapsulated by their own name. In these apps, a user's request will cause only the relevant data to be refreshed rather than the full page. Now, let's get into the nitty-gritty of the technological side of things. There are two main components of traditional single-page applications:
- The website's index.html
- The whole JavaScript bundle
The main JavaScript bundle file is embedded with an src tag in the index.html file. Further dissection into vendor portions and the application bundle is possible (which majorly serves as an optimisation). Although, the notion of a single application with a single package remains essentially the same.
Among the many benefits of SPAs are their responsiveness and speed, offline support and caching, higher performance and continuous UX, customization, flexibility, etc. Decoupling of the front end from the backend is another important aspect of SPAs. That's why it's not necessary to redeploy the entire structure just because you tweaked the front end.
It's perfect in every way, yet it just wasn't enough at the time
Initially, one of our core apps was designed with two distinct repositories:
- The oldest web repository: this was majorly the legacy codebase, which was serving very few features (orders and payments majorly).
- The V2 repository: this was a webpack-based SPA, which made use of external libraries that were imported in the package JSON.
The two repositories were used to serve the application as a whole, and the files were routed on a load balancer level.
In order to keep up with the expanding needs of our app, we've established a number of internal departments (such as those responsible for supplier support, payments, advertisements, user acquisition/activation, and expansion). This allowed us to accomplish more in a shorter time frame, which was great, but it also caused a number of complications:
- Differences in components and the hassle of constantly rewriting and duplicating components
- Blocking team: even though various teams worked on somewhat distinct parts of the app if one team's update broke something, everyone's development would be interrupted
- When our seller hub expanded at such a massive rate, the application grew tremendously in size and complexity, with the concern that it would eventually become a monolith
- This affected developer efficiency since it took longer for the monolith to build, lint, and run all the test cases
At this point, we realised that the existing architecture couldn’t accommodate such rapid expansion. Preserving our mantra "Problem-First Mindset", we investigated potential alternatives while maintaining a clear picture of our expectations for the new architecture, such as giving each team its own fully-functional, live repository and empowering engineers with the freedom to choose whatever micro applications to construct and operate locally to speed up their development.
Good news: we figured it out!
Cometh micro-frontend
After extensive research, we concluded that switching to a micro-frontend architecture would not only solve all of our problems but also materialise all of our future aspirations. As defined by Toptal, “Micro-frontend architecture is a design approach in which a front-end app is decomposed into individual, semi-independent ‘micro apps’ working loosely together.”
It's perfect. “Bzzzzzzzzz…Clap!”
Once we decided on micro-frontend architecture, we spent the better part of a month building it.
We exclusively utilize micro-frontend architecture for our seller-facing web app, and sellers may also access it via webviews in the Meesho app. We have more than six lakh merchants on our platform, and earlier this year, we rolled out the micro-frontend architecture to all of them. Many of the significant changes we made over this time are outlined here:
- To accommodate the new micro-frontend architecture, we built a container application that can serve as a host for other micro-frontends, including payouts, services, fulfilment, growth etc.
- It is now possible for each micro application to have its own unique build and deployment procedure, as well as a set of linting rules. However, they all can be constructed using several SPA frameworks
- Each micro application connects with the container via a remote file that is specified in the config of the host (container) application
- All the micro applications can share the same libraries, eliminating the need to re-download everything
In the initial stages of this project, we chose webpack as the module bundler. It’s a module bundler for JavaScript applications, but it does a lot more than that. It assesses each package and generates a dependency graph consisting of various modules your web app needs to operate effectively. In response to this graph, it generates a new bundle with exactly the right amount of files, sometimes just one .js file that can be simply plugged into an HTML document and used for the application.
Module federation
It is one of webpack's various micro-frontend implementation strategies. It enables us to split our application into a succession of smaller applications that can be independently created, deployed and then reassembled into a single application. It was introduced in webpack 5.
Take it easy, it's already a success
Yes, we can now confidently state that it served its intended purpose. Since the advent of micro-frontends, many significant issues have been resolved like:
- Less inter-team dependency and increased ownership of the features owned
- Improved the speed of front-end builds by over 50%
- Autonomy in structuring a team's own codebase
- Independent and improved on-call scheduling process
Moreover, this architecture holds tremendous potential and will be integral to many of our future initiatives. This also gives us the flexibility to experiment with other tech stacks without mandating that everyone make the switch at once. Future enhancements, such as the introduction of plugins for communication between different micro-frontends, are already planned.
Come back to this space to learn more about our progress with micro-frontend architecture.
If you are interested in working with a daring and growth-obsessed tech team, join us.
CREDITS -
Editor - Rochak Singh
Creatives: Rahul Prakash (LinkedIn, Portfolio)
