Posts tagged http
Rack: Layering Ruby Web Apps
Mar 3rd
I’ve not used it myself, but conceptually I’ve always been very interested in WSGI (the Python Web Server Gateway Interface). WSGI defines a standard interface between web servers and frameworks, giving python web applications the same portability that Java servlets enjoy, and also makes it much easier to layer code—with a standardised interface you can easily add in extra components to process your input and output before or after your main framework has handled it.
So say you had an application with a great web interface but no API to handle the input format of your choice. With WSGI you could intercept the API input and convert it before it ever hits the main application, making the whole process transparent to client and application. These two articles at xml.com are a good overview.
Ruby doesn’t have the same profusion of frameworks of python or java, but that transparent layering is still attractive, and a standardised interface makes it much easier for developers to put together experimental new frameworks without waiting for mongrel or another server to support them, or to build pluggable middleware. And that’s where Rack comes in.
According to Christian Neukirchen in an introductory blog post “dealing with HTTP is rather easy” and the core API of Rack is simply a method call that returns a hash of response code, response headers and response body. From that same blog entry:
class HelloWorld def call(env) [200, {"Content-Type" => "text/plain"}, ["Hello world!"]] end end
There aren’t many examples out there yet, but Johan Sørensen has a very simple example framework and a bit more discussion on his blog. There are also several sample adapters for existing frameworks available. What would be really nice to see next is an implementation of the atom publishing protocol using Rack, along the lines of this WSGI implementation. This could well be a project to watch.
Edge Rails Saves You Money (and improves performance)
Feb 17th
For anyone who serves up content that is requested repeatedly by the same user agents (be they web browsers, news readers, or any other) it can quickly get expensive (financially and in performance hits) to use up bandwidth sending the same data to the same destination over and over. HTTP provides mechanisms to deal with that, but until recently they’ve been poorly supported.
Those costs are the reason that this is great news. DHH just committed a change to Edge Rails that automatically adds an ETag when sending a response and returns an HTTP 304 (Not Modified) when an agent comes back asking for the same content before it has changed.
Chad Fowler has a good explanation on his blog, where I heard the news, and this page from the Universal Feed Parser docs is also a good summary.