Taking a bit of inspiration from KeystoneJS - with the API-first initiative for D8, as well as some heated discussions about adding a front-end framework to core, it's worth considering fully embracing some dogfooding. It's currently not possible to build a decoupled interface into Drupal that can perform all the available tasks through a standard administrative theme.

Proposed resolution

  • Ship Drupal with a standalone Symfony application that handles routing, form generation and rendering.
  • Modules plug into Drupal Core for any data saving, exposure and validation. Then separately into the stand-alone application for displays.
  • Drupal Core and Drupal Admin/Front-end can only communicate through web requests/sockets (There are clearly performance issues and questions here. One option is to design it this way to force us to be disciplined about having clean interfaces, and replace it with something that does direct access when running in production)

Major APIs currently missing:

  • Form API isn't exposed, so it's not possible for another system to build or validate a form against Drupal. This should probably not include extra bells and whistles like ajax and paging, leaving that up to the front-end implementer.
  • Same for Configuration, although this is in the works.
  • Blocks (currently our only layout engine that's in core).

Example for creating a new node:

  • The node add page in the Admin/Front-end app requests data from Core for how a form should be built.
  • Generate and render the form using Symfony's form builder.
  • User submits the form.
  • Symfony controller dispatches the data for validation, if it fails, it rebuilds the form with error messages. If it's valid, Core saves the data and returns the new object.
  • Show a view in the Symfony application with the new object.

If that works out, routing and rendering etc could be removed from Drupal Core entirely and solely done in the stand-alone app. If someone wants to build a different administration/front-end interface in a cool new framework, this is now possible without imposing it on all Drupal users. If it doesn't work out, we at least get some better APIs.

I've suggested Symfony as it's something we're already familiar with as a community, but whatever framework we chose is going to be ultimately (hopefully?) be inconsequential.

Obviously there's a bunch of stuff I haven't touched on, like multi-lingual, but this is just to get the discussion started.


justafish created an issue. See original summary.

emarchak’s picture

I’d like to point out a use case that may not be covered if we move the Form API to the Symfony form builder, without allowing the dynamic generation of forms that Form API allows.

We have an entity type that represent TV Shows, and administrators want to create multiple forms per show. These forms are to allow the audience to contact hosts, apply to participate in reality shows, etc., so they’re different for each show. Similar to Google Forms or Survey Monkey, but we wanted it in Drupal.

If the form structure is forced to be in config, and not dynamic, this use case wouldn’t be met.

If the form structure is able to be generated by the back end, and THEN passed to the form builder, we’d have the flexibility we’d need. This would also allow for the bells and whistles (ajax, paging, etc.) to be added in at later, as I can generate the structure based on our business logic.

I really like the standalone Symfony application idea. I hope there’s traction!

prestonso’s picture

This proposal opens an alternative pathway for #2645666: [policy, no patch] Require Node.js for Drupal 9 core and rewrite some of Drupal's UI code from PHP to JS with regard to JavaScript-driven administrative front ends. One initial note I have about this proposal is that we should endeavor to make the API-first Drupal back end as agnostic as possible and not conflate what we need from Drupal's web services with what we need to serve a Symfony front end. That way, even if a new front-end approach comes along, Drupal is still just as well-equipped for those requirements. In my opinion, the best way to ensure that the APIs remain as front end-agnostic as possible is to have parallel efforts that effectively dogfood, such as a second side-along effort in JavaScript.

mrjmd’s picture

+1 to this proposal and Preston's approach here, this sounds like a very sensible way to open up experimentation of building administrative interfaces with new technologies without having to pick one.

Is there any active investigating going on now into level of effort for exposing the Forms API?

dawehner’s picture

Issue summary: View changes
prestonso’s picture

yoroy’s picture

How does this relate to #2346619: Roll back the kernel/most of routing (if at all)?

dawehner’s picture

#2346619: Roll back the kernel/most of routing is mostly to blow off one's steam, while not changing any fundamental ways how the Drupal page rendering system works.

This issue instead proposes to change the Drupal page rendering system by separating the "Drupal the thing which stores stuff and handles with data" to "Drupal, the thing which actually renders anything". By separating the two, as written in the issue summary, we would require to be actually API first.