Sharing Modules Across Experience Services and Multi-Screen Applications

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
• Reduce 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:

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 design.

This approach solves many of the problems mentioned before:

• Minimizes duplicate design/development/QE effort across teams, which 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 change on 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 effort is much lower compared to the previous coding change model

How does it work in practice in 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

• Web components—traditionally the eBay web app for each hosting page typically is not well aligned, so the developers use different versions of JavaScript libraries and utilities, which makes developing reusable web components difficult. But a solution is on the way with the eBay UI for the web effort in progress. This effort standardizes the web UI components and supported JavaScript library and utilities, which makes shared module web components possible.
• 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

References

• Experience Services — eBay’s Solution to Multi-Screen Application Development
• Don’t Build Pages, Build Modules