User:Owyn/Mediawiki As Service
| Mediawiki As Service | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Owen Davis |
| Document status | in draft |
Summary
[edit]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. Of the two approaches described, we feel like the API approach would be easier to implement, as the second one would involve an almost complete rewrite of mediawiki to do properly.
API Approach
[edit]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
[edit]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:
- Abstraction + Autonomy + Loose coupling
- Stateless + Composable
- Autonomous + Authoritative
- Discoverable + Service Contracts
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 even have to contain any of the look and feel of Wikipedia.
Examples
[edit]One example of how this has worked is the "Chat" application developed by wikia. It's a node.js app that among other things uses a wrapper called WMBridge https://github.com/Wikia/app/blob/dev/extensions/wikia/Chat2/js/WMBridge.js to communicate with mediawiki through the API to authenticate users, parse wikitext, load emoticons defined as mediawiki messages and a few other functions.