Helping Bloodwise beat blood cancer

Torchbox was recently approached by Bloodwise with the sort of project that doesn’t come along very often. Many clients come to us with an idea of what they want, and need our expertise to design and build it.

It’s a rather different problem to “we want a website”.

Now, this sort of project has its challenges. The chance to really work on something interesting from scratch is wonderful, but it requires a flexible approach when you don't have a clear idea what you’re going to build from the outset.

Bloodwise wanted Drupal. It’s a technology they use themselves and one they like. Drupal is great for building websites that deal with content. If you’re building a relatively traditional website with listings of teasers linking to pages, and those pages organised into categories, it’ll do 50% of the work for you. As a developer, you’ve just got to put the Lego together the right way and then spend time making it look pretty. However, Drupal isn’t so great a choice if you’re doing things with content that isn’t so traditional. You don’t want to paint yourself into a corner with what the site’s UI will let you do.

From experience, Drupal 7’s theme system can get in the way of simple tasks. Such as, moving something from one part of a page to another or subtly changing how something works. This is why it’s been radically overhauled for Drupal 8. If your project can’t wait for 8, and you need total flexibility right now, what can you do?

The approach we took was to treat Drupal as a data store and use something else to assemble the data and theme it. It’s a similar approach to the “Headless Drupal” method of putting a site together; Drupal’s paired with a JavaScript app written with something like AngularJS.

For our project, we’re pairing Drupal with a lightweight MVC app written using the Silex microframework. When a page is requested, the request goes to the Silex front end, which figures out what data it needs to fulfil the request. It asks Drupal for just the data, puts it in HTML templates and sends it back to the browser. Building the site this way gives us the freedom to build the markup and the structure of the site exactly how we want it, while also giving us Drupal’s powerful tools for managing content.

For templating, we’re using Twig, the templating system used by Drupal 8 and a popular open source project in its own right.

One of the concerns about building the site this way was performance. Silex by itself is really fast, as it doesn’t do much. Drupal can be tuned for pretty decent performance when serving a whole page. When it’s being used as a data store, and could be queried many times to assemble a page, its speed may start to become a factor. 

One of our solutions to this is Apache Solr, a popular open-source search engine. For this project, we used Solr as a back end for not only the site’s search, but also to power the listings on the site. Requests to Drupal from Silex come back in 100 to 200ms. Requests to Solr are usually in the range of 5 to 20ms. This means that for page loads when Drupal isn’t involved, we can load many listings incredibly fast.

So, is this the right approach for every project? Well, no. There’s a balancing act involved in choosing the technology for any project and certain factors will make building a site in this way more or less attractive. With that in mind, here’s some reasons why this approach might make sense (or not) for your project:

• You want total control over markup and site structure.

• You’re working on a team with designers and front-enders who understand Twig templates. (And this is more likely than you might think. They have a lot in common with the templates used in Django, for example)

• You want Drupal for content management, but other software in the mix too. While we’re just fetching data from Drupal and Solr on this build, you could use the same techniques to fetch data from or pass data to anything with an API for it.

• You don’t want to have to re-implement some basic features like logging in or out.

• You want to add Drupal modules in the future and have them “just work”.

• Drupal’s stock markup isn’t far from what you want anyway, or you have the time and skill on hand to re-theme Drupal’s output as required.

As for our project - at the time of writing, we’re mid-build, and on course to launch in a couple of months. We’ll blog again when it’s live!

If you'd like to find out more about the platform we're creating for Bloodwise, or want to chat about your exciting project, please get in touch. We'd love to hear from you.