Every day, thousands of suppliers use Partner Home, the enterprise platform where companies who conduct business with Wayfair can manage their listings, pricing, and operations. We’re constantly looking for ways to improve their experience, encouraging existing suppliers to expand their catalogs and showing new suppliers that it’s in their best interest to sell with Wayfair.
There are many complex content verticals in the Partner Home space, ranging from transportation to media management. With separate teams working in each vertical, how can we make sure that the variance and complexities of Partner Home don’t reflect in our end-user experience?
In this two-part series, we’ll be explaining how we’ve addressed this problem, making the user journey on Partner Home more consistent by introducing micro frontends and rethinking how we distribute applications.
How Did We Get Here?
Providing uniform and quality user interfaces is a difficult task in a corporation the size of Wayfair. In the early days of the company, all of our code was in a monolith. This organizational model was effective at ensuring consistency across our websites but as we began to scale, the coupling prevented us from moving quickly and allowed failures in a single area to have outsized impact on our codebase.
Several years ago, the decoupling effort began; separating applications and allowing them to move at their own pace but also causing the previous level of consistency to waver. Teams had to balance rapid feature iteration with the new need to keep their shared patterns up to date. The role of platform teams became dominated by outreach and feature teams began to solve shared problems on their own in order to preserve autonomy, further propagating inconsistencies in the platform.
The Problems With Visual Consistency and Distribution
The move towards decoupling our frontend applications has allowed us to operate at scale and build a more resilient platform overall. However, it has required teams to think more carefully about the interaction between elements on their page, particularly if some of these elements are being heavily utilized across the website. If we distribute elements as static libraries it also requires teams to keep their dependencies up-to-date. If teams don’t immediately update and redeploy their applications when visual changes are released in shared pattern libraries, the new visual features won’t be distributed holistically across Partner Home pages.
For example, if we decide to make the global navigation a new color, every team needs to update their version of the navigation, else it would be different colors visually as a user navigates between applications such as Catalog Manager and Pricing Home. Some tools like Dependabot try to alert teams when their libraries are out of date but do not eliminate the need for manual maintenance. The inescapable truth is that decoupled teams own their dependencies and will always be involved to some extent with the versioning of their shared libraries.
Platform engineers who want to distribute shared components have the time-intensive task of convincing teams to update their package versions. Since this maintenance has undesirable effects on velocity and consistency, wouldn’t it be nice to keep a scalable decoupled model while ensuring that highly integrated components get updated automatically across the platform?
Micro Frontends: Is the Timing Right?
One solution to the distribution problem is using micro frontends. The general idea is that applications can live inside other applications: they have an independent deployment pipeline and operate semi-autonomously but still appear to users like an integrated part of the page they are looking at. Instead of being a static instance, micro frontends are dynamic, living applications.
Micro frontends in various forms have been around for a while now, ranging from server-side template composition to IFrames. Why is now the time to bring them into our tech stack for Partner Home? Like any architecture, micro frontends introduce organizational tradeoffs. When it comes to risks, broken code can reach production faster than ever before and a higher level of thought is required in designing component integrations. Additionally, micro frontends can be technically complex, particularly if they require a significant reworking of the core architecture.
Wayfair is a significantly more mature tech company now than it was 5 years ago — most current teams utilize rigorous automated test coverage, effective CI/CD pipeline checks before deployment, and state-of-the-art monitoring and alerting to capture failures in production.
A rise in technical expertise and a significantly increased focus on domain services within Partner Home also positions us with the ability to dedicate the required effort to building scalable and functional shared solution interfaces.
So is there a technical artifact that would mitigate the risk of an architecture overhaul?
Module Federation to the Rescue
Enter module federation, a cutting-edge technology offered by Webpack in their version 5 release. Module federation introduces the capabilities to turn chunks of any application into a micro frontend with just a few lines in a configuration file. Conveniently, you can do this in the same Webpack build that is the backbone of all new decoupled frontend applications at Wayfair. It also plays nicely with React, the frontend framework used for the majority of pages in Partner Home.
With module federation, applications highlight chunks of their code to be exposed publicly for other applications to consume. When the exposed chunk is updated, all applications that are using it start referencing the new version. Module federation allows us to gradually transition into micro frontend architecture without overhauling our existing tech stack.
The result? Highly utilized components where consistency is paramount can be maintained and iterated upon with their updates distributed automatically to any host applications in the domain.
The Evolution of the New Distribution Model
Our team maintains the Partner Home Frontend Platform and we innovate upon and distribute numerous components for which the shift to micro frontends could reap serious benefits.
In addition to addressing the low-hanging fruit, what if we look beyond the use of this new technical artifact and begin to explore how it could impact our distribution model for solutions to shared concerns? Instead of building static components, tossing them up, and having applications utilize what they wish, we can apply the principles of live application development and maintenance to these components, making them dynamic, living entities.
In other words, we could use micro frontends as a stepping stone to revolutionize the way Partner Home applications interact.
The New Frontier
We started the journey by thinking of shared entities in a new way, going back to the basics, and focusing first on our customers, the suppliers that use the Partner Home platform. In their day-to-day, suppliers deal with several core concepts that appear in multiple places as they navigate the Partner Home tool suite.
For example, “a product” representing a physical item in the supplier's catalog, may show up on a pricing page, an inventory page, and a schema tag editing page. Today, a product, despite being a bounded context in the supplier’s mind, is represented with a slightly different UX on each page. Sometimes it even pulls from different data sources. What if we reimagined “a product” as one of the shared components in our libraries and then evolved it to use the new application approach? It seemed like a perfect pilot to prove out a brave new paradigm in Partner Home.
At the end of March, we gathered a group of engineers, product managers, and designers from across the Partner Home space for a two-day workshop to explain the project and understand what we’d need to prove that this idea could be successful.
We used the expertise of product managers in the catalog space to understand what information is most critical to suppliers, we worked with UX designers to imagine where this application could live visually on our website, and we collaborated with a cohort of senior engineers to understand the technical requirements of the initiative. With a plan in place, we got to work.
In April, we finalized our designs and collaborated with the Frontend Platform team to release a version of our shared frontend configuration library which allows applications to upgrade to Webpack 5. In May, we built our first micro frontends with module federation. We configured the technology to our needs and implemented our designs of a sleek and subtle frame application within a product overview list.
Finally, in early June, we successfully launched the “Supplier Product Object” application into our first production use case, the Catalog Manager. It shows that this isn’t just a pipedream and can fundamentally change how we build a supplier-centric experience.
A special thanks to the core engineering team that helped make this effort happen—Mario Fernandez, Veronica Machado, Ben Barnett, and Diego Fiore. You’ll hear more details about how we executed on the ideas mentioned in this article in part two of this series, written by Mario Fernandez. Stay tuned!
Want to work at Wayfair? Head over to our
Careers page to see our open roles. Be sure to follow us on
Twitter,
Instagram,
Facebook and
LinkedIn to get a look at life at Wayfair and see what it’s like to be part of our growing team.