Best Practical

Jifty's Request Inspector

We're experimenting with mirroring technical articles written by Best Practical engineers. This article is about a component of Jifty, our web framework.

Jifty's RequestInspector plugin provides you with debugging information for HTTP requests. You can examine the SQL queries that were issued in servicing the request, inspect a Devel::NYTProf profile of the request, and more. The information is presented in an (admittedly ugly) admin panel. Here's what our Changelogger's request inspector page looks like:

If we click into one of the requests, we can get an overview of that request.

We can inspect in detail a particular part of a request with another click.

Backend

The frontend is good enough. It gets the job done. But what I am really interested in, and what I had far more fun creating, is the backend that powers this.

RequestInspector is a Jifty plugin. Its job is to manage all of the other plugins that inspect requests (such as SQLQueries, DumpRequestResponse, NYTProf, and Gladiator). RequestInspector informs the plugins of interesting events such as: a new request is beginning, that request finished.

Each plugin produces various kinds of data. That data is completely opaque to RequestInspector. The data can be an object, a number, a code reference, or whatever else. All RequestInspector does is keep track of that data, handing the data to the plugin when it needs to do something with the data.

When a new request begins, RequestInspector calls the inspect_before_request method on each plugin. When the request ends, inspect_after_request is called on each plugin. The interesting bit is that the opaque data is threaded between the return values and parameters of these methods. The return value of inspect_before_request is passed to that plugin's inspect_after_request. inspect_after_request's return value is stored for later rendering. (In what amounts to a global variable — sorry!)

When the user wants to see a request, RequestInspector calls the inspect_render_summary method on each plugin. When the user wants to see the detailed analysis by a particular plugin for a particular request, RequestInspector calls the inspect_render_analysis method on that plugin. It is completely up to the plugin to decide what to render. Both methods receive the data it returned from inspect_after_request for that request.

Benefits

You might wonder why this design is better than, say, a specific data format to which each plugin must adhere.

It is unclear what such a data format would look like. I don't think a single data format could usefully encompass the different kinds of data that these plugins produce. While SQLQueries's data is complex data structure with a lot of information, NYTProf's is basically just a random number used to track the on-disk profile directory.

The format would certainly evolve over time. This means that plugins would have to change as well just to keep up with RequestInspector. With my design, plugins really only need to change when they want to support newer RequestInspector features.

It's simpler for plugins to let them dictate how they want to store whatever they are tracking. It's simpler for the RequestInspector core too, since it is free from having to examine the plugins' data.

Finally, the RequestInspector plugin can get arbitrarily complex and the plugins do not have to care about it. The RequestInspector already lets you filter out URLs you know you will not want to inspect. The individual request inspector plugins do not have to implement that functionality.

In the future, I plan to add a feature to RequestInspector that lets you see which requests took the most amount of database time, or leaked the most amount of memory, etc. All the feature will require of plugins is that they implement an optional inspect_compare_requests method. The method will receive that plugin's data from two requests and returns -1, 0, or 1. So trivial that I should just do it now.. :)

Basically, RequestInspector leverages the Principle of Least Knowledge to keep things simple, easy, and flexible. Shriram Krishnamurthi's Moby Scheme Compiler talk was particularly influential on this design. He described a similar (though simpler) system that he uses to make programming fun and interesting for middle school kids.

Jifty at the London Perl Workshop

I got to present a pair of talks on  Jifty at the London Perl Workshop this weekend. It's always a pleasure to get to hang out with the folks from london.pm....even if they do attempt to drag me out for drunken Karaoke on occasion.

Seriously, though, I had a great time.

I was the first talk of the morning in the beginners' track. The "intro-level" talk is a derivative of the talk I gave at OSCON, by way of Audrey's presentation of it at Amazon. You can download a PDF of the talk.

After lunch, I was the first talk in the advanced track.  As I'd been expecting to give a second (shorter) introductory talk, I spent most of the plane ride over and the previous evening desperately cranking out slides for Scary Jifty, a talk about some of the deep magic we're using behind the scenes to make developing with Jifty simple and clean. If you want to see a bit about Template::Declare, IPC::PubSub and some hacks that...will likely be used by my detractors to besmirch my good name, check out a PDF of the talk.

39404142

Smart caching for CSS and JS

(Reposted from Tom's original post at http://hiveminder.blogspot.com/2006/09/smart-caching-for-css-and-js.html)

When working on Hiveminder, we ran across the problem of how to keep the CSS and JS cached by browsers as long as possible but still be updated as soon as it changes.  We wanted to retain the ease of updating the live site, while at the same time not forcing users to clear their caches every time we (frequently) push a CSS or JS update.

The easiest way is to simply change the referenced filename so the browser doesn't have the contents cached.  Many sites accomplish this by putting version numbers in the filename.  However, that requires manually changing the filename every time, and though it could have worked for Hiveminder, we wanted a general, hands-free solution to the problem for our web framework Jifty.

Our final solution has two parts:

1. Squish all the CSS files into one file and all the JS files into another.
2. Hash the contents of those files using MD5 and use the resulting digest as the filename.

The advantage of this is that it's totally hands free.  Whenever the contents of any of the CSS or JS files change, the resulting digest and therefore filename changes, and the browser picks up the new code.  It also slashes the number of HTTP requests by squishing the all the files together into one "virtual" file (the contents of which we can also cache server-side).  For good measure, we also gzip the data on the fly if the client accepts it.

Jifty takes care of all of it, using JavaScript::Squish and our new CSS::Squish to squish the files.  We think it's a novel idea that works really well, allowing us the advantages of modular CSS and JS while keeping it efficient in production and easily updatable.