Talks

This is a follow-up to my DrupalCon Pittsburgh talk from a year prior and the shorter DrupalCon Lille talk. It provides a ~15 minute overview of the status nor the progress, but dedicates the majority to 5 (!!!) live demos to show how to start using config validation today:

1. use Config Inspector to find which config is still missing validation constraints, add it, and observe it catching invalid data — by adding a few lines of YAML!
2. adding validation constraints to config schema, and observing them working and being picked up by Config Inspector
3. update existing config forms to use validation constraints, using the new #config_target
4. modifying configuration via JSON:API!
5. last but not least: a Guaranteed-to-Work Recipe, created from scratch, and it refusing to get applied if it results in invalid configuration

This is a follow-up to my DrupalCon Pittsburgh talk. It does not provide an overview of the status nor the progress, but instead it’s hands-on, with 2 live demos to help attendees:

1. use Config Inspector to find which config is still missing validation constraints, add it, and observe it catching invalid data — by adding 3 lines of YAML!
2. update existing config forms to use validation constraints, including tweaking the validation error message — by adding 6 lines of YAML and copy/pasting 5 lines of PHP!

Each in less than 5 minutes, including the explanation!

In other words: everybody walked out ready to contribute to the DrupalCon sprints on the next day, or to update their own modules.

I’m honored to say that this was voted the 8th most interesting session at DrupalCon Lille!

As has become a tradition since DrupalCon Amsterdam 2019, all Drupal core initiatives with leads attending DrupalCon Lille took part in a PechaKucha-style keynote format. Despite not leading any initiative right now, I was asked to present the status & progress of the work on Config Validation that I together with a handful of others have been doing in the past few months.

Drupal 8 shipped with many exciting new concepts, including “configuration”, “configuration and content entities”, “validation constraints” and “API-First”.

The missing link between these has always been the inability to modify configuration through Drupal’s REST or JSON:API. Because only content entities have validation constraints.

This has been the #1 blocker to the Drupal (JS) Admin UI initiative: validation of configuration unfortunately (but understandably) still is hardcoded in the PHP-based form logic.

But … in the background, the foundation was laid during the Drupal 8 cycle to validate configuration. In fact, one contrib module has been doing it since 3 years before this DrupalCon is taking place — no core hacks required.

Drupal 10’s CKEditor 5 module is the first time that Drupal core is using validation constraints instead of form-based validation logic!

Not only does this allow modifying configuration through APIs, it also allows us to eliminate subtle configuration errors that go unnoticed, and thus make Drupal more reliable in general!

It also paves the path for the Recipes Initiative as well as the many configuration management-related modules to become much more reliable.

All Drupal core initiatives with leads attending DrupalCon Amsterdam took part in an experimental PechaKucha-style keynote format (up to 15 slides each, 20 seconds per slide):

Drupal 8’s continuous innovation cycle resulted in amazing improvements that made today’s Drupal stand out far above Drupal 8.0.0 as originally released. Drupal core initiatives played a huge role in making that transformation happen. In this keynote, various initiative leads will take turns to highlight new capabilities, challenges they faced on the way and other stories from core development.

I represented the API-First Initiative and chose to keep it as short and powerful as possible by only using four of my five allowed minutes. I focused on the human side, with cross-company collaboration across timezones to get JSON:API into Drupal 8.7 core, how we invited community feedback to make it even better in the upcoming Drupal 8.8 release, and how the ecosystem around JSON:API is growing quickly!

It was a very interesting experience to have ten people together on stage, with nearly zero room for improvisation. I think it worked pretty well — it definitely forces a much more focused delivery! Huge thanks to Gábor Hojtsy, who was not on stage but did all the behind-the-scenes coordination.

The benefits of backwards compatibility (BC) are clear: no users are left behind. Which leads to higher adoption rates because you’re often getting new features and you always have the latest security fixes.

Of course, that’s easy when you have a small API surface (as Nate Haug once said: “the WordPress API has like 11 functions!” — which is surprisingly close to the truth). But Drupal has an enormous API surface. In fact, it seems there’s APIs hiding in every crevice!

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

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 Drupal 8, we have experience with some extremes:

1. the BigPipe & Dynamic Page Cache modules have no API, but build on top of other APIs: they provide functionality only, not APIs
2. the REST module has an API, and its functionality can be modified not just via that API, but also via other APIs

The first cannot break BC. The second requires scrutiny for every line of code modified to ensure we don’t break BC. For the second, the burden can easily outweigh the benefit, because how many sites actually are using this obscure edge case of the API?

We’ll look at:

• How can we make our modules more evolvable in the future? (Contrib & core, D8 & D9.)
• Ideas to improve this, and root cause hypotheses (for example, the fact that we have API cascades and not orthogonal APIs)

We should be thinking more actively about how feature X, configuration Y or API Z might get in the way of BC. I analyzed the architectural patterns in Drupal 8, and have some thoughts about 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! This session is only a starting point; we should continue discussing in the hallways, during dinner and of course: in the issue queues!

Preview:

As part of working in Acquia’s Office of the CTO, I’ve been working on the API-First Initiative for the past year and a half! Where are we at? Find out :)

Preview:

The Drupal render pipeline and its caching capabilities have been the subject of quite a few talks of mine and of multiple writings. But all of those were very technical, very precise.

Over the past year and a half I’d heard multiple times there was a need for a more pragmatic talk, where only high-level principles are explained, and it is demonstrated how to step through the various layers with a debugger. So I set out to do just that.

I figured it made sense to spend 10–15 minutes explaining (using a hand-drawn diagram that I spent a lot of time tweaking) and spend the rest of the time stepping through things live. Yes, this was frightening. Yes, there were last-minute problems (my IDE suddenly didn’t allow font size scaling …), but it seems overall people were very satisfied :)

Have you seen and heard of Render API (with its render caching, lazy builders and render pipeline), Cache API (and its cache tags & contexts), Dynamic Page Cache, Page Cache and BigPipe? Have you cursed them, wondered about them, been confused by them?

I will show you three typical use cases:

1. An uncacheable block
2. A personalized block
3. A cacheable block that you can see if you have a certain permission and that should update whenever some entity is updated

… and for each, will take you on the journey through the various layers: from rendering to render caching, on to Dynamic Page Cache and eventually Page Cache … or BigPipe.

Coming out of this session, you should have a concrete understanding of how these various layers cooperate, how you as a Drupal developer can use them to your advantage, and how you can test that it’s behaving correctly.

I’m a maintainer of Dynamic Page Cache and BigPipe, and an effective co-maintainer of Render API, Cache API and Page Cache.

Preview:

As part of working in Acquia’s Office of the CTO, I’ve been working on the API-First Initiative for the past year and a half! Where are we at? Find out :)

Preview:

As part of working in Acquia’s Office of the CTO, I’ve been working on the API-First Initiative for the past year and a half! Where are we at? Find out :)

Preview: