Marketplace/Mobile Optimized Websites/engineering

The Marketplace has been placed into maintenance mode. It is no longer under active development. You can read complete details here.

The Marketplace was built with a single database table holding all our apps. The easiest way to add another type would be to add a column called `type` or add another table and change our code logic to look at both. Past experience (AMO) shows that this can lead to unnecessary complexity around queries and templates, especially when the data hops through several hoops (like Elastic Search) to get to where it is going.

We emphasize the Marketplace being 100% API based on the front-end -- this proposal brings those same benefits to the backend as well.

In this proposal there is no UI for managing the websites stored in AWS. It will all be done via APIs. This scales well with the phased rollout/review plan since APIs will mean minimal implementation time.

Open Questions

• If we add ratings/reviews where do we store those?
  • [andym] Ratings and reviews are essentially rating things on the web, basically a URL. Stand up a ratings service that matches a URL to a Firefox Account user. Depends upon the exact functionality though.
• If we add owners or a management UI, where does it live?
  • [andym] A client side app using the API? Authentication through Firefox Accounts using OAuth. I think an interesting question is how do you determine ownership for a URL?

Revision/Decision

For Phase 0 (at least), we decided to use Elastic Search as the abstraction layer. While this does not accommodate disparate data sources, it avoids performance overhead in combining and sorting data in Elastic Search. The performance testing of this idea shows minimal performance degradation.