| title | seoTitle | seoDescription | datePublished | cuid | slug | cover | tags |
|---|---|---|---|---|---|---|---|
A Case Study Interview into Micro-Frontends: Building Design System for E-commerce Platform |
Case Study Interview for Microfrontends: E-commerce Design System |
Micro frontend architecture is an approach to building web applications by splitting the user interface into smaller, independent, and reusable parts. Each |
Thu Mar 30 2023 11:17:07 GMT+0000 (Coordinated Universal Time) |
clfv0twho000909jw1lyuegjj |
a-case-study-interview-into-micro-frontends-building-design-system-for-e-commerce-platform |
interview, ecommerce, @platform, design-systems, microfrontend |
In a previous article Micro-Frontend - What & Why?, we took a look into what is Micro-Frontend architecture, as well as some core concepts behind it. For some of you that have missed the memo, here’s a tl;dr:
Micro frontend architecture is an approach to building web applications by splitting the user interface into smaller, independent, and reusable parts. Each part is owned and developed by a separate team, and they are brought together in the browser to create a single, seamless user experience.
In this article, we'll dive deeper into the practice of applying micro frontend architecture at Swift - an e-commerce company and long-term partner of Dwarves Foundation. We'll take a closer look at one specific use case - development & integration of a shared design system - and explore some of the challenges and outcomes of using micro frontend architecture.
For privacy’s sake, we will refer to our client company as “Swift”. The information discussed here is from a real interview based on real-world events.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1680174820301/586eb6f9-c7fb-4cf1-92a8-330224cad3ec.png align="center")
At Swift, we wanted to make our development process more efficient, and we found that breaking down large projects into smaller chunks was the way to go.
This led us to micro-frontend architecture, where we split the project into smaller chunks so that each team could be in charge of a chunk. This made development, testing, and delivery much easier.
The projects at Swift are split vertically by page and sub-domain. We have at least ten apps in total, each assigned to a specific team. A sample breakdown of our current system would include:
-
Authentication (Login)
-
Profile Dashboard
-
Ads Management Dashboard
-
Chat
-
Design System
… and so on.
This approach has allowed us to have a more focused development process, which has ultimately led to better results.
We realized that having a UI library that all our apps could use would reduce code duplication and make the development process smoother. To achieve this, we opted for a stack of React, Storybook, and pure CSS that gets bundled together with the component.
One of the significant challenges we faced was following the design with sufficient leeway for all possible variants and customizations. We also encountered technical issues, ensuring the components can integrate nicely into multiple different apps and environments. Last but not least, we had to focus on building good documentation that allowed for fast and accurate collaboration.
The process of consuming this app is relatively straightforward. We build and publish the package to npm, and consumers install it and import the components they need to use.
We have started applying this design system to our existing apps, such as Ads Management Dashboard, and we are expecting to integrate it further into other projects in the near future.
Since this is a UI-focused package, we believe it is unlikely that the apps will face difficulty upgrading to the newest version.
Initially, we recommend implementing the UI independently in each app, and only after everything is stable should we gather the components that can be shared. By this point, the cost of upgrading the package for all apps should be relatively low because the risk is also low - considering that we have ensured all the components are working in a stable way.
Our expectation was to build an internal design system that all our apps could share, and we have achieved our goal. We have released the first version of the package, which can be applied to some of our production apps.
In conclusion, at Swift, we have found that micro-frontend architecture and a shared design system have been beneficial to our development process. While we encountered some challenges along the way, we believe that the benefits have been worth it, and we are now reaping the rewards of a more efficient and streamlined development process.
In this case study, we explored how the Micro-Frontend architecture was applied across Swift’s e-commerce platform - how the system looks, and how it makes integrating a new app much more efficient. Vertically splitting the apps by sub-domains is an effective approach to Swift’s use cases - and it looks like they will keep going strong with this.
Alas, Swift is not the only one among our partners that are utilizing a Micro-Frontend architecture, and we are reaching out to others for even more insights. Stay tuned for more!
At Dwarves, we encourage our people to read, write, share what we learn with others, and contributing to the Brainery is an important part of our learning culture. For visitors, you are welcome to read them, contribute to them, and suggest additions. We maintain a monthly pool of $1500 to reward contributors who support our journey of lifelong growth in knowledge and network.
-
Check out our products
-
Hire us to build your software
-
Join us, we are also hiring
-
Visit our Discord Learning Site
-
Visit our GitHub