Decoupled Days 2019

Decoupled Days

Decoupled Days 2019 last month, the third edition of the conference, was fantastic. I had the privilege to speak and attend last year, as well. The conference has quickly risen to be one of my favorite conference of the year.

Not familiar with Decoupled Days? Spawned in the “Hallway Track” of DrupalCon between its founders, the conference originated as Decoupled Drupal Days in 2017. Last year saw the phasing out of the word “Drupal” as the conference became focused on decoupling in general, not just Drupal. That is one reason it has quickly become a favorite event. It is an engineering and design conference. The act of decoupling in a system requires specific system design and presents engineering challenges. The organizers identify it as:

The only conference on the future of CMS, headless CMS, and decoupled CMS.

It’s not just about Drupal. Moreover, it’s not about abandoning Drupal. It is about using the correct tooling for the exact problem and how do our previous paradigms fit into this new architecture. One of the most exciting concepts discussed throughout the sessions was the shift of “where Drupal lives in the architecture stack.” Oh, and of course the exciting “battle” between GraphQL and RESTful APIs; more precisely for the event, the JSON API specification.


One identifiable topic at the conference was GraphQL. Facebook created the GraphQL specification, and the GraphQL Foundation now manages the specification. It has also grown in popularity thanks to venture-capital based companies like Apollo which have built server and client tooling around GraphQL. 

There were no JSON API specific sessions at the conference, but the JSON API maintainers were in attendance to listen and take in information rather than speak.

One of the most significant conversation pieces about GraphQL is that it isn’t a RESTful API interface. GraphQL is a query-like language that allows you to pass queries or mutations (non-read operations) as a GET or POST to the GraphQL endpoint. Each GraphQL server has its schema that maps to the backend data storage.

I enjoyed having many conversations about the different use cases for GraphQL and JSON API. I feel that GraphQL is a perfect fit to get up and running with a read-only API that requires a specially designed schema created by the consumer side. After that, when an API requires manipulation of data, or you don’t want to define the API schema, JSON API comes out on top. Again, it comes down to preference and proper tooling for the project.

After my Delivering Headless Commerce session, I was able to sit down with Mateu Aguiló BoschWim LeersGabe Sulliceand others to discuss the Drupal JSON API implementation. One of the biggest takeaways from that conversation is the plan forward to provide cross-bundle entity collections. The JSON API Cross Bundles module is being developed to sandbox feature development and eventually move support into Drupal core once an evaluated. 

Decoupled architectures in practice

I made it to two sessions which covered decoupled architectures that placed Drupal in a different position of the architecture stack.

Dominic Laylock from Mentrix discussed how the Economist scaled their content platform using an event-driven decoupled architecture. Drupal had become the monolithic centerpiece of the platform. With growing multichannel requirements, the Economist revised to an event-driven and microservice architecture. Drupal moved to the background, and its content pushed out, treating it as a content source like other items in their stack. Data is taken from Drupal and processed into a canonical data source based on by workers and pushed into their content store. All consumers access content through a GraphQL endpoint that only accesses the content store. The session page:

Mateu Aguiló Bosch’s session focused on the importance of using a proxy in front of your Drupal API server. Mateu’s main argument was that your API proxy should be a Node.js server. In all reality, the proxy could be replaced by any service which handles concurrent requests and allows routing between different backend services. Many cloud providers offer API gateways, or you could write on in Golang or ReactPHP. The benefit of using Node.js? A Node.js server can execute server-side rendering for modern JavaScript frameworks. Server-side rendering improves your JavaScript application’s SEO and accessibility by rendering HTML on the server and not the client — like a standard server-side application. Here is a link to the session for when videos are available:

Decoupled: 3 years of hosting and building

Michael Schmid of Amazee discussed their history of the building and hosting decoupled architectures — which spawned the creation of the hosting company. Amazee Labs is the agency leading the development of the GraphQL server spec in Drupal. It was interesting to learn that the development and training were leveraged through client work, much like Centarro with Drupal Commerce. Here is a link to the session for when videos are available:

Delivering Headless Commerce

On Thursday, I gave my Delivering Headless Commerce session. Centarro has been developing API-First improvements for Drupal Commerce, alongside features such as Addressbook, Pricelists, and Invoices. The presentation covered the available API integration options in Drupal and how to build consumers for a headless Drupal Commerce site. Both GraphQL and JSON:API have their benefits and challenges when implementing headless eCommerce. The slides go into depth on using either technology for the various components that go into a headless Drupal Commerce build. I discuss improvements we have made and our current development status to improve the API capabilities of Drupal Commerce.


You can also catch my talk again at the Drupal Chicago meetup on August 7th:

Add new comment