Some web UIs with very rich UXes have an architecture made up of two parts;
- REST API server; Connects to the database and controls and manipulates all data coming in and out of the database, but never "renders" anything other than formatted data (e.g. JSON); It never does anything related to any markup.
- UI server; Static resources for the web browser: an "index.html", JavaScript, CSS stylesheets, templates and UI/chrome images (but not content images uploaded by users).
These two parts are served from different servers on different domains. All of the data-related logic is in the processing XmlHttpRequests. All the UI-related logic is in JavaScript.
How does Drupal fit in to such an architecture?
- PHP serves no purpose on the UI server; everything is static, and JS/Sass is compiled, minified, aggregated upon deploy, not at runtime.
- Drupal does an awful lot that is not useful on the API server, and difficult to shut down;
user/login,node/NIDfor starters.
So what role does Drupal play?
Drupal would be useful for data/content modelling, serving the REST API and maybe an admin UI, albeit with a UX that may be inferior to the rich UX of the pure JavaScript front-end.
But this neglects much of Drupal's value. I imagine using Drupal in this way would be painful compared to tools that are pure frameworks and not products. E.g. tools do not assume by default that HTML is being served and that make zero assumptions about what the app should do until you write code to tell it what paths to serve, attach an authentication library, describe a data model or API endpoints.
Is this headless Drupal? Does Drupal have a role in such architectures? Even when compared to existing pure framework tools?
Comments
Great questions. One of
Great questions.
One of Drupal's biggest strength in any architecture is how easy it is to build rich content models in it's own UI. This means that non-technical users and front end developers can not only edit content, but can also edit the content model without writing a line of code.
It's unlikely, and probably impossible to build a separate UI/Chrome that allows users to edit the content model in Drupal and still be able to use a separate UI/Chrome. You might be able to build a bridge API, but I think that Drupal contrib modules would always find new ways to break that bridge, and the Drupal form API and entity API are so intertwined it would be very difficult to make a separate UI that isn't part of Drupal.
However if your UI is primarily presenting content, or if your users are interacting with the content and not editing it. You can build very rich apps without a developer that knows both the UI server and the REST server.
It's true that it's hard to turn off the html endpoints in Drupal, but it's not impossible. One architecture that I've seen is limiting the HTML endpoints in Drupal to editors behind a firewall and only exposing the REST API server to the rest of the world. This approach can be modified to use a different auth method instead of a firewall per-se.
Nuking Drupal's Frontend
@Bevan Good points for discussion!
Drupal does have a lot of non-frontend functionality. Of course it also has a lot of frontend-only functionality, often without a clean separation between the two (better in D8 than D7 in some ways, but still takes work to strip out the frontend).
The Nuke Drupal Frontend module (currently for D7) helps with this:
(Note this assumes Drupal's administrative UI is not going to be replaced by a separated admin frontend)…
Leaving Drupal as a backend-only, configurable content store, that can double as a REST server. That sounds like a useful role to me. What do you think?
Indeed, a comparison would be
Indeed, a comparison would be very useful for anyone looking build headless-Drupal websites/apps.
Bevan/
I agree the API server seems
I agree the API server seems to be the place for Drupal to fit into such an architecture. However Drupal still seems like a poor tool of choice for that role compared to a pure framework. Still, the best tool is the one you know...
I just heard about RESTful module for Drupal 7 which seems focussed around making Drupal provide a clean JSON REST API, fitting the bill for that role.
Bevan/
REST comparison page
@bevan I've been meaning to talk w amitaibu about restful. I'm not sure yet all the ways that differs from http://drupal.org/project/restws, but would love to know. It might be worth making a g.d.o module comparison page about the various D7/D8 options available now
Drupal has two heads
@mizru says: "One of Drupal's biggest strength in any architecture is how easy it is to build rich content models in it's own UI. This means that non-technical users and front end developers can not only edit content, but can also edit the content model without writing a line of code."
I agree, though I would decouple the admin UI from the ability to build rich content. Drupal (especially with D8 and beyond) is a locus for creating semantic content that can be re-re-represented in a variety of ways.
The content creation use case is key: Drupal is, after all, a content management system, not a content representation system. Content management encompasses the ability to not just CRUD content but control its access, workflow and syndication.
A "pure framework" is a straw man in this scenario. While a "pure framework" might provide low-level scaffolding for content creation, Drupal provides a significantly more robust set of tools to manage who can see, edit, create, delete, transmit, syndicate, and (meta) describe content at a particular time, in a particular context, for a particular audience.
A "pure framework" is a straw
A "pure framework" is a straw man in this scenario. While a "pure framework" might provide low-level scaffolding for content creation, Drupal provides a significantly more robust set of tools to manage who can see, edit, create, delete, transmit, syndicate, and (meta) describe content at a particular time, in a particular context, for a particular audience.
This is huge. Drupal is much more than scaffolding.
I assume you a "straw man"
I assume you a "straw man" argument.
You may well be right. That is one of the things I am trying to work out with this conversation.
Bevan/
To balance your last point, I
To balance your last point, I have heard of frameworks (django or rails? I forget) that will provide CRUD forms with form widgets for all the entity's fields just by describing the entity, schema and form widgets per field/property to the system. I assume that would be like writing a feature module by hand, but with an API that is sane enough you can actaully get your head around it, instead of needing a big complicated GUI (Drupal) and Features (or config management).
I have not used it so I can not comment confidently on their completeness or ease of use.
Of course a non-developer can not change the content/data model. But then I never recall having found that a useful feature, so that is a good thing in my opinion.
Bevan/
We build pure applications
We build pure applications (Mostly in node.js), Drupal sites and headless Drupal sites. There are final products that are much easier to build with a framework, and yup working with features sucks, but if your list of requirements lines up with the capabilities of drupal, even on the backend it's not just "the solution you know" it's worth the overhead of the config quirks to save time on building an administration backend.
The option that puts the whole equation on it's head is something like https://prismic.io/ which is only an API and administration backend.
Thank you @mirzu for your
Thank you @mirzu for your insights.
Prismic is really interesting. I think this FAQ captures the essence of its uniqueness compared to alternatives; https://prismic.io/faq#how-is-it-faster-and-easier-to-use
If Drupal were to have a role in the architecture described in the original post, I think something very equivalent to Prismic would be Drupal's sweet spot. If I have understood the other comments correctly, I think most of the other commentators would agree. (Correct?)
I am interested in how you decide, more specifically, whether or not to use Drupal for your projects.
I imagine that if a project's content is almost only user-contributed and there is not much of an admin UI to build, then frameworks are more favourable. But if the content is almost only generated by a small group of selected individuals, then Drupal beats a framework.
Is this correct? How far along the continuum between those two extremes is the tipping point? What other factors help you decide whether or not to use Drupal?
Also; once eight is the version of choice for Drupal, do you think would you still use Node JS for projects that do not use Drupal? Or would you consider Symfony2 (without Drupal)?
Bevan/
Similar tools
I wouldn't call Prismic unique. I wouldn't expect them to point to their competitors, but they do have competitors who also do content publishing only via API. These are the ones I know about:
https://www.contentful.com/
https://gathercontent.com/
http://www.camayak.com/
http://marquee.by/
[Moved]
[Moved]
Bevan/
Thanks for the list. By
Thanks for the list.
By "unique" I meant different to other two options being discussed for an API server and admin UI; Use Drupal, or use a framework.
The websites you linked to all seem like hosted commercial services that have limitations in regards what you can build with them (compared to self-hosted Drupal). I.e. You can not extend them with your own server-side code. Correct?
Do any of existing software tools (frameworks or products) make it really easy to build and host such a web application for your own project?
We have already discussed how frameworks can do this but lack rich understanding of custom content models that is baked into Drupal (for better or worse).
And we discussed how Drupal can do this, but still assumes that it is serving the front-end (even when it is not), defaults to serving HTML and is fidly to get a clean REST API out of.
Would it be reasonable to say that the goal of this group is to make Drupal better, so that Drupal can easily be the API server and/or admin UI? Does that also mean Drupal may need to stop assuming it is serving the front end and make the default render format configurable to something other than HTML?
Bevan/
It's been a LOOOONG time
It's been a LOOOONG time since I played with Rails but even back then it had CRUD form system called "scaffolding". And Django's main feature is the "automatic administration". But you don't get the nuanced permissions, roles, publishing workflow and integrations you get with Drupal + contrib.
You either need a "big complicated GUI" for administrative purposes or you don't. And if you don't, Drupal probably isn't the right choice as a framework.
As for non-developers changing the content/data model--those people are called "site builders". :-)
Thanks for sharing your real
Thanks for sharing your real life experience. That helps a lot! :)
Bevan/
Krlucas' comment about "site
Krlucas' comment about "site builders" is key here.
Let me frame this from their perspective.
Let me describe one:
She writes no code of any kind, she does everything through the admin interface, there she knows how to create nodes, arrange blocks, create content types, edit views, entity references, panels layouts, install modules and themes etc. With these tools she has the power to do a vast number of things that formerly would have required a developer. She probably works in an organization where there is a developer who can troubleshoot module conflicts, bugs or performance issues but doesn't need to ask for help that often.
One day the developer comes to her and says "we are rebuilding the site to be headless"
in the world of headless Drupal can she still do all of these things? I'm inclined to think she can't change themes or arrange blocks, or work with panels, and it may even be more difficult for her to preview nodes or views. In essence, more than half of the functionality she has come to expect will not be there.
For the site builder this does not seem to be much of an improvement.
No, I don't think site
No, I don't think site builders can do the things you mention and so I'd agree that headless Drupal isn't that great from the perspective of site builders, but I don't see this approach as applying to them. I think the best outcome is to make it easy to decouple the frontend for those that want to develop a site this way while leaving in place the standard config for site builders or those that simply like the default.
John Hannah
Friendly Machine
Yes
I haven't yet seen anyone suggest removing any of the functionality you mentioned, only make it no longer required. So I think the short answer is yes. The longer answer: it depends what site she's working on and what choices were made in the development of that site.
Choices to do things in ways that bypass UI functionality (and limitations) are already made throughout Drupal. Queries built with EFQ can't be altered in the Views UI. Content updated via Feeds can't edited with node edit forms. Forms built with the forms API can't be adjusted with the Webform UI. Headless Drupal would be another option like this.