Weekly Edition
Return to the Front page
| |||||||||||||
Ruby on Rails releases 2.0
Rails (aka Ruby on Rails or RoR) is a framework for building web applications. It has gotten a lot of attention – some would say hype – over the past few years as easy to use and learn, while allowing the creation of complex database-backed web services. In the year since Rails 1.2, the team has not been idle, with their work culminating in the release of Rails 2.0 this month. RoR is based around the idea of using the model-view-controller (MVC) pattern to cleanly separate the user interface from the application logic and data storage. All of the Ruby code written or generated for a Rails application is organized into a directory hierarchy based on what part of the MVC they implement. All of the parts of the application know how to find the others because of this convention, which is in keeping with the two principles that guided the development of RoR. Fundamentally, RoR is built around two principles. The first is "convention over configuration", which is the idea that only things that deviate from standard practices need to be specified via configuration. One can get surprisingly far by sticking with these standard practices. The other principle is "don't repeat yourself", which means that there is a single place to go to specify something about the application; other places that need it or things derived from it, retrieve it from the canonical place. This is most evident in the specification of database table and column names; they are described in the model and other parts of the application retrieve them as required. The principles are interrelated, of course, and are two of the innovations that RoR has popularized for web application frameworks. Many previous attempts required a huge amount of configuration information to be specified, often nearly identically in multiple places. Simplifying this configuration headache was explicitly a goal for Rails. It can take a bit of time to come to grips with the conventions used, but once that is done it is straightforward to use the framework. Generating code to handle simple modifications to the database data, known as scaffolding, is another technique popularized by RoR. From the specification of the data model, Rails will generate an interface to create, read, update, and delete data in that model. It can also generate "migrations" which contain the SQL necessary to create or modify the database tables to reflect changes in the model. Migrations can be used in both a forward and backward direction to keep the database in sync with the state of the application as changes are made. Rails itself is broken up into multiple components implementing each piece of the MVC architecture: ActiveRecord for the model, ActionPack for the view and controller, along with a number of lesser players. It provides extensive test harness facilities that allow testing of the web application without using a browser or network at all. RoR is a comprehensive solution, with a large number of very vocal supporters. The new release provides a number of new features, some performance enhancements, as well as the requisite bug fixes. The bulk of the changes in 2.0 are in the controllers. The first is better support for "representational state transfer" (REST) style web application APIs, which were introduced in Rails 1.2. Better support for multiple different views based on application criteria were also added, allowing the interface to change based on the device accessing it, for example. Security enhancements were made as well, with code being added to help protect against cross-site scripting and cross-site request forgery attacks. These two web application flaws are becoming rather popular to exploit, so any assistance a web framework can give is welcome. The default session objects have changed to be cookie-based, rather than stored in a file or the database. This allows snooping of the session data, but the data is hashed to prevent forgery. Performance and scalability have been the traditional knocks against Rails, and though there were some enhancements, especially to ActiveRecord, that should provide some boost, it is not clear how well Rails handles huge sites. It is something the Rails team is aware of, so, over time, those kinds of problems should be solved. RoR is a very capable framework and the 2.0 release looks very good. The Rails community should find much of use. (Log in to post comments)
Performance Posted Dec 20, 2007 16:07 UTC (Thu) by rfunk (subscriber, #4054) [Link] Rails deployment issues always seem to play second fiddle to the programming aspects, probably because the programming is so easy and the deployment can be such a hassle. And deployment is mainly a hassle because Ruby is slow and Rails is big (relative to Ruby's slowness anyway). As far as I know, the current best-practices approach to deployment performance seems to be to have a front-end web server (or set of them) that serves static content and proxies non-static requests back to a set of servers running a Ruby-based web server that is always running the rails application. Scaling involves increasing the number of application server processes, application server machines, and web server front-ends. (I'm anxiously awaiting an upcoming book about Rails deployment.)
Performance Posted Dec 21, 2007 3:50 UTC (Fri) by jordip (guest, #47356) [Link] For the courageous, Ruby 1.9.1 is about to be released. RoR is almost compatible with it and I guess they will launch a compatible version in January. This mix should make RoR at least 30% faster, being conservative.
Performance Posted Dec 21, 2007 5:47 UTC (Fri) by bronson (subscriber, #4806) [Link] It's true that scaling Rails is interesting. Each request is serialized using a semaphore! A single Rails process handles only one request at a time and is proud of it. The serialization makes Rails a little easier to code for but, to deploy at better than 10 req/sec, you'll need to set up a load balancer in front of multiple Mongrel processes. Each Mongrel takes ~50-150MB, so it doesn't take too many to exhaust the memory of a single host. And, you're right: it's a big win to serve static content outside of Rails. Merb is an example of a Rails-like framework that does work in parallel. It takes a bit more awareness to write for but, if you have long-running processes (like a lengthly file upload), a little extra attention for a drastic savings in processes/RAM is probably worth it. For more complex setups, a few companies set up a few Merbs to handle long-running processes and Rails to handle the easier stuff. Depending on your app, it doesn't take too many app servers before the database starts to suffer (many tens of simultaneous connections)... One way of fixing this is spreading your data across multiple databases. ActiveRecord actually makes this fairly painless (multiple plugins) but it takes a bit of forethought. I'll say this: Rails makes deployment exciting! If there's a good book, I'm all ears. Do you like Deploying Rails Applications, Scaling Rails, or something else?
Performance Posted Dec 21, 2007 14:24 UTC (Fri) by rfunk (subscriber, #4054) [Link] I wouldn't even think of deploying a rails app without at least two rails processes, preferably more. The only book I've looked at so far about deployment is the original DHH Agile Rails book, but there are lots of websites around with recommendations. I intend to get the Zygmuntowicz "Rails Deployment" book when it comes out. I'm not aware of other books specifically on the topic.
|
|||||||||||||