September 1st, 2017

“Decoupled Drupal” is the Drupal community’s buzzword of 2017. There’s lots of blog posts about why you would want it (basically, in the same cases where you would want Service Oriented Architecture), just like there are myriad posts about why you should switch to microservices/etc., but I wanted to see how hard it would be to actually build a really basic JavaScript frontend for interacting with a Drupal backend.

Turns out it’s actually a bit harder than I thought it would be, mostly for security reasons. The OAuth workflow isn’t too complicated once you’ve done it before, which I have, for making calls to REST APIs like Reddit, Spotify, that kind of thing.

There are probably a lot of ways to actually implement a headless Drupal backend. The only one I really know to use, though, is Reservoir.

Here are the steps to duplicate what I did, so you can poke around:

Follow the Reservoir repo’s README.md to install a basic reservoir app using composer. Follow the Quick Start Guide to set up your OAuth keys, roles, clients, and users, and to make some basic requests with Postman. Clone my repository into your docroot folder, put your client ID and client secret into index.html towards the bottom of the file, and navigate to http://localhost/app.

It’s essentially a JavaScript attempt to do what the Quick Start Guide does in Postman — authenticate a user, and list/create/delete articles.

You’ll notice that when your auth token expires, my application does not refresh it. I’ve opened an issue in Reservoir’s GitHub repo about it. (I freely admit this is due to my own OAuth ignorance.)

You would also never want to:

store your client ID and client secret in your JS source code

store both your access token and refresh token in browser cookies

And I did both of those things, in this case. It’s a proof of concept, not a production solution 🙂

What’s your experience with decoupled Drupal? Send me an email or write a comment with your thoughts!