Hi! I’m Wim, live in the beautiful bike-centric city of Ghent and I’ve been fortunate enough to be able to work full time on making Drupal better & faster for over a decade now! (I’m also interested in energy efficiency, smart home shenanigans and think more software empathy would make the world a better place.)

 

5 April, 2017

Drupal 8.3: BigPipe experimental → stable!

Almost a year ago, BigPipe was the first experimental module added to Drupal 8. It was still experimental in Drupal 8.2 (October 2016), but it was upgraded from alpha to beta stability. Later today, Drupal 8.3.0 is going to be released, and BigPipe is now stable!

Install it!

BigPipe is a zero-risk module. So … why not install it right now? You can uninstall it at any time. It won’t cause problems in any browser, on any web server, or with any proxy. Because:

There is zero risk of data loss. And when the environment — i.e. web server or (reverse) proxy — doesn’t support streaming, then BigPipe-delivered responses behave as if BigPipe was not installed. Nothing breaks, you just go back to the same perceived performance as before.

If you’re still on Drupal 8.2 for a while — also install it! There are no functional changes for BigPipe between 8.3 and 8.2.

Stability

In hindsight, we could have made BigPipe stable from day one, or at least in Drupal 8.2.

22 March, 2017

Backwards Compatibility: Burden & Benefit

In my job at Acquia, I’ve been working almost exclusively on Drupal 8 core. In 2012–2013 I worked on authoring experience (in-place editing, CKEditor, and more). In 2014–2015, I worked on performance, cacheability, rendering and generally the stabilizing of Drupal 8. Drupal 8.0.0 shipped on November 19, 2015. And since then, I’ve spent most of my time on making Drupal 8 be API-first: improving the RESTful Web Services support that Drupal 8 ships with, and in the process also strengthening the JSON API & GraphQL contributed modules.

In the process, I’ve learned a lot about the impact of past decisions (by myself and others) on backwards compatibility. The benefit of backwards compatibility (BC). But the burden of ensuring BC can increase exponentially due to certain architectural decisions. I’ve been experiencing that first-hand, since I’m tasked with making Drupal 8’s REST support rock-solid, where I am seeing time and time again that “fixing bugs + improving DX” requires BC breaks. Tough decisions.

In this talk (which will be a core conversation at DrupalCon Baltimore), I analyzed the architectural patterns in Drupal 8, and provided suggestions on how to do better. I don’t have all the answers. But what matters most is not answers, but a critical mindset going forward that is consciously considering BC implications for every patch that goes into Drupal 8!

Not thoroughly considering new interfaces (API surface) risks making the software unmaintainable!

Preview:

See https://events.drupal.org/baltimore2017/sessions/backwards-compatibility-burden-benefit + https://seville2017.drupaldays.org/sessions/backwards-compatibility-burden-benefit.

Conference
Drupal Dev Days Seville 2017 + DrupalCon Baltimore
Date
Location
Seville, Spain + Baltimore, USA
Duration
50 minutes
20 February, 2017

Ode to OpenTracker

This is an ode to Dirk Engling’s OpenTracker.

It’s a BitTorrent tracker.

It’s what powered The Pirate Bay in 2007–2009.

I’ve been using it to power the downloads on http://driverpacks.net since the end of November 2010. >6 years. It facilitated 9839566 downloads since December 1, 2010 until today. That’s almost 10 million downloads!

Stability

It’s one of the most stable pieces of software I ever encountered. I compiled it in 2010, it never once crashed. I’ve seen uptimes of hundreds of days.

12 May, 2016

BigPipe

Did you know that often the majority of the time spent generating a HTML page is spent on a few dynamic/uncacheable/personalized parts? Pages are only sent to the client after everything is rendered. Well, what if Drupal could start sending a page before it’s fully finished? What if Drupal could let the browser start downloading CSS, JS, and images, and even make the majority of the page available for interaction while Drupal generates those uncacheable parts? Good news — it can!

This is where Drupal 8’s improved architecture comes in: it allows us to do Facebook BigPipe-style rendering. You can now simply install the BigPipe module for Drupal 8.0 and see the difference for yourself. It has been included in Drupal 8.1 as an optional module (still marked experimental for now).

In this session, we will cover:

  • The ideas behind BigPipe
  • How to use BigPipe on your Drupal site
  • How Drupal is able to do this (high-level technical information)
  • How you can make your code BigPipe-compatible (technical details)
  • What else is made possible thanks to the improved architecture in Drupal 8 (ESI etc.), without any custom code

(We start with the basics/fundamentals, and gradually go deeper into how it works. Even non-Drupal people should be able to follow along.)

See https://events.drupal.org/neworleans2016/sessions/bigpipe + http://drupalcamp.be/node/196.

When I delivered this talk at DrupalCamp Ghent, Peter Decuyper did an amazing sketchnote:

Conference
DrupalCon New Orleans + DrupalCamp Ghent
Date
Location
New Orleans, USA + Ghent, Belgium
Video
BigPipe
Duration
60 minutes
20 April, 2016

Drupal 8.1: BigPipe as an experimental module

Today, Drupal 8.1 has been released and it includes BigPipe as an experimental module.

Six months ago, on the day of the release of Drupal 8, the BigPipe contrib module was released.

So BigPipe was first prototyped in contrib, then moved into core as an experimental module.

Experimental module?

Quoting d.o/core/experimental:

Experimental modules allow core contributors to iterate quickly on functionality that may be supported in an upcoming minor release and receive feedback, without needing to conform to the rigorous requirements for production versions of Drupal core.

…

Experimental modules allow site builders and contributed project authors to test out functionality that might eventually be included as a stable part of Drupal core.

With your help (in other words: by testing), we can help BigPipe “graduate” as a stable module in Drupal 8.2. This is the sort of module that needs wider testing because it changes how pages are delivered, so before it can be considered stable, it must be tested in as many circumstances as possible, including the most exotic ones.

16 February, 2016

A RESTless week

I spent about a week of my time at Acquia on improving Drupal 8’s REST support.

That time was spent fixing, reviewing, triaging and documenting.

Drupal 8’s REST works very well, we just have to make it more friendly & helpful, remove Drupalisms and support more REST capabilities.

Fixing, reviewing & triaging

I went through the entire issue queues of rest.module, serialization.module and hal.module. I was able to mark about a dozen bug reports as duplicates, fix a dozen or so support requests, have reviewed probably a few dozen patches, rerolled about a dozen patches, created at least another dozen patches and … triaged 100% of the open issues. I clarified titles of >30 issues.

27 January, 2016

BigPipe webinar

This talk covers everything in BigPipe (the webinar I did a few weeks ago was only an introduction).

I’ll let the webinar summary speak for itself:

Did you know that the majority of the time spent generating a HTML page is spent on a few personalized parts? Pages are only sent to the client after everything is rendered. Well, what if Drupal could start sending a page before it’s fully finished? What if Drupal could let the browser start downloading CSS, JS, and images, and even make the majority of the page available for interaction while Drupal generates the personalized parts? Good news - it can.

This is where Drupal 8’s improved architecture comes in: it allows us to do Facebook BigPipe-style rendering. You can now simply install the BigPipe module for Drupal 8 and see the difference for yourself.

In this webinar, we will discuss:

  • The ideas behind BigPipe
  • How to use BigPipe on your Drupal site
  • How Drupal is able to do this (high-level technical information)
  • How you can make your code BigPipe-compatible (technical details)
  • What else is made possible thanks to the improved architecture in Drupal 8 (ESI etc.), without any custom code
Date
Location
Belgium, online
Video
BigPipe: The Architecture Behind the Fastest Version of Drupal Yet
Duration
60 minutes
19 January, 2016

BigPipe introduction webinar

Acquia frequently does webinars and given my work on BigPipe, I was asked to present with Fabien Potencier (of Symfony fame). Fabien covered back-end performance in the form of profiling, I covered front-end performance, and really the intersection between front-end and back-end performance in the form of BigPipe.

Date
Location
Belgium, online
Video
Best Practices for Drupal Performance Tuning
Duration
20 minutes
18 January, 2016

Performance Calendar 2015: "2013 is calling: are CMSes fast by default yet?"

This year, Performance Planet did an advent calendar again, just like the last few years. I also contributed an article — what follows is a verbatim copy of my “2013 is calling: are CMSes fast by default yet?” article for the 2015 Performance Calendar that was published exactly a month ago.

Two years ago, I wrote about how making the entire web fast is the real challenge. How only the big few companies are able to have very fast websites, because only they have the resources to optimize for performance. Many (if not most) organizations are happy just to have a functioning, decent looking site.

In that article, I said I thought that if we made the most popular CMSes faster by default. That would go a long way to make the majority of the web faster. Then less technical users do not need to know about the many arcane switches and knobs just to get the intended performance. No more “oh but you didn’t set it up correctly/optimally” — or at least far less of it.