Reflections on Symfony Live London 2014

At the end of September, I went to my first “non-Drupal” PHP event,
Symfony Live London 2014. With Symfony components
becoming a large part of Drupal 8 it was an excellent opportunity to learn a bit about
what it all means, and meet the Symfony community. I’ve dabbled with Drupal 8,
and we use some Symfony components in our existing Drupal 6 and 7 projects, so I
wasn’t coming in completely cold.

The Naked Bundle

Top among these presentations for me though, was The Naked Bundle
presented by Matthias Noback. Matthias focused on how the bundle (Symfony’s equivalent
of a module) could be stripped back to the minimum Symfony specific code, and merely
act as a bridge between the framework and your business logic (which, he asserted,
has no place belonging in a framework specific implementation, and should be in
its own standalone, interoperable library).

The short summary of The Naked Bundle was the premise that it should be easy to take
your business logic and expose it to a Symfony bundle, a Laravel package, a Drupal
module - it’s all PHP after all. Rather than repeat the talk here, I’ll direct you to
the excellent slides
describing a number of approaches to meet this goal.

Drupal modules

The concept of a Naked Bundle has some direct relevancy for the Drupal world. We’re
in the middle of the Drupal 7 lifecycle, many of us still supporting or evolving
Drupal 6 sites, and most of us looking forward to Drupal 8 and the changes that it
will bring to the Drupal ecosystem. It’s therefore not unreasonable that a large number
of Drupal developers are building functionality which may be in use on three versions of Drupal,
or maybe more, not to mention the liklihood of Drupal developers looking at
other solutions for some sites, whether it be Symfony, Laravel or something different.

The Naked Module?

So then, is the Naked Module a concept worth considering? Why not move as much
business logic as possible into interoperable PHP libraries which get pulled into
Drupal via a bridge module? There’s obviously a fine line to tread in ensuring
you don’t throw out all the benefits of Drupal’s core and contrib functionality, but
if building something specific to your domain then there’s a lot to be said for
this approach:

Portability - PHP libraries are more easily moved between Drupal versions, or to
other frameworks altogether. Migrating functionality from one version of Drupal to another
therefore becomes much less of an issue, as your custom code is now less coupled to
specific versions.

Testability - a standalone PHP library is more easily unit testable, regardless of
whether it’s going to be used in Drupal or not.

How?

In projects at Capgemini, we’re already using several approaches which lets us get
some way towards this concept:

Writing domain specific logic in standalone libraries, for example, code to handle
creation, validation and manipulation of business objects implemented in PHP classes,
and called out to from Drupal hooks

Integrating with internal or external remote services via a service wrapper which can again
be called from within the Drupal module

Using the Composer Manager to
include these PHP libraries in our Drupal installations so that they can be managed separately to
site or module repositories

Using a shared ORM and DBAL such as Doctrine to access custom database objects consistently
regardless of Drupal version or framework, particularly when they don’t need to be
Entities

Most, if not all, of these approaches are already in use in the community, for example Commerce Guys
recently released a generic PHP addressing library
to handle creating, manipulating and formatting postal addresses for shipping or billing
across different countries. Providing this as a generic library rather than hiding it in a
Drupal module means the support for this logic can benefit the entire PHP community.

Libraries first

As Matthias stated in his Naked Bundle talk, it’s only sensible to seek practical
reusability. In the case of Symfony bundles an example of an allowed dependency would be
the HTTPFoundation classes and trusting the HTTPKernel.

In Drupal, we’d want to take advantage of existing hooks, and well defined, well tested APIs
rather than re-inventing things. However, with a libraries first approach, modules can be
made smaller, slimmer, avoid framework specific conventions and dependencies,
and simply expose resources to add rich domain specific functionality for easier
porting to other versions or frameworks.