How to build a working Drupal 8 app in 25 hours

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.  

The Mission

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.

By deadline, Trent created this session scheduling app for the Drupal Summit. You can check out the original code at GitHub here and here.

Screenshot of app
And here's what it looks like. 

The Tools

Drupal 8

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.


You can essentially write in plain HTML in this JavaScript framework, and, like Drupal, it benefits from a vibrant open-source community (unlike the Facebook and Google driven Angular and React).

Key elements
Here’s a look at the key elements of Drupal and Ember that Trent brought into this project.

We’ll also need a few contributing modules:

Rest UI

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

The app has five basic content types: chat, date, room, session and user session:

Basic content types

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:

Session tree

Here’s a look one layer down at room:

Room tree

The JSON API will give you standard structured data for roomsession, 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:

Ember models

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:

Inverse references

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:

Index template

The problems

Trent ran into a few hiccups trying to write such a pared-down app.

Time zones

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.

Naming conventions

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?

Sometimes, Trent says, you just want to show a functional prototype to a client. A bare bones mock-up using Drupal and Ember puts a working model on the table in a matter of weeks. Anyone with a little Drupal, JavaScript and CSS experience can do it, no manual required. Perhaps the final product will use a different framework, but a simple application like this one can be the first step to something bigger and better.