Microservices at eBay, Part 2: Sharing Modules Across Experience Services and Multi-Screen Applications
In this past, a developer shares how his team is using microservices to increase efficiency, reduce the amount of code required, and more.
Join the DZone community and get the full member experience.Join For Free
By now, most eBay core business flows have gone through the journey of implementing Experience Service-based multi-screen application solutions, where web and mobile native app user interfaces are composed of one or more modules, and Experience Services directly returns these modules to clients with content synthesized from backend data sources, localized and formatted, and ready for rendering and user interaction. This article outlines a plan to move more modules to a shared environment.
This architecture offers benefits for each each business flow or domain by providing:
- Consistent user experience across web and mobile native apps.
- Faster time-to-market for releasing business features across devices.
- Reduction in duplicate engineering work across devices.
During this journey, we have found that there are many modules that can or should be reused/shared across UIs of many business flows, including:
- Marketing modules
- Merchandising modules
- First-party and third-party advertising modules
- Product reviews modules
- Browse/search guidance
- Best selling/top-rated products module
- Deals modules
- Search result module
- Search refinement module
- Category navigation module
Here are some examples how these modules (in red boxes) are reused across several hosting pages:
View Item page
But many pages hosting these modules have their own Experience Services directly integrating with those shared domain services (e.g. Merchandising) and producing their own flavor of module response schema (e.g. Homepage vs. Search vs. Product vs. ViewItem). The native and web apps teams then have to repeatedly develop components for each flavor of the logically equivalent module. The following diagram illustrates this situation.
The different shades of each color in the diagram represents different flavors of each component:
- Red represents Merchandising.
- Blue represents Advertising implementation.
- Yellow represents Finder implementation.
- Green represents Product Review implementation.
As you can see, there are several problems:
- Duplicate design/development/QE effort across many teams.
- Different flavor implementations give inconsistent user experiences to end users.
- When a new functionality needs to be introduced to a module, the developers need to negotiate with many teams to implement it. And those implementations usually roll out to production at different times due to priority setting/resource planning in each team, which slows down business and further fractures the user experience.
What Is the Solution?
Instead of duplicating the effort across many teams, owners of the shared domain (e.g. Merchandising) should collaborate with other teams of hosting pages to:
- Have product management standardize the user experience of the modules across all hosting pages. If the business needs a few different variants of the module design across different hosting pages (Homepage vs. Search vs. Product vs. ViewItem), then we should standardize a set of variants and let the hosting page choose which variant best suits them and avoid creating one-off flavor splinters again.
- Standardize the module response schema for these agreed-upon module designs.
- Develop one Module Provider service for these agreed-upon module designs to be invoked by all hosting page Experience Services.
- Allow different hosting pages' Experience Services call these module providers and pass through their response to clients. Integration of these modules to different pages are significantly simplified.
- Develop one set of web components for these modules with standardized schema and reuse them across all web applications.
- Develop one set of Mobile Native components per stack (iOS vs. Android) for these modules with standardized schema and reuse them across all native apps.
The following diagram illustrates such a design.
This approach solves many of the problems mentioned before:
- Minimizes duplicate design/development/QE effort across teams. This also translates to:
- More engineering resources becoming available for other development.
- Faster time-to-market for integrating these modules.
- Creates consistent user experiences across business flows/pages (Homepage vs. Search vs. Product vs. ViewItem), in addition to consistency across devices (web and mobile native apps).
- Speeds up delivery of business change:
- Most minor changes (changing the verbiage and image content) do not even need any changes to the Module Provider interface, therefore there is no change needed to the hosting page, Experience Services, and web/mobile apps.
- Most algorithm/data source changes are managed by the Module Provider internally, and there is no change to the Module Provider interface, the hosting page Experience Services, or web/mobile apps.
- If there is a change to interface, changes will be localized to:
- The module provider interface.
- The shared web components to work with new response schema.
- The shared mobile native components to work with new response schema.
- The hosting page Experience Service interface, which is updated by up-revving the module’s Maven JAR dependency version and recompiling it, so integration efforts are much lower compared to the previous coding change model.
How Works in Practice at eBay
The Module Provider integration approach has been warmly embraced by many domains in eBay, including Merchandising, Advertising, Marketing, Vertical Finders, and Product Reviews. This approach has resolved a long-standing integration challenge they faced with each hosting page. In the past, they had to work in the hosting page code base to orchestrate integration with their domain, which usually created a fractured functionality and user experience due to constraints in that environment, resourcing, and planning. It has also been embraced by the mobile native app community, which saves large amounts of duplicated development by adopting reusable components built to support the standardized module response.
There are some eBay specific challenges we are working through, including:
- Product management alignment—traditionally eBay product management for each page is more siloed and not thinking about reusable modules across pages. With the adoption of Experience Services, where a module is now a first-class citizen, product management is changing its thinking and practice to adopt shared modules that are not tethered to any particular page and that can be reused across pages.
Overall, with problems getting gradually resolved, more and more shared module provider-based solutions are created and used across eBay to provide:
- Consistent user experiences across domains and devices.
- Faster time-to-market for adding/changing business features.
- More efficient use of engineering resources.
Published at DZone with permission of Chuck Zheng. See the original article here.
Opinions expressed by DZone contributors are their own.