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 and templatized and that all hooks and skin interfaces used data instead of HTML, leaving rendering to the final step before output. Combined with a backend system that broadcasts events allowing for more asynchronous processing, 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.

API Approach
One idea for Mediawiki as Service would be to the existing MediaWiki API 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 already (api.php), we also have our own ways to deal with nirvana feature (wikia.php).

The current API is not well suited to this kind of approach and would naturally overlap with the effort to revamp the API: Requests for comment/API roadmap

Pros
 * The Api is testable.
 * The 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

Functional Decomposition Approach
Another idea for Mediawiki as a Service is a complete rewrite of the core of mediawiki into services responsible for different aspects of the application. In general, a service oriented architecture encourages use of the following patterns in components: Most classes in Mediawiki core are actually more like Utility classes filled with helper functions intended for manipulation of internal or global data structures. If core areas of code such as Authentication, User Rights, Editing, Revision management, Parsing, Rendering, Events and Logging could be separated out into totally separate services that depended on no global variables, only interfaces then mediawiki functionality could be more easily integrated with other applications, and the different components could be used in a standalone way by projects that just needed one feature without bringing along the entire "product". Combined with a separation of Data and UI concerns, this would allow Mediawiki to become a more abstract wiki framework that doesn't necessarily have to look like Wikipedia.
 * Abstraction + Autonomy + Loose coupling
 * Stateless + Composable
 * Autonomous + Authoritative
 * Discoverable + Service Contracts

TODO
Come up with some specific examples of how this would work