Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Background
Drupal 8 has so far seen many major improvements to alternative ways to access data through the inclusion of REST in core. In an environment where Drupal may be increasingly accessed by means other than http, we will need a way to allow other systems to more easily access, in real time, content managed by drupal and cause actions within drupal. We propose an initiative with goals to improve in this area by including new experimental core functionality.
A big focus for this initiative will be to get the necessary sign-offs ahead of time in order to make it possible (and sustainable) to work toward the big end goals of this initiative.
Goals
We need to strategize around this. Right now I am researching running Drupal as a service or daemon that would allow alternate access endpoints to be managed. I am not sure this is the best solution for this, but it is the best thing I can think of at this time --suggestions are welcome.
Other strategies:
- SDK that can access Drupal's data but is otherwise self-contained.
- ... We need more of these.
Must have
Access points for systems inside and outside of php to access Drupal's systems and cause events and reactions within drupal. This could take the form of Drupal running a websocket endpoint, or a socket connections, or MQTT connection. The specifics are not important and the actual connection needs to be able to be handled in core. Drupal needs to facilitate this and manage the safe starting and stopping of the connection.
Should have
One (or more) connection endpoint out of the box and SDKs that support that endpoint for different development environments.
Suggested list of supported SDKs:
- PHP
- Javascript
- Nodejs
- Swift
- Java (android)
Could have
More supported endpoints and SDKs out of the box.
- C#
- Elixir
- Ruby
Signoffs needed from contrib maintainers
Thanks to the Content Workflow Initiative. I took much of the structure of this from that post.
Comments
Comment #2
webchickSorry, this fell totally off my radar. :(
However, given this seems to be all about the framework side of Drupal, and not about the user-facing parts, tagging for framework manager review instead.
Comment #3
frobAwesome, I was working on a proof of concept at DCLA and it looked promising. Especially if combined with IoT and non-http protocols.
Comment #5
webchickHi there! This is an issue that we'd ideally like to move to the new "Drupal core ideas" queue when/if #2785735: [policy, no patch] Agile process for bigger changes in core (Part A: Ideation) goes through (hoping for the next week or two). If you could read that issue and provide any thoughts you might have, that would be great!
Comment #6
webchickComment #7
frobI have commented on that issue, sorry I didn't see this earlier. I also changed the title to better reflect what this issue is about.
Comment #8
webchickMoving over to the new Drupal Core Ideas queue while we get this into shape.
Comment #9
frobChanged the title to make it more informative in the ideas queue.
Comment #10
catchThere's already work in the core issue queue to try to help with long-running processes.
For example #1199866: Add an in-memory LRU cache tries to deal with the memory implications from entity caching if you keep loading thousands of different entities.
#2717207: Add a time service to provide consistent interaction with time()/microtime() and superglobals abstracts how time is accessed.
Stuff like that doesn't need sign-off
Adding SDK endpoints etc. does need sign off but would want to see this fleshed out more - however that won't be useful until Drupal can be successfully run as a daemon/service.
Comment #11
frob@catch is this a goal of Drupal? This would be more about making this an ability of core and organizing around that.
Comment #12
yoroy CreditAttribution: yoroy at Roy Scholten commentedHow does this relate to #2757967: API-first initiative ?
Comment #13
frob@yoroy, currently this isn't a part of the API-first initiative. I think it should be, but that initiative currently is more focused on more traditional non-realtime apis. Even long running api calls, such as GraphQL and such, do not require the running of Drupal as a service.
Running Drupal as a service would more allow for true real-time event driven systems, such as home-automation systems and other IoT protocols.
Comment #14
frobI noticed there is already work being done in several places to make this more of a reality. It might make this more possible if this was acknowledged as a goal of the API-first initiative.
https://groups.drupal.org/node/417723
https://www.drupal.org/node/2218651
Maybe the answer is to run a separate FastCGI client that invokes Drupal though the php FastCGI server. https://stackoverflow.com/questions/6801673/python-fastcgi-client
Comment #15
dawehnerIt would be nice to document actual usecases where serving content via HTTP doesn't cut it. Many places out there just offer form of HTTP based APIs and they are fine with that.
Comment #16
frobMany IoT devices communicate over MQTT, and KNX. These are extremely low powered devices and connecting to them would require a bridge service which converts them to an http to talk to Drupal.
A use-case, a user has an MQTT switch (such as a sonoff) and they want to create a schedule for it to turn on and off with Drupal. Currently they would need to also have a MQTT bridge that is passing the connection to/from Drupal. If Drupal was able to accept the MQTT connection directly a more secure and robust home automation system could be designed around it.
Comment #17
frobAnother use-case. Websockets.
Currently in order to utilize websockets it requires maintaining a separate non-drupal code-base. This means utilizing Drupal data requires creative solutions for real-time connections, usually this means server-side http connections between services.
Some info on using Websockets in php:
https://www.youtube.com/watch?v=J1F1z6mkDlY
Comment #18
nod_