Apr 29 2015
Apr 29

A Common Sense Guide to Headless Drupal

One of the major topics of discussion in the Drupal community has been decoupled (or headless) Drupal. Depending on who you ask, it’s either the best way to build break-through user experiences, or nothing short of a pandemic. But what exactly is a decoupled architecture?

A decoupled content store splits the content of a website from how it is displayed into multiple independent systems. Decoupled sites are the logical evolution of splitting content from templates in current CMSs. Decoupled architectures started to become mainstream with the publication of NPR’s Create Once, Publish Everywhere (COPE) series of articles. Other media organizations including Netflix have seen great benefits from a decoupled approach to content.

Like many other solutions in computer science, decoupling is simply adding a layer of technical abstraction between what content producers create and what content consumers see.

Approaching the release of Drupal 8, technical decision makers face an important choice. When an existing site is upgraded to Drupal 8, how do we decide if we should decouple the site or not? Before we decide to work on a decoupled implementation, it’s critical that everyone, from developers and project managers, to content editors and business leaders, understand what decoupling is and how to ensure a decoupled effort is worth the technical risk.

Why Decouple?

I’ve seen many people jump to the conclusion that decoupling will solve problems unrelated to a decoupled architecture. Decoupling doesn’t mean a website will have a cleaner content model or a responsive design. Those are separate (though relevant) solutions for separate problem sets.

These are the specific advantages of a decoupled architecture for a large organization:

  • Clean APIs for mobile apps: Since the website front-end is consuming the same APIs as mobile apps, app developers know that they aren’t a second-tier audience.
  • Independent upgrades: When the content API is decoupled from the front-end, the visual design of a website can be completely rebuilt without back-end changes. Likewise, the back-end systems can be rebuilt without requiring any front-end changes. This is a significant advantage in reducing the risk of replatforming projects, but requires strict attention to be paid to the design of the content APIs.
  • APIs can grow to multiple, independent consumers: New mobile apps can be created without requiring deep access to the back-end content stores. APIs can be documented and made available to third parties or the public at large with little effort.
  • Less reliance on Drupal specialists: Drupal is a unique system in that front-end developers need to have relatively deep understanding of the back-end architecture to be effective. By defining a clear line between back-end and front-end programming, we broaden our pool of potential developers.
  • Abstraction and constraints reduce individual responsibilities while promoting content reuse: Content producers are freed from needing to worry about exact presentation on every single front-end that consumes content. Style and layout tweaks are solely the responsibility of each front-end. Meanwhile, front-end developers can trust the semantics of content fields and the relationships between content as determined by the content experts themselves.

Here Be Dragons

At the beginning of a decoupled project, the implementation will seem simple and straight-forward. But don’t be fooled! Decoupled architectures enable flexibility at the cost of simplicity. They aren’t without risk.

  • One system becomes a web of systems: A decoupled architecture is more complex to understand and debug. Figuring out why something is broken isn’t just solving the bug, but sorting out whether the problem lies in the request or in the API itself.
  • Strict separation of concerns is required to gain tangible benefits: As front-end applications grow and change, care has to be taken to ensure that front-end display logic isn’t encoded in the API. Otherwise, decoupled systems can slowly create circular dependencies. This leads to systems with all of the overhead of a decoupled architecture and none of the benefits.
  • Drupal out-of-the-box functionality only works for the back-end: Many contributed modules provide pre-built functionality we rely on for Drupal site builds. For example, the Facebook module provides access to the Facebook API and to Facebook login widgets. In a decoupled architecture, this functionality must be rewritten. Site preview (or even authenticated viewing of content) has to be built from scratch in every front-end, instead of using the features we get for free with Drupal. Need UI localization? Get ready for some custom code. Drupal has solved a lot of problems over the course of its evolution so you don’t have to—unless you decouple.
  • The minimum team size is higher for efficient development: A Drupal site with a small development team is not a good candidate for decoupling unless content is feeding a large number of other applications. In general, decoupling allows larger teams to work concurrently and more efficiently, but doesn't reduce the total implementation effort.
  • Abstraction and constraints affect the whole business: The wider web publishing industry still has the legacy of the "webmaster". Editors are used to being able to tweak content with snippets of CSS or JavaScript. Product stakeholders often view products as a unified front-end and back-end, so getting the funding to invest in building excellent content APIs is an uphill battle. Post-launch support of decoupled products can lead to short-term fixes that are tightly coupled, negating the original investment in the first place.

The Heuristic

To help identify when decoupling is a good fit for a client, Lullabot uses the following guidelines.

Decoupled architectures may be appropriate when:

  1. The front-end teams require full freedom to structure and display the data.
  2. The front-end team does not have Drupal expertise.
  3. More than one content consumer (such as a website and multiple mobile apps) is live at the same time.
  4. Display front-ends combine data from multiple distinct API sources like CMSs, video management systems, and social media.
  5. A project consists of multiple development teams.

If a project meets some of these criteria, then we’ll begin a deep-dive into what decoupling would require.

  • Does decoupling also require a complete content rewrite, such as when migrating from legacy "full-page" CMS’s? We’ve encountered sites that haven’t made the move to structured data yet and still consist primarily of HTML “blobs.” This scenario presents a significant hurdle to decoupling, though it’s a separate problem from decoupling.
  • Does the development team have the time needed to build and document a content API with something like Apiary? Or is using Drupal as a site building (but coupled) development framework a better fit?
  • Does the web team consist primarily of Drupal developers, and will those developers continue to support the website in the future? Would the front-end team be better served by Views, Panels and the theme layer, or by a pure front-end solution like React or Angular?
  • Is there enough value in decoupling that the business is willing to change how they work to see it’s benefits?

Decoupled architectures are a great solution - but they’re not the only solution. Some of the best websites are built with a completely coupled Drupal implementation. It’s up to us as technical leaders and consultants to ensure we don’t let our excitement over an updated architecture get in between us and what a client truly needs.

Senior Drupal Architect

Want Andrew Berry to speak at your event? Contact us with the details and we’ll be in touch soon.

Access professional Drupal training at Drupalize.Me

A product of Lullabot, Drupalize.Me is a membership-based instructional video library. It can be supplemented with on-site training workshops, custom built for any organization.

Go to Drupalize.Me
Mar 04 2015
Mar 04

Learning to love the “touch-base”

One of the core skills of our client services team is the ability to communicate clearly, efficiently, and humanely to each other and to our clients. It’s this communication that gets us through gnarly project roadblocks and beyond the purely technical solutions. Unfortunately, this can lead to the dreaded wave of “calls”, “syncs”, “touch-bases”, and “meetings” which eat up our calendar hours.

As much as these terms can make our stomachs collectively turn, they are a critical component of the success of our projects. How do we turn this communication from something we avoid into something we look forward to?

Min-maxing participants and empowerment

The first step is to define the participants in a meeting. Each participant should be able to provide a unique perspective to the topic at hand. On many projects, there are multiple developers, designers, testers, and project managers, and in many cases only one person from each group is actually required for the weekly syncs.

It’s easy to default attendance to whoever has “senior”, or “lead”, or “manager” somewhere in their title. But in a balanced and capable team, it is often better to share the load of decision making among the greater team, especially as projects move on and individuals develop areas of expertise. In some cases, it can work well to simply round-robin participation from different subgroups. This helps to prevent one person from being overloaded with calls and meetings while giving the whole team a chance to drive the project direction.

A meeting should end up with a small group of individuals attending. I find it works best with no more than 4 people. Each person should have distinct contributions to make, and together the group should be empowered to make decisions. Sometimes discussion reveals further dependencies to resolutions, but ideally a meeting is a chance to show your team that you trust them and their expertise.

Action items and responsibilities

“What did we decide on the last call?” is one of the most frustrating ways for teams to start a meeting. Rehashing discussions and decisions leaves participants feeling like their time was wasted and that no progress was made. With a bit of guidance (typically from project managers), meetings can be made more effective with some documentation.

I find the best meeting notes are those that are distributed to the whole team and indexed, such as in an app like Basecamp or Google Groups. Each note should contain the participants, one-line summaries of the discussion, and action items at the end. Every action item should have a clear owner and notes of any dependencies, along with any external constraints. For example:

“Investigate why drush is broken.”

is significantly less useful than

“Angus will talk to the multifield maintainer on why drush updatedb broke on the last build. This needs to be fixed before Tuesday so we can do our next production deployment.”

Having action items and clear responsibilities documented solves a whole host of communication problems, while keeping the rest of the team up to date. Reading is so much faster than listening and speaking, so it allows the rest of the team to keep up to date without the same time commitment.

Iteration, Evaluation, and Communication

Standing meetings can be useful to force communication, but beyond daily standups, they should only be used as a last resort. Early in a project they can really help with architectural discovery, or in bootstrapping new teams. As time goes on, standing meetings can often become longer and have more and more people invited to them. It’s important to continually evaluate a meeting, and to willingly burn it to the ground to refocus and rebuild.

Every meeting participant should be empowered to call the existence of a meeting into question. When team members start grumbling about a recurring call, they should be able to discuss their feelings openly and honestly.

Just as we never stop aiming to make ourselves better developers, as teams we must never stop trying to improve and optimize our communication. By following these steps, your teams will be well on the path towards meeting nirvana.

Senior Drupal Architect

Want Andrew Berry to speak at your event? Contact us with the details and we’ll be in touch soon.

Nov 28 2012
Nov 28
Lullabot logo

Lullabot has trained thousands of Drupal developers & guided the development of some of the largest Drupal websites.

Nov 28 2012
Nov 28

In this lesson, we use the taxonomy that we have created for our videos to create a view of our videos, with an exposed filter that lets users limit the view by taxonomy terms.

Ooyala is a paid video delivery service, which manages your videos and handles video delivery to your site. You will need to have an Ooyala account in order to use this module on your Drupal site.

Nov 28 2012
Nov 28

In this lesson, Andrew will walk you through how to use Drupal taxonomy terms with your videos, and to also, importantly have that information synced with your videos in the Ooyala Backlot.

Ooyala is a paid video delivery service, which manages your videos and handles video delivery to your site. You will need to have an Ooyala account in order to use this module on your Drupal site.

Nov 28 2012
Nov 28

Ooyala is a paid video delivery service, which manages your videos and handles video delivery to your site. With the Ooyala module you can connect the Ooyala service to your Drupal site to display and play your Ooyala videos from within Drupal. This lesson will walk you through the modules that are needed, and how to configure them to work properly. We will create a new content type for our videos, and configure the Ooyala field using the Ooyala uploader. We also cover adding custom meta data to your video.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web