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
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.
