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

Request for comment (RFC)
Service split along presentation vs data manipulation line
Component	General
Creation date	16 February 2015
Author(s)	Brion Vibber (WMF) and RobLa-WMF
Document status	declined 2015-03-11 RFC office hours discussion See Phabricator.

Tracked in Phabricator
Task T89889

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.

Create a business logic class to start isolating the logic from the HTML UI
Add an API module to expose the logic via web UI for apps and JS
Progressively enhance the web UI special/action to use the API when JS is available
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
phab:T89971 - rework of Image info to fit client usages better
phab:T32788 - Allow triggering of user password reset email via the API
Requests for comment/Rewrite enhanced recent changes