Introducing Saucier

With the first party API building tools built into Drupal 8 core, there’s been a lot of talk about building semantic APIs in Drupal; when, how, and why you should or should not. However, a commonly overlooked piece of this picture is how to go about actually consuming these APIs. As it turns out, consuming an API, even a well designed one, can present a number of challenges.

Four Kitchens realized this when working with TWiT.tv to launch their new website and public API. TWiT.tv is one of the oldest and largest podcasting networks, with a loyal and active developer community who have created a number of applications and websites using TWiT.tv data. The new TWiT.tv website is powered by Drupal and provides both a public and private API using the RESTful module.

The private API is consumed internally by a Node.js application, which takes the data from the API and turns it into the TWiT.tv web pages. During the process of building this Node.js application, we identified a number of components that would most likely be needed by any Node.js application consuming a Drupal API, so we created a Node.js framework that contains these components. This framework is called Saucier.

What does Saucier do?

Saucier provides a collection of tools, organized in a boilerplate folder structure to make it easy to get started building your Node.js Drupal-consuming website. It provides routing, authentication, templating, and caching layers that make it straight forward to create a route that returns data from a Drupal API.

Routing and templating

Using Saucier, one can define a route, and tell that route what endpoints it needs to call to gather the data necessary to render the route using a template. Saucier will then authenticate with Drupal, load the data, pass it to the template for rendering, and then retu\r\n \the template’s output to the browser. The templates are written in Dust.js, an asynchronous templating engine that allows for rendering on the client or server side. This means our pages are sent as plain HTML, and when necessary, we can use the same templates to update the content client-side. This approach is much more performant than a completely client-side solution such as Angular consuming a Drupal API.

Caching

A common problem with consuming a Drupal API is caching. You don’t want to call the Drupal API for every request. That would create a bunch of unnecessary load on Drupal, since much of the data may not change frequently. Instead, you should cache data from Drupal so that you can render your webpages without bombarding and potentially overloading Drupal. Saucier provides a cache layer for routes that does exactly this, using Redis to store the non-persistent cached data. When a route is visited, Saucier will check to see if the data needed by that route is in the cache. If it is, the route will use the cached data to continue rendering the page. If the data isn’t in the cache, or has expired, Saucier will ask Drupal for the data, cache the results, and then render the page.

Try it!

These tools made it easier for us to consume Drupal-based APIs in a custom Node.js app, and we hope that others find Saucier to be a useful addition to their toolbox.

Four Kitchens is actively working on Saucier. Suggestions and contributions are welcome, so feel free to fork the Github project and hack away!

View Saucier on GitHub