Summary of the Backbone.js BoF at DrupalPrague

On September 25, 2013, I lead a Birds of a Feather session at DrupalCon about the use of Backbone.js with Drupal.

We have raw notes from the discussion.

This is a summary of those raw notes.

Goal of the BoF

Solicit input from developers, project managers and business owners regarding their intended use of Backbone with Drupal. Shape the plan of the Backbone module based on this input.

Questions

How do you currently use Backbone.js with Drupal?

Very few individuals in the session were familiar with the REST module in Drupal 7. Use of Backbone.js with Drupal 7 seems limited to calling up nodes for display.

What challenges do you face using Backbone.js with Drupal

Set up of the REST module in Drupal 7 is painful and rarely succeeds.

Rendering forms with Backbone.js is difficult because of verification.

There exists no standard caching strategy for client-side rendered content within Drupal or Contrib.

When a site is rendered completely in a client, search bots are left with nothing to index.

Templates defined on the server side cannot be easily shared to the client side, because the data variables need to plug into those templates must be defined through the Render API.

What solutions do we have?

Setting up REST module

REST module is now included in Drupal 8 core, with a HAL JSON serializer module as well. The field and property data of any entity cane be requested and altered through a standard REST call.

Extend the Backbone Module to provide an API for common tasks

We assembled the following list of what the Backbone module might provide.

1. An API to get and post any entity in the standard installation
2. An API to get and post individual blocks
3. Client-side template caching
4. Deal with forms, required fields and validation

Template duplication

This is a tough one. We will be able to reuse server-side TWIG templates when we can (1) determine the correct template to apply given a route, user, permissions, etc., and (2) format a data object with keys that correspond to the placeholders in the template and pass that data to a client.

The day of the BoF, I was a little worried about the complexity and vagueness of this problem. I then wondered into c4rl's session The history & future of Drupal theming. I saw a possible solution. c4rl wants to make refactor the Render API into a service that can return either render content, or the data associated with a template. If we can ensure that the Render API plays well with REST, we might be able to create addressable page sections that return data and links to template resources for that data.

For instance, imagine requesting Sidebar A at the following URL:

http://example.com/node/1/page/region_sidebar_a

Or even a block in Sidebar A:

http://example.com/node/1/page/region_sidebar_a/block_recent_comments

The response would contain a JSON object like this:

Dealing with SEO in a Single Page Application

In 2009, Twitter built the first high-profile single page application using the #! character. With this effort, they degraded the performance of their site and not hyperbolically broke the web. Suddenly, individual tweets and user profiles no longer had stable, unique URLs; they had the same domain URL with a hash value that informed the app how to respond.

I know of two approaches that one can to ensure that a crawler -- or any user agent that does not evaluate JavaScript -- will get a page of HTML to consume.

The first is pre-rendering. This involves detecting user agents on the server and providing a pre-rendered page to that agent. Honestly, I find this method brittle, duplicative and a little black hat SEO.

The second approach is providing a configuration that would serve pages with nothing but content objects. So node/1 would return a simple html page with just the semantic content of the node. The rest of the page would be filled in through client-side requests for regions/blocks. After the initial page load, the ancillary assets (regions and blocks) could be cached locally so subsequent requests for content simply replace the main node on the page without calling a rerender on anything else in the page.

I'm confident we can hack together the second approach in Contrib and prove it out.

If you would like to participate, please visit the Backbone module issue queue!