It doesn’t have to be complicated.
At the 2017 Pacific Northwest Drupal Summit, our developer Trent Stromkins demonstrated how you can create a functioning decoupled web app in only 25 hours of coding time using Drupal 8 and Ember. You can watch Trent’s full talk and slideshow below, or if you don’t have an hour scroll down for the key details.
Trent was out to prove you can build a working app in only a bit of spare time with no custom coding and no special expertise.
Total project time: twenty-six days from start to finish.
Total coding time: twenty-five hours.
We’re all about Drupal at North Studio and, while it may not be the best for building a real-world application, it’s a great way to prototype your ideas.
We’ll also need a few contributing modules:
Sure, we could do everything through configuration management, but a UI gives us simplicity and speed.
It’s important to remember that the JSON API is not the same thing as Drupal JSON. The JSON API is a specification structure that allows any front-end framework that understands it to use your outputs. That means you don’t have to control anything coming out of Drupal with custom coding magic.
This mechanism allows you to control your cross-origin resources, and deal with cross-scripting problems.
Finally, Trent used a few Ember add-ons to connect with Drupal: ember-data, ember-moment, ember-data-drupal, and ember-local-storage.
Keep a close eye on ember-data-drupal, since that’s the add-on Trent needed to deal with Drupal’s messy naming conventions.
The app has five basic content types: chat, date, room, session and user session:
Trent kept everything simple, and stuck to basic relationships we’re used to seeing in Drupal. Level and track here are taxonomies, and room is a node. Here’s a look inside session:
Here’s a look one layer down at room:
The JSON API will give you standard structured data for room, session, and your other content types.
Now let’s look at Ember. Remember, our goal here is to get our application out of Drupal and into Ember without a lot of work. Simplicity is key. To do that, we use models, so our build ends up in Ember looking like this:
The data is not as controlled as it might be in other APIs, so we specify the reverse field using a bi-directional reference, like this:
Ember is a route driven framework. Components can have data, but everything ends up in the URL structure. Once we’ve loaded the data into the actual index template, it looks something like this:
Trent ran into a few hiccups trying to write such a pared-down app.
Unlike JSON, Drupal doesn’t give a time zone stamp, but assumes times to be in UTC. To avoid any custom coding the point of this exercise Trent just used UTC as if it were the right time. Ideally, the data would come out with a time zone marker.
Trent found himself stumped trying to make authentication work with JSON web tokens on a short time budget. Instead, he sidestepped the problem by using local storage. Could we have used the Drupal Flag module? Sure. But Trent wanted to keep his thin, pure-HTML, 2.8 MB package as slim as possible.
Dealing with naming conventions between Drupal and Ember was a headache for Trent, but also showed off one of Ember’s strengths. When he couldn’t figure out how to strip and reserialize his data without messing up how Ember handles relationships, he went to the Ember community for help. Sure enough, someone had already built a solution for just that problem: the ember-data-drupal module.
And that’s why we use open-source software.
So why do it?