User:Owyn/Mediawiki As Service

We would like to evolve a long term strategy towards separation of internal data structures and business logic from rendering wikitext. We call this idea "Mediawiki as a Service". For example, imagine that all HTML/HTTP related code is removed from core or templatized and that there was a type of Skin that just exposed data instead of HTML. Combined with a backend system that broadcasts events so that hooks worked (more like an Actor model), and a replacement for the shared state/global variables that are currently used then it could be possible to use mediawiki as a core component of a service oriented architecture with a completely different front end, or as an embedded part of a larger application. This seems like it would be useful in other projects such as mwlib.

One idea for Mediawiki as Service would have a simple architecture if we could just use api of MediaWiki and build a frontend on top of it. The frontend would communicate with MediaWiki using HTTP (or compatible) calls. MediaWiki exposes most functionality as api methods (api.php), we also have our own ways to deal with nirvana feature (wikia.php).

Pros
 * Api is testable.
 * Api is easily extendable
 * We don’t need to modify core mediawiki and because of that we could easily upgrade to newer version.
 * Frontend can be written in any language or framework
 * Easier to write mobile frontend (I guess)
 * Foundation choices doesn’t have to be our choices (e.g. javascript libraries, resource loader etc)

Cons
 * It is not REST (or any standard type of API)
 * Most of MediaWiki code would not be used
 * MediaWiki Extensions would not be used unless exposed by API
 * Frontend has to be built (almost) from scratch
 * We still don’t have guarantee that api will not change in future.
 * It won’t be MediaWiki for enduser