RailsConf Europe: Hydra
Posted by Nick Sieger Sat, 06 Oct 2007 12:04:00 GMT
On September 19, Craig and I presented our talk at RailsConf, which appears to have been well received. It went off mostly without a hitch, if it wasn’t for a couple of hiccups in the demos. I apparently didn’t practice them enough, because a couple of critical steps were either missed or I did them out of order and confused myself. But that’s ok, because I’m releasing the demo steps, source and slides here so you can try them out for yourself.
So, download the zip and follow along. The contents look like this:
1-active-resource-basics.txt 2-make-resourceful.txt 3-atom-roller.txt 4-service-chatter.txt RailsConfEurope-Hydra.pdf demo/ demo-baked/
The demo steps are in the text files; I’d recommend going in the order specified. It turns out the third isn’t really a demo but more of a code review, because it also requires you to have Roller set up and I’m not going into those details for now. If you want to just run the demos, skip to
demo-baked, the finished product.
For those of you who didn’t see the talk, here’s the basic message.
Look at your basic MVC Rails app.
Why not consider spliting it into two? ActiveResource allows you to access a RESTful resource in your Rails application like it was just another model.
This might seem like overkill for a simple application, but what if you had an e-commerce application domain like this?
Splitting up your code into separate Rails applications encourages encapsulation, reduces potential coupling, and gives you more flexible deployment options. Basing interactions upon REST and HTTP means that you can more easily mash up data or create caching strategies, given proper usage of ETags/Last-Modified and/or cache-control headers. The great thing is that existing HTTP reverse proxies can be used without having to mix the caching code in with your application code.
In the application we’re building, we have a number components that are not Rails-based. To expose them to our environment, we’ve taken the strategy of exposing a simple REST web service for the component, and then it can be consumed by the other applications using ActiveResource. The REST web service can either be implemented in the component’s native language/technology, or in some cases we’ve written a wrapper service in Rails since Rails makes it so easy to build REST interfaces. In that case, Rails is pure integration -- RESTful glue.
The idiom that makes this all possible is the uniform interface. In HTTP, this means addressability (each resource gets a unique URI) coupled with the HTTP method verbs HEAD, GET, POST, PUT, and DELETE. Inside your Rails applications, it’s the ActiveRecord interface. If you keep your controllers skinny, you can boil the interface down to the following set of methods (in this case, for the prototypical blog post model):
Post.new/Post.create Post.find @post.save @post.update_attributes @post.errors @post.destroy
And in fact, this is precisely what ActiveResource provides, and it’s enabled by duck-typing. Walking through the demos illustrates this pretty well, as you’ll basically swap ActiveRecord for ActiveResource with no noticeable difference, all the way down to validation errors in the scaffolded forms (which I was unable to demo in the talk due to the hiccups).
We’ve found that when you’re making RESTful web services, the controllers largely become boilerplate because of the uniform interface.
make_resourceful has been a boon in that regard, as the demos also show. There are several plugins that help you DRY up your controllers (other approaches include
resources_controller), so you have some choices there.
We mentioned some drawbacks in our experience with ActiveResource, which have largely been addressed for the upcoming Rails 2.0 release.
Finally, we noted that deployment could be a pain with so many Rails applications to keep running. To that end, we are leveraging JRuby and Glassfish to make this a non-issue, as we simply WAR up our Rails applications with warbler and let Glassfish take care of the rest. Performance is still an open question, but we plan to roll up our sleeves and make sure this combination really hums.
Enjoy the demos! Feel free to drop me an email if you have any questions or troubles with them.