Posts tagged frameworks

Rack: Layering Ruby Web Apps

Mar 3rd

Posted by James Stewart in Commentary

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.

, , , , , ,

BarCamp Grand Rapids 2

Aug 21st

Posted by James Stewart in Commentary

This weekend was the inaugural BarCamp Grand Rapids. I was only able to make it for the day on Saturday, missing the previous evening’s introductions, talks, and trip to Grand Rapids Brewing Company, but it was good to be able to attend, and even better to have it just a short bike ride away.

It was a fairly small group that was gathered, so almost all of the sessions ran in a single room. Java developers were in the majority—probably not a surprise given that it was the local Java Users’ Group that put the event together—but those of us working with dynamic languages made sure that those languages got their share of mentions.

If anyone was hoping for a serious conflict in the ‘web frameworks smackdown’ they will have been disappointed, as we quickly seemed to come to an agreement that most of the time maintainability and scalability are down to the quality of the code as much as the choice of language/framework, and moved on to a quick demonstration of the building of a Rails app, and a discussion of the potential of JRuby.

Having never really worked with java, I enjoyed Kyle‘s demonstration of the DWR ‘Easy Ajax for Java’ library which I’d read about but not seen in action. It still seemed like more work than RJS, but for those with an existing commitment to java it seems like a great help.

I had various ideas I’d contemplated presenting on, including ActiveResource, my Collage project and its use of Atom, and microformats. But time didn’t allow me to prepare the former two, and Andy had microformats pretty well covered in his (very interesting) ‘geo’ session, so I ended up running a quick demo of the Smart Pill Filemaker/PHP plugin, that seemed to be well received.

Overall, it was good to find some other people around Grand Rapids who have a good grasp of what’s happening in web development at the moment. Not being in a big city or getting to conferences, it can sometimes seem like all the innovation is going on elsewhere. Most of it is, but at least a few people around here are involved in working out where the web is going next.

, , ,