Decoupling Concerns

How to use the same data source across multiple channels (website, mobile app, info screens and more) and keeping it maintainable? One way would be to separate it into a module which offers everything from a REST interface to custom feeds… but this quite quickly becomes unmaintainable with a few 2000 lines of .module files.

We want to separate the handling of the data source & associated logic to a system that specializes in handling this, meaning we are completely skipping Drupal when interacting with the REST api for both mobile apps and info screens. Another benefit to this approach is it allows us to centralize the business logic on the Silex platform so it applies to all channels using it.

In the presentation I will touch on the subjects of:

• What is Silex and why you should use it as well!
• How content can be enriched in a decoupled fashion!
• Why it makes sense to have a proxy layer between Drupal and a third-party web service.
• How to use queues in Drupal when talking with a third-party service.
• How to fetch this data from a Drupal website using CTools.

The result being a decoupled architecture where concerns of content creation / enrichment is separated from the rendering. The other “side” effect of this is your business logic is now neatly packaged and ready to be used in any Symfony, Drupal 8 or similar project in the future or at least with a minimal of changes.

We have at Adapt used this approach to implement a REST api that partially acts as a proxy that validates/transforms request proxied to a third party SOAP service while still allowing content to be created and mangled together with data from the SOAP service.

Why are we not yet using Drupal 8 for this? – quick answer: D8 is not mature enough for production yet.

Some of the technics that is being demostated in this presentation was originally inspired by "A Decoupled Drupal with Silex" talk that Larry "Crell" Garfield & Hagen Last held at Drupalcon in Amsterdam.