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

Strawman proposal for moving forwards

Yes please. There are numerous advantages to this, from making it easier for first time MediaWiki hackers to write patches by separating presentation from function, making code more modular and reusable and therefore increasing velocity, and increasing the ease with which functions can be exposed via the API. A task of this size is likely going to take quite some time and there will be numerous edge cases, but any progress made would be a massive step forwards. Straw man proposal for first milestone: refactor special pages so that there is no place in MediaWiki where the API has to instantiate a special page in order to function. --Dan Garry, Wikimedia Foundation (talk) 04:11, 16 February 2015 (UTC)

Architecture-level split or system-level split?

I feel the meaning of "split" a bit unclear in this proposal. Separating presentation logic from business logic is a fundamental element of every sane architecture; ensuring that no class tries to do both would be uncontroversial, I am sure. However, in the SOA discussions "split" usually means separating things into different system processes, possibly on different machines, which use language-agnostic ways of communication (such as REST). I.e., a two-tier architecture with separate MediaWiki Frontend and MediaWiki Backend applications, the frontend doing all data read/write by calls to the backend API. That's a more bold proposal with less obvious benefits, and more hardships (for one, I'm not sure it could be done with slow, gradual refactoring). So which one is being suggested? --Tgr (WMF) (talk) 05:51, 16 February 2015 (UTC)

• I don't think it's absolutely necessary to split things such that the presentation logic and the business logic only communicate through HTTP. However, the APIs between those components should be such that a mobile application could use the same APIs over HTTP that the web application uses internally. -- RobLa-WMF (talk) 06:39, 16 February 2015 (UTC)
• (edit conflict) I read this request for comments as being about the splitting of business logic from presentation logic, which is something that is currently very intertwined in parts of MediaWiki. In doing that, the internal API that's used by the MediaWiki front-end would then be very clearly defined, which eases exposing it to other API consumers. I'd personally prefer that we simply focus on that task for now, because it's still a rather big task and it's a big step forwards that unlocks a lot of other possibilities. --Dan Garry, Wikimedia Foundation (talk) 06:45, 16 February 2015 (UTC)

All business logic available via remotely callable api

I would rephrase the statement "Split our backend code that deals with presentation (e.g. HTML generation, such as our skin system) from the code that deals with storage and manipulation of data." to instead say something like "All business logic must be available via remotely callable APIs". In my opinion this is the true goal of a service layer split that separates presentation logic from the business logic of the underlying system. This type of separation can be implemented in many different ways. One way is to re-arrange existing implementations in such a way that business logic is encapsulated in controller classes which communicate using well defined interfaces. These can then in turn be consumed and aggregated by other controller classes to implement view layers in HTML for consumption by web browsers and some variety of HTTP-based remote for consumption by other things. --BDavis (WMF) (talk) 06:48, 16 February 2015 (UTC)

Missing important specifics

Hi. In looking at the current draft, my concern is that this request for comments lacks specific actionable examples. If there's a real problem here, it shouldn't be difficult to come up with a list of at least a few examples where a cleaner/clearer split would've really helped us. (The proposal uses the phrases "a lot" and "often," so I'm basically throwing out a couple [citation needed]s.) I think by looking at specific problematic parts of the current codebase, we'll increase focus in this discussion and we'll be able to more easily see larger design/architectural patterns (or anti-patterns!).

I understand that this proposal is somewhat intended to be high-level, but currently it's too vague to be useful, in my opinion. The "Problem" section needs to be fleshed out. --MZMcBride (talk) 08:04, 16 February 2015 (UTC)

Collecting some concrete examples would be nice to illustrate the architectural principle being promoted. Off the top of my head Allow triggering of user password reset email via the API is the sort of thing that I would expect a cleaner separation of UI and business logic to readily address but I'd like to see more examples as well. On a gut feeling level, I would guess that much of the initial work would be targeted at SpecialPages both in core and in extensions. --BDavis (WMF) (talk) 19:04, 16 February 2015 (UTC)

Extensions actually getting a chance to define how the page is going to look. Less bugs about URLs pointing to the wrong place when the parsing is done on a different wiki (e.g. foreign file repo description pages). Getting rid of behavioral differences between interfaces which present different views of the same data, such as old-style and enhanced recent changes. More modular, easier to understand code. --Tgr (WMF) (talk) 19:25, 16 February 2015 (UTC)

"Special page calling API" anti-pattern

Please, no. There is absolutely no reason to serialize various variables in a FauxRequest and then attempt to extract the results out of the ApiResult. For most actions there should be a common backend class that implements the logic, and both the special page and the API module call this common backend class. Some query modules may be exceptions, where a corresponding special page does not exist or the optimization of batch-style SQL querying done in the API cannot match the querying done by the special page. Anomie (talk) 15:05, 23 February 2015 (UTC)

Anomie, we talked about this at length in yesterday's RFC Office hours meeting:: "AGREED: nobody is in favour of having special pages do FauxRequest calls to ApiMain". We discussed alternatives "consider Interactor pattern for code review between SpecialPages and API", "improve the RFC pattern #2 with more specifics", the width of PHP service APIs, etc. -- SPage (WMF) (talk) 08:55, 12 March 2015 (UTC)

Another proposal to merge in

Seems like similar proposals keep surfacing at the same time - I have created a task and a Business Layer Architecture on budget RFC, and later discovered this. My idea is to refactor all formatting code from the API modules, and provide a better interface with objects like Title/TitleValue/User used for parameters and for output. A separate code would convert extarnal API requests into internal API module calls. I am still not clear on the actual interface - we obviously want to reuse all the SQL optimizations API provides, as well as combinatorial approach where multiple items can be requested from the API in one call. Would it make sense to keep a dictionary as a main parameter interface into internal API, and provide a few helper functions for the most common cases? --Yurik (talk) 04:23, 7 April 2015 (UTC)