I see six realistic options:
#1 The API is a separate Django project running in a 3rd-party PAAS under a
separate domain name, such as api.compat.mozilla.org
#2 The API is a separate Django project running in a new Mozilla virtual
server, and appears under developer.mozilla.org
by reverse proxy
#3 The API is a separate Django project running in MDN infrastructure, and
appears under developer.mozilla.org
by reverse proxy (similar to
#4 The API is included as a Django app in the Kuma project
#5 The API is part of the Kuma project
#6 There is no API (additional kuma models, updated when the wiki changes,
with enhanced KumaScirpt).
#1 is definitely my preferred solution. It's simpler for me to develop,
and will maximize the chances that non-Mozillians will use the API and
contribute data and code. I agree with what others have said about the
The first technical challenge to is easing authentication between kuma and
the new service. If we're going to allow data contributions from outside
MDN, then the API will need some user authentication flow, including login
pages, auth tokens, and click-through CC0 license agreements. However, the
first use case is data contributions from an MDN page. This can range from
no user interaction (requiring an auth handoff between kuma and the API,
and kuma to grow auth provider features) to just re-authenticating the user
(for example, with another Persona login).
The second challenge is selecting a PAAS and provisioning the server. I
can do the technical half. The other half is getting a Mozilla credit card
and signing up for a service, which will probably involve WebOps / IT.
The third challenge is procuring a DNS name and related SSL certificates,
which will definitely involve WebOps / IT.
Going with a different solution will reduce or eliminate these challenges,
but add their own. For example, solution #5 (part of the Kuma project)
means that we'll have to start with the standard release procedures for
this very beta code. Solution #4 means restricting the new code to the
kuma toolset - the Python version, Django version, caching solution, web
proxy, scaling solutions, etc.
My instinct is that it will be difficult to move between solutions in
future versions. If we start out with solution #4, we'll stay with
solution #4. Moving between solutions will be similar to the effort to add
another authentication solution to kuma, with the added challenge of little
benefit for MDN contributors - technically and politically hard.
If we're serious about outside contributors, v1 needs to be as stand-alone
as possible. The risk is there's no guarantee that if you build it, they
On Tue, Jul 29, 2014 at 9:17 AM, Luke Crouch <lcr...@mozilla.com
> John Whitlock is working on the new backend  for the Compat Data
> project  that will power MDN's browser compatibility tables. 
> In a pull request , and at yesterday's planning meeting, I proposed we
> host the API under MDN at:
> Another option is to host the API as a micro-service app at a new domain,
> MDN gives us some advantages:
> * We won't need to provision any new servers from WebOps/IT
> * We can re-use existing push (Chief) and monitoring (New Relic) services
> * We can re-use MDN sessions for API authentication
> Are these enough to convince us to host the API under MDN? What are the
> advantages of hosting it as a micro-service outside of MDN?