Requests for comment/Service split along presentation vs data manipulation line

This RFC calls for a split of backend services between presentation on one side, and data storage and manipulation on the other.

Background
There has been much talk in 2014-2015 about moving toward a service-oriented architecture. One aspect of that strategy should be defining where we want the fissures in our architecture to be, and then defining a strategy for creating a cleaner separation of code along that fissure.

Problem
Currently, we have a lot of code that entangles database manipulation with presentation of the data. This makes it difficult to create different user interfaces that present the same data. For example, the task of creating a mobile application that does the same thing that our desktop code does is hampered by the fact that the desktop code often manipulates the data directly rather than operating through an API that can also be available to the mobile application.

Proposal
Split our frontend code that deals with presentation (e.g. HTML generation, such as our skin system) from the backend code that deals with storage and manipulation of data. This desire may (and should) seem obvious, and is more-or-less stated in more specific proposals (e.g. Redo skin framework and services and narrow interfaces). What this proposal calls for is for us to generally agree on the direction, and then make explicit the desire and urgency to propose and implement solutions in this area.

The Lines
There are other lines that we can split things along that achieve many of the same goals as this RFC. T


 * between UI & core logic
 * between core logic & storage
 * between extra logic & expandible services (?)

Note: these are not central to this document, but are possible directions for future RFCs.

[flesh this bit out]
 * stateful vs stateless... sorta a restatement of presentation vs business logic. (state belongs in logic side)
 * caching vs storage state

(draft) Patterns
Several possible patterns that can be followed in this direction. This RFC doesn't recommend any particular one, but rather, is a survey of possibilities that should be considered.

API as backend

 * API module with business logic
 * Special: page or action calls API internally

Common model/controller

 * Class that does the actual work
 * API query class -> for apps and JS/web
 * Special: or action -> for the base web UI

Separate services

 * Separate service sits behind one of the above models
 * May have a pure-PHP alternative (as with built-in MySQL search vs external CirrusSearch) or may be a progressive enhancement feature

Migration models
Example: Special: page or action has mixed biz logic and wikitext or HTML output.


 * 1) Create a business logic class to start isolating the logic from the HTML UI
 * 2) Add an API module to expose the logic via web UI for apps and JS
 * 3) Progressively enhance the web UI special/action to use the API when JS is available
 * 4) profit!

Considerations for team management

 * Consider having separate people working on separate sides of API lines -- make sure the APIs are clear, well contracted, both sides stay maintainable
 * Consider needs of multiple consumers for an API -- design them to serve the multiple cases well

Examples

 * Redo skin framework
 * T89971 - rework of Image info to fit client usages better
 * T32788 - Allow triggering of user password reset email via the API
 * Requests for comment/Rewrite enhanced recent changes