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

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

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

Background[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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

Common model/controller[edit]

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

Separate services[edit]

  • 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[edit]

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[edit]

  • 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[edit]

See also[edit]

Retrieved from "https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Service_split_along_presentation_vs_data_manipulation_line&oldid=2704698"