Headless Wordpress/Drupal is galloping into view with Sleepy Hollow references tagging along for the ride

By: ; Date: 2015-12-16 11:31

Tags: Wordpress » Drupal Themes » Drupal

Headless Wordpress is becoming a thing, now that Wordpress 4.4 has been released and has some core support for a REST API. The Drupal world has seen Headless Drupal work for a couple years now, and the Wordpress community has seen the light as well. The advantages of decoupling the website rendering from content management are many, the biggest perhaps being the rapidly changing best practices landscape for delivering content to the display device. The capabilities at the client end are rapidly morphing, much more quickly than the release cycles of the content management systems.

Yesterday, Pantheon held a Webinar about Headless Wordpress .. so here's a few thoughts and notes. I'm excited by the possibilities but disagree with some of the policies being developed.

Foundational understanding -- what the heck are we talking about: Headless What?

Are we talking about Ichabod Crane and the Headless Horseman? Nope. Headless Wordpress/Drupal is to split away the website rendering task from the rest of the system. You'd have your preferred content management system to store the content. The rendering layer would then access that content via an API. And it's feasible to have multiple rendering layers for different delivery destinations -- render the content one way for Google AMP, another way for Facebook, another way for desktop browsers, another for mobile, etc.

To generalize the concept a bit, what about switching from a monolithic system to one built up from microservices? The microservice architecture is all the rage nowadays, but it's not just a cool buzzword. A system built from microservices should be more scalable - just increase/decrease resources on the service that needs it. But more importantly each microservice will be more maintainable. A small service with a well defined API can be easily coded/tested by a small team, and its feature-set can be iterated independently of other microservices so long as it maintains API compatibility. Building a large service from several microservices means the whole system should be easier to maintain, and features can be iteratably added in an organic fashion.

By contrast the current popular content management systems (Wordpress, Drupal) are big monoliths. How long did the Drupal 8 development cycle take? How long before the bulk of Drupal websites will migrate to Drupal 8? And, more importantly, the architecture of both Drupal and Wordpress are what you'd call a monolith that supports plugins to extend capabilities.

One downloads a Wordpress or Drupal distribution from the central website, and poof in a few minutes you have a website. That has user experience advantages in setting up sites, but what's the long term cost? The whole system is more rigid than it should be. What about the task of integrating user/account management with some other service? Neither make it easy to replace specific services within the content management system, because it's a monolith.

In a microservice architecture system, the individual services could be swapped out for other services that implement the same API. Suppose you wanted a centralized media (image, audio, video) service that supplied media files out to several websites? How would you do that in Wordpress or Drupal? If, on the other hand, an appropriate media service API existed, a centralized media server could be connected into the backend of several websites.

Permeable boundary between theming and the-rest-of-the-system

A serious problem with Wordpress or Drupal is the mixing of business logic into templates. Is a template the correct place to put an SQL query? Nope. But, it happens.

In Wordpress it is common practice to make WP_Query calls in theme files -- essentially meaning you're making an SQL query, in a theme file, fiddling with the data, and placing all kinds of business logic code in the theme layer. Architecturally this is wrong. Plus, it's a security/stability problem because it makes changes to theming code just as critical as code changes elsewhere.

With Drupal 8 this is somewhat fixed because the new theming layer prohibits code in template files. During the lead-up to Drupal 8 I'd seen a presentation on the new theming mechanism in Drupal 8, and one point by the presenter is the risk of a theme template containing code that executes the SQL command: "DROP TABLE users;" ... and that to generate the slide the person put the necessary code in their template file, then accidentally saved the template ... which then caused the SQL to execute, deleting their users table, thereby proving their point about the inherently risky architectural flaw.

This is one primary purpose for developing the Headless Wordpress/Drupal architecture. Done well it eliminates this risk, while additionally making it possible for the content rendering layer to iterate much more rapidly than the content management system.

First step - slap an API on the content management system allowing client code to access content as data.

Third step - PROFIT

The intermediate step is to implement one or more systems to access content through that API, and render the content for devices. It's possible to implement multiple client app's to access that API for different purposes.

  • Static website generator: Iterates over the content, dumping it out to static HTML files. This is hugely more scalable than any dynamically generated page out of a content management system.
  • Fully dynamic: Every page hit calls the API to access content
  • JavaScript in browser: The API calls could all be done in the browser, and its the browser that assembles the content in the page
  • Hybrid: Some static content, some dynamic content
  • Single page app: Build what looks like an Application, running inside a web browser window, with JavaScript driven controls and API's to the server
  • CMS-to-CMS: It's supposedly possible to rig one CMS instance to not store any content, but to access it from another CMS instance.

Implementation

I think all this is cool. Where I diverge from the story told by the Pantheon presenter is the implementation.

What he suggested is to, rather than render HTML on the server for delivery to browser, rig the CMS to send an HTML that's mostly JavaScript code that then uses the API to bring content to the browser.

As a result, the browser has to do a lot of work assembling the content, and there's lots of round trips between browser and server as it does so.

Another big problem is that search engines no longer have indexable HTML. Instead they must run faux web browsers in their web crawler farm, so that the faux browser can render the content in order to have indexable HTML. And, yes, the search engines have done this in response to the large number of websites that do significant amounts of content rendering in the browser.

I disagree that's a good idea for general purpose websites, but don't want to rathole on that topic.

The Pantheon dude suggested three JavaScript app frameworks: ReactJS, Backbone, AngularJS

There are of course a large variety of JavaScript app frameworks for in-browser development. Those three have significant marketshare, and big players are backing each.

By way of example the Calypso project was discussed. This is a desktop application developed by Automattic, which lets people manage their Wordpress.com websites from an app rather than by logging into the Wordpress.com website. There's a Github repository containing all the code, and you can easily download an app for your platform (unless you're on a Chromebook, as I am).

Another example is a TodoMVC style app developed by the presenter -- https://github.com/joshkoenig/todo-wp -- using Wordpress as the backend data store, and a front end app consuming a REST API from Wordpress.

« Republican Presidential Candidates want massive violation of First Amendment and other American legal freedoms MEADS Capability Nodes »
2016 Election Acer C720 Ad block AkashaCMS Android Apple Apple Hardware History Apple iPhone Hardware April 1st Arduino ARM Compilation Asynchronous Programming Authoritarianism Automated Social Posting Bells Law Big Brother Blade Runner Blogger Blogging Books Botnet Botnets Cassette Tapes Cellphones Christopher Eccleston Chrome Chrome Apps Chromebook Chromebooks Chromebox ChromeOS CIA CitiCards Civil Liberties Clinton Cluster Computing Command Line Tools Computer Hardware Computer Repair Computers Cross Compilation Crouton Cyber Security Cybermen Daleks Darth Vader Data backup Data Storage Database Database Backup Databases David Tenant DDoS Botnet Detect Adblocker Digital Photography DIY DIY Repair Docker Doctor Who Doctor Who Paradox Drobo Drupal Drupal Themes DVD Election Hacks Emdebian Enterprise Node ESP8266 Ethical Curation Eurovision Event Driven Asynchronous Express Facebook Fake News File transfer without iTunes FireFly Fraud Freedom of Speech Gallifrey git Gitlab GMAIL Google Google Chrome Google Gnome Google+ Government Spying Great Britain Home Automation HTTPS I2C Protocol Image Conversion Image Processing ImageMagick InfluxDB Internet Internet Advertising Internet Law Internet of Things Internet Policy Internet Privacy iOS Devices iPad iPhone iPhone hacking Iron Man Iternet of Things iTunes Java JavaScript JavaScript Injection JDBC John Simms Joyent Lets Encrypt LibreOffice Linux Linux Hints Linux Single Board Computers Logging Mac OS Mac OS X Matt Lucas MEADS Anti-Missile Mercurial Michele Gomez Military Hardware Missy Mobile Applications MODBUS Mondas Monty Python MQTT Music Player Music Streaming MySQL NanoPi Nardole Net Neutrality Node Web Development Node.js Node.js Database Node.js Testing Node.JS Web Development Node.x North Korea Online advertising Online Fraud Open Media Vault Open Source Software OpenAPI OpenVPN Personal Flight Peter Capaldi Photography Plex Media Server Political Protest Power Control Privacy Production use Public Violence Raspberry Pi Raspberry Pi 3 Raspberry Pi Zero Recycling Republicans Retro-Technology Reviews Right to Repair River Song Rocket Ships RSS News Readers rsync Russia Russia Troll Factory Scheme Science Fiction Season 1 Season 10 Season 11 Security Security Cameras Server-side JavaScript Shell Scripts Silence Simsimi Skype Social Media Warfare Social Networks Software Development Space Flight Space Ship Reuse Space Ships SpaceX Spring SQLite3 SSD Drives SSD upgrade SSH SSH Key SSL Swagger Synchronizing Files Telescopes Terrorism The Cybermen The Daleks The Master Time-Series Database Torchwood Total Information Awareness Trump Trump Administration Ubuntu Virtual Private Networks VirtualBox VLC VOIP Web Applications Web Developer Resources Web Development Web Development Tools Weeping Angels WhatsApp Wordpress