Tablet APIs with Symfony & Drupal

Tags: Tech Blog Published:

Solving problems It's for good reason that our company blurb describes us as "a UK digital agency who solve problems, build solutions and support you" rather than just "Drupal website builders". It's rare these days that the problems that we solve for our customers fit neatly inside the confines of the content management system (CMS) alone. There are often parts of the overall solution that go well beyond the website. For some clients it can be a need to integrate data into the CMS from other business systems, or to push data out into other systems such as customer relationship management (CRM) applications.

As you'd expect - one of the most common areas we talk about with our clients is their strategy for tablet & mobile. For many clients, a well made responsive website is everything that's needed - it enables users to interact with the business smoothly no matter what device they're on, and gives the business a single, central channel of content to manage.

Modern responsive websites can even take advantage of features such as geolocation, and camera interation that were traditionally app-only territory - making even interactive sites achievable without developing separate apps.

The case for "apps"

However there are still plenty of occasions where we come up with  requirements where mobile or tablet apps are the right solution. There can be many reasons for that:

  • the app experience needs to be significantly different from the web experience
  • non-web features such as in-app purchasing are needed
  • a desire to have the app work well offline

However, many of these apps aren't just standalone - they need to interact with clients' existing website data, to pull in content, or to integrate with CRM features and data.

Traditional integration options

Simple solutions can involve using web-view wrappers to simply make standard (responsive) web pages available within the app. This is a nice simple choice where there is a desire to "have an app" - or where there are a layer of app features wrapped around the web content. However - the app is more or less limited to displaying pages as-is - so the site itself needs to be designed with that in mind. Typically users also need to be online to access the website content.

Alternatively, Drupal's Services infrastructure is a popular way to provide external systems access to Drupal's CMS content in a structured way that apps can consume. Apps can then display the content as they wish, and can store it for offline use. This is a good solution for many sites - especially if there is a clear match between the way the site structures content and the way that the app wants to consume it.

Other options

However we've recently worked on a few implementations that made us consider alternative approaches. These implementations:

  • dealt with large volumes of frequently changing content
  • had complex access requirements - not closely aligned to the way content was structured on the site
  • needed to be able to "sync" quickly when online to grab all content for later offline use

There were two main reasons we avoided Drupal's Services layer:

  • it would have been a significant effort to make it map the content together correctly in a way that was efficient for the app to fetch
  • it would have been a lot heavier to operate efficiently for large volumes of requests - partly down to the complexity of the sites in question

As an alternative we built a lightweight API using the Symfony components. This sits alongside Drupal and accesses the data it needs directly.

API Diagram

The main advantages of this approach are:

  • we're not constrained with how we access data - we're building the content retrieval in exactly the way we need without having to adapt something else
  • the API service is very light - using only minimal resources since it doesn't have to do a full Drupal bootstrap
  • it can be hosted and scaled independently of the website if needs be

There are a couple of gotchas along the way - particularly where the data you are serving relies on Drupal's processing of the data, not just the raw data. So, before you consider this as an approach it's worth thinking about:

  • do I need Drupal to process the data for me? (the obvious example is image URLs which Drupal tokenizes when it generates them)
  • will the app just read data - or does it need to add or update data as well?
  • how closely does my app data access match my online model?


If you need a little help when it comes to thinking outside the box in order to find your perfect solution, we're all ears - we love a challenge, so get in touch.

Equally, if you'd like to join a team that pushes the limits and enjoy building solutions that make a difference, you might like to find out more about our vacancies.