Help Starting a Headless Drupal System

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
tony.stecca@virtualhighschool.com's picture

Hi,

my name is Tony. I work for a large online high school. We deliver all of our content as static HTML pages via a learning management system.

We are currently designing a new content and content delivery system and are interested in using JSON objects to represent our pages drupal to store the objects. After some research it appears that this approach is already in use by some organizations and is called headless drupal.

Is this the appropriate place to ask questions about our project? For starters, I'd like to know people are handling the encoding of their content in JSON and then how to save this JSON object as a drupal node.

FYI, we have at least one capable PHP programmer in our organization and we are planning on pursuing a programmatic approach with the API. That is, I'm not just looking for a contributed module that works out of the book. I understand that we may need to write a custom module.

Thanks in advance for the help.

Tony

Comments

I think Drupal could

technicalknockout's picture

I think Drupal could definitely be a good fit for your project. I've used Drupal to store content and serve as JSON data for other systems before. Drupal 8 handles this out of the box and the Drupal API has a lot of options for adding custom functionality. There are also contributed modules, like Rules, that allow you to create custom functionality through the admin dashboard.

I would only warn you about is the difficulty in learning and using Drupal itself, if you are new to Drupal. A lot of people find it challenging to learn, it really depends on your experience and your expectations. Also, Drupal 8 has a lot of changes from Drupal 7, so be careful evaluating between the two. Drupal 8 has more advanced features and improvements from 7, but the community around 7 is much more mature in terms of available knowledge online and contributed modules/plugins.

"Drupal 8 handles this out of

RobKoberg's picture

"Drupal 8 handles this out of the box" - no, it really doesn't. It provides some basic support for content nodes, but not their relationships (like images, terms, other entities). I recently tried to work with D8, but contrib/core modules like migrate are underwhelming and don't really work as expected. It seems several "fixes" and breaking changes are in D8.2, but only D8.1 is released, so what do contrib module authors do? I have been following this group and drupal in general and wondering if most people have abandoned D8. (I have moved to nodejs for the most part)

Can't you fill in the data

technicalknockout's picture

Can't you fill in the data for images, terms, and other entities using views? Which is also in core in D8.

The module still needs to be

Greg Boggs's picture

The module still needs to be ported:

https://www.drupal.org/node/2621558

Is it really needed in 8?

technicalknockout's picture

Is it really needed in 8? There's the REST export display type:

https://drupalize.me/blog/201402/your-first-restful-view-drupal-8

Agreed

tyler.frankenstein's picture

As much as I love Views Datasource for D7, I also think it is no longer needed in D8, since exposing Views as JSON data is now possible with D8 core REST export display.

As for getting JSON data in and out of Drupal, I use/maintain jDrupal and Services for D7, and use/maintain jDrupal and use core REST for D8.

If you want to do something

Greg Boggs's picture

If you want to do something like have translated content output in JSON, then you're going to need something with more features than what's built into core so far. I believe the plan for core rest is to expand it over time. It may have more features than the last time I tested it.

The rate of my contrib

Greg Boggs's picture

The rate of my contrib modules adoption for Drupal 8 has been increasing 300% week by week. At this point, it looks like Drupal 8 is going to be bigger than Drupal 7 as we have expected.

As for core REST, core REST is designed as a no frills REST solution. It's pretty solid, and there are still robust json solutions in contrib if you need more than what core REST can provide.

As you mentioned, migrate is an experimental module still, and not yet perfect.

Let's focus on the needs of the original poster.

markconroy's picture

Hi folks,

Rather than get into the states of RESTful in D8 or otherwise, let's ask the OP what he wants to achieve specifically?

When we know that, we can tell him if D8 (or D7 + contrib) is the right solution (or if Drupal itself is not the right solution).

Sorry for popping in in an interventionary manner, but I think it's important when a new member seeks assistance that we focus on their needs instead of the present state of Drupal.

Respectfully,
Mark.

Glad to see this is an active

tony.stecca@virtualhighschool.com's picture

Glad to see this is an active discussion board. Thanks for the input.

I'll lay out a bit more of the plan. We have Drupal 8 installed and have we're hoping to stick with for the user management, content versioning, and other CMS features.

After that though, we're planning on writing a custom page-builder module using http://innovastudio.com/content-builder.aspx . This module would create a JSON representation of the page and then save it to a Drupal Node. We are new to Drupal so we'll have to figure out the API for this. Can you recommend a method for saving the JSON object as a Drupal Node?

Glad to see this is an active

tony.stecca@virtualhighschool.com's picture

Glad to see this is an active discussion board. Thanks for the input.

I'll lay out a bit more of the plan. We have Drupal 8 installed and have we're hoping to stick with for the user management, content versioning, and other CMS features.

After that though, we're planning on writing a custom page-builder module using http://innovastudio.com/content-builder.aspx . This module would create a JSON representation of the page and then save it to a Drupal Node. We are new to Drupal so we'll have to figure out the API for this. Can you recommend a method for saving the JSON object as a Drupal Node?

Generate JSON as needed.

GrandmaGlassesRopeMan's picture

@tstecca

Why not just generate the JSON as needed? Core REST will generate a JSON object for each of your requested nodes as needed.

drpal, in our early tests

tony.stecca@virtualhighschool.com's picture

drpal, in our early tests we've been able to retrieve the JSON view of a node using the REST api and JSON view. This is working well. Although the data in the body is currently limited mark-up HTML. In our proposed model the body content would be a JSON model of the page content.

I'll give some more information about our project. In our school we have around 70, 000 course pages split among hundreds of courses. All of our pages are static HTML pages. We envision migrating our pages to this JSON model, stored in Drupal, over several years. You can see some of our content pages if you visit our website, virtualhighschool.com, and click Start Demo.

We have dozens of different page elements that our instructional designers use to build the pages: exercise boxes, strategies boxes, notes, etc. In the new model our pages would be an array of JSON objects. You can see below how these page elements might be stored. The intent of this is that our content becomes separated from the markup.

{
type: "paragraph",
content: "Remember, once we have more than 12 sides, we often refer to polygons as n-gons. In order to determine the sum of all of the angles in an n-gon, we can use the following formula."
}

{ type: "box",
role: "exercise",
subrole: "tryItOnYourOwn",
version: 0.9,
title: "Exercise: Matching",
instructions: "Categorize the movements into the correct plane in which they take place.",
disallow: ["notes", "accordian", "image"],
content: "A bunch of HTML."
}

Assuming that our custom page editor outputs an effective JSON model of the page, what is the best way to same this model as a node? Thanks again for all comments.

T

Have you seen

RobKoberg's picture

Have you seen https://firebase.google.com/ ? - that might meet your needs and it is pretty simple to use with any front end. The problem with D8 is you have to work to get JSON (unless everything can be self contained in simple value fields on a node). In your example content above:

  • would type, role ,and/or subrole be a reference to a term? If so, you will need to work to bring that into the JSON result
  • is version based off a reference to some entity? You will need to work
  • would content like that above ever have an image type property? You will need to work

It is not difficult, especially with views, but it is not out of the box. Though why this needs to occur is beyond me.

Another thing, at least this was the case with D7 and probably still the case, is that you tend to need to do a full bootstrap of drupal, including the theme layer, to get modules to provide JSON results. I could be wrong on this with regard to D8.

From what you have shared

tripper54's picture

From what you have shared about your project, I honestly don't think Drupal is a good fit. Drupal's strength is its highly opinionated field and entity APIs. They allow for flexible content modeling at a business level.

But by the sounds of it you already have a very well developed data schema, and you just need some way to store and retrieve that data via an API of some kind (REST or GraphQL I guess).

IMO a lower level framework would be more appropriate. If your developers are most comfortable with PHP, I'd look at Laravel. Otherwise node.js might be the way to go.

As you're storing JSON objects, a document based DB like Mongo might be most appropriate. It depends on the relationships between your data objects and what kind of queries you would be running on them.

If you're sold on Drupal, I'm sure you can make it work. But if it was my brief I'd look elsewhere.

I agree based on the example

technicalknockout's picture

I agree based on the example data, Drupal does not seem like the most natural fit. It could be done, but doesn't sound like it would be leveraging its strengths and maybe even shoehorning this data into Drupal's data/fields models. It sounds to me more like a natural fit would be another framework (or maybe even no framework) that is designed around JSON objects/records.

tripper and tko, we are not

tony.stecca@virtualhighschool.com's picture

tripper and tko,

we are not hooked on Drupal yet. We're planning on keeping out proprietary JSON content model because our content is so unique. We're also expecting RESTful, client side rendering of the JSON model, and a custom drag-and-drop builder for the JSON model. None of this requires drupal and we would definitely have to extend it to make it.

What we're hoping to get our of Drupal are other CMS aspects, particularly content versioning and user management. We'd like to avoid building these aspects of a CMS. Do you think this is reasonable?

BTW, won't be back till after the weekend. Thanks for the help, looking forward to continuing the discussion.

I guess the devil is in the

tripper54's picture

I guess the devil is in the details: break your required user management and content versioning requirements into user stories. Then compare how Drupal will meet those requirements, compared to the time & effort required to implement those features in a lower level framework.

My inclination is that Drupal would end up not being a good fit. User management and content versioning are not rocket science to implement (depending on the exact requirements). Both are very common features that could be provided by framework libraries, or framework agnostic libraries.

But I'd be convinced either way by a thorough analysis.

Headless Drupal

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week