User:Daniel Kinzler (WMDE)/Frontend Architecture

This document describes how MediaWiki's user interface should function. It is intended to provide constraints and guiding principles for feature development.

The front-end architecture defines the flow of information and control between the client device and the application servers (or, more generally, the data storage layer). In practice, this mostly mostly means defining when, where and how HTML is generated, manipulated, and assembled.

Assumptions

 * 1) MediaWiki has to be installable on a plain LAMP stack without root access (shared hosting use case).
 * 2) We cannot reply on being able to run PHP and JS code in the same process / without the need for communication via the network stack (no v8js in PHP).
 * 3) Eventually, we want to allow fully data driven UIs (meaning that all HTML is generated on the client). This requires all functionalityto be available via an API.
 * 4) However, we want to support at least consumption of all content, including meta-data, on HTML-only devices with no JS support.
 * 5) We want the ability to serve different content to different classes of clients (varying on screen size, accepted language, etc).
 * 6) However, we also want the ability to serve reactive content to the client which adapts to the target device's capabilities.
 * 7) We cannot assume that all functionality can be converted to a data driven approach right away, it will take some time for e.g. all extensions to be converted to a data driven approach. We need to cater to transitional stages. We aim to make the most common workflows available via APIs soon.
 * 8) We'd like the ability to render declarative templates on the client as well as on the server.
 * 9) We want consistent localization when rendering on the client or on the server, including message strings, parameter substitution, plural handling, and formatting for numbers and dates.

Components

 * Page composition at the network edge (probably using ESI). API for serving HTML snippets (some cacheable globally, some per user, some not at all)
 * This requires a dependency tracking and puring engine (using Kafka as a bus and some graph database for storing the dependency graph). Used to re-generate HTML snippets (and other derived artifacts).
 * skins, etc..
 * Template engine with a JS and a PHP implementation.
 * If we have localization implemented in both JS and PHP, templates can be fully data driven
 * If we have PHP code as the single source of truth for i10n handling, templates can only use pre-formatted data. This would probably require an API mode that doesn't return abstract JSON nor rendered HTML, but some kind intermediate form (which may be augmented HTML).
 * special pages...