Everyone knows that the unofficial motto of Drupal is, "There's a module for that!" But everyone also knows that the fastest way to having the slowest site is to install every module under the sun. Still, when the client ranks a piece of functionality on their "must-have" list, and the only way to accomplish it involves installing a complicated module or writing your own, what other option do you have?

Enter Varnish, the reverse proxy wunderkind. Many people know Varnish in its role near the top of the Web caching stack, but that's only the beginning. Varnish features a full content-parsing engine and the ability to execute arbitrary code written in the language of your choice. Put this together, and Varnish can become an all-seeing, all-dancing partner alongside Drupal in your site development and maintenance lifecycle. To be sure, not all problems are suitable for Varnish. But neither are all problems justification for hacking on Core. The goal is to see Varnish and Drupal as complementary in the same way that PHP and MySQL are; symbiotic tools, of which you choose the best for any given development challenge.

We'll start with an examination of ESI, then move on to seeing that as simply a particular implementation of the more general concept of Varnish's request processing flow. We'll also cover working with the APIs exposed by VCL—both the documented and the, let's say, "not-so-documented" ones—and common "gotchas" when you start pushing beyond a vanilla reverse proxy configuration. Given time or interest, we'll go into opportunities for expansion, some practical re-implementations of Drupal modules entirely or mostly within Varnish, and security concerns that can arise when you start offloading critical elements. Audience participation and feedback is heartily encouraged throughout; it's called the bleeding edge for a reason, and everyone has problems for discussion or solutions to contribute.