Page MenuHomePhabricator
Create Task
Maniphest T88301

RFC: Clean frontend - backend separation; make all frontends API consumers
Closed, DeclinedPublic
Actions

Description

A task to explore the advantages and disadvantages of separating all front-ends / skins from the data / API layer. For the purpose of this task, the frontend is the code that

  • adds the chrome around the content (language links, tool links, footer, user tools), and
  • renders special pages.

Advantages

  • Introduces a well-defined interface between frontend & backend
    • Improves testability
    • Reduces the amount of code front-end developers need to understand
  • Drives API improvements (performance and features), which in turn can make our front-end development more flexible
  • Can power single-page-app front-ends with server-side pre-rendering for first load
  • Enables faster testing of UIs and Frontends without using a backend (fixtures)
  • Enables and empowers non-web interfaces like native apps on iOS, Android, etc.

Disadvantages

  • Performance, if not done well
  • Migration cost

See also

Related Objects
Search...

Event Timeline

• GWicke created this task.Feb 2 2015, 6:10 PM
• GWicke raised the priority of this task from to Needs Triage.
• GWicke updated the task description. (Show Details)
• GWicke subscribed.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 2 2015, 6:10 PM
• GWicke updated the task description. (Show Details)Feb 2 2015, 6:12 PM
• GWicke set Security to None.
• GWicke updated the task description. (Show Details)
• GWicke updated the task description. (Show Details)Feb 2 2015, 6:15 PM
• GWicke renamed this task from Clean frontend - backend separation; make all frontends API consumers to RFC: Clean frontend - backend separation; make all frontends API consumers.Feb 2 2015, 6:47 PM
• GWicke added projects: Architecture, Service-Architecture.
• GWicke added a project: TechCom-RFC.
• GWicke updated the task description. (Show Details)
• GWicke removed a subscriber: Aklapper.
• GWicke added subscribers: • TrevorParscal, Krinkle, • brooke, kaldari.
EBernhardson subscribed.Feb 2 2015, 6:49 PM
• GWicke added a subscriber: • Nuria.Feb 2 2015, 6:49 PM
fbstj awarded a token.Feb 27 2015, 9:24 PM
daniel closed this task as a duplicate of T89889: RFC: Service split along presentation vs data manipulation line.Mar 4 2015, 8:28 PM
daniel moved this task from P1: Define to (unused 2) on the TechCom-RFC board.Mar 4 2015, 8:33 PM
daniel moved this task from (unused 2) to Declined on the TechCom-RFC board.
• Spage added a subtask: T89889: RFC: Service split along presentation vs data manipulation line.Mar 11 2015, 9:16 PM
• GWicke reopened this task as Open.Mar 11 2015, 10:05 PM
• GWicke added a comment.Mar 11 2015, 10:09 PM

Re-opened as the focus of RobLa's RFC (T89889) seems to be more on internal MW refactoring, and less on building front-ends on top of APIs that are also exposed to other services and clients.

• GWicke mentioned this in T89889: RFC: Service split along presentation vs data manipulation line.Mar 11 2015, 10:11 PM
• GWicke updated the task description. (Show Details)
• GWicke updated the task description. (Show Details)Mar 11 2015, 10:14 PM
bd808 moved this task from Declined to Old on the TechCom-RFC board.Mar 12 2015, 12:19 AM
bd808 subscribed.
Anomie subscribed.Mar 12 2015, 1:51 PM

Reading this, and more so reading comments by the author at the recent RFC meeting for T89889, I find this RFC unclear.

For example, MediaWiki PHP code implementing a frontend page should be calling the "API" provided by MediaWiki PHP "controller" classes. It should not be calling the "API" provided by ApiBase subclasses, or be calling ApiMain, or be using curl to hit api.php. On the other hand, using curl or something like it to hit api.php would be appropriate for code external to MediaWiki, since that code doesn't have direct access to call the PHP controller classes.

I'm not sure whether this RFC as currently written is ignoring that internal/external distinction or is assuming/advocating a complex Hurd-style architecture where effectively everything has to go through layers of IPC.

• GWicke mentioned this in T111588: RFC: API-driven web front-end.Sep 5 2015, 12:57 AM
• Jhernandez updated the task description. (Show Details)Oct 5 2015, 6:49 PM
• Jhernandez awarded a token.
• Jhernandez subscribed.
• RobLa-WMF moved this task from Inbox to Tracked as ArchCom-RFC on the Architecture board.Mar 17 2016, 10:32 PM
Danny_B added a project: Proposal.May 2 2016, 10:13 PM
• RobLa-WMF mentioned this in E187: RFC Meeting: triage meeting (2016-05-25, #wikimedia-office).May 25 2016, 7:03 AM
Krinkle removed a project: Architecture.Mar 31 2017, 10:15 PM
• Niedzielski subscribed.Jul 9 2017, 7:11 PM
• Jhernandez mentioned this in T177464: Submit an RFC and discuss it with TechCom.Oct 5 2017, 10:10 AM
Krinkle removed a project: Proposal.Dec 21 2017, 11:39 PM
daniel subscribed.Jan 9 2018, 5:54 PM

This RFC has been inactive for more than two years now. In the light the outcome of T169266: Clarify recommendations around using FauxRequest, it should probably be declined. The desire to have a clear separation between frontend (presentation) and backend (application logic and storage) has merit, but that is covered sufficiently by T89889: RFC: Service split along presentation vs data manipulation line.

Krinkle closed subtask T89889: RFC: Service split along presentation vs data manipulation line as Declined.Jan 31 2018, 12:31 AM
Krinkle closed this task as Declined.Jan 31 2018, 12:35 AM
Krinkle moved this task from Old to Declined on the TechCom-RFC board.

Like T89889, closing in favour of T111588: RFC: API-driven web front-end.

TechCom generally prefers smaller RFC as opposed to one very large RFC, such such merging may seem odd. But in this case, neither of the three related proposals is more or less specific, all three are broad and generic, and this should help consolidate the efforts. I imagine that T89889 will likely turn from an RFC into a tracking task with individual RFC being spawned from it as we go.

Aklapper removed subscribers: Anomie, • TrevorParscal.Oct 16 2020, 5:28 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL