Architecturally it may be desirable to factor our codebase into multiple independent services with clear APIs, but small wikis would clearly like a "single server" installation with all of the services running under one roof, as it were. Some options previously proposed have involved VM containers that bundle PHP, Node, MediaWiki and all required services into a preconfigured full system image (T87774).
A bit of further hacking would allow you to install mediawiki skins or extensions via NPM and to dispatch to Parsoid (running in the same process).
- Determine whether this technology (or something similar) might be an acceptable alternative for small sites which are currently using shared hosting. See T113210: How should Wikimedia software support non-Wikimedia deployments of its software? for related discussion.
- Identify and address technical roadblocks to deploying modular single-server wikis (see below).
- Certain pieces of our code are hardwired to specific directories underneath mediawiki-core code. This complicates efforts to run mediawiki from a "clean tree", and to distribute piece of mediawiki separately. In particular:
- It would be better if the vendor directory could (optionally) live outside the core mediawiki tree, so it could be distributed separately from the main codebase, and allow for alternative package structures.
- Extensions and skins would benefit from allowing a "path-like" list of directories, rather than a single location underneath the core mediawiki tree. Extensions/skins could be distributed as separate packages, with a simple hook to add their locations to the search path.
- @tstarling has suggested that when running in single-server mode, some internal APIs (for example, between mediawiki and Parsoid) would be better exposed as unix sockets on the filesystem, rather than as internet domain sockets bound to localhost. For one, this would be more "secure by default" and avoid inadvertent exposure of internal service APIs.
- It would be best to define a standardized mechanism for "services" to declare themselves & be connected & configured. This may mean standard routes on a single-server install (/w and /wiki for core, /parsoid for parsoid, /thumb for the thumbnailer service, etc), or else standard locations for unix sockets.
- Can we leverage some of the various efforts to bridge composer and npm (for example), so we don't end up with incompatible packaging?