Ruby on Rails is a full-stack, open-source Web framework used for writing real-world applications with more simplicity and less code than most XML frameworks. As the official RoR web site says, it’s “an open-source web framework that’s optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.” The happiness comes from Rails’s sustainable and productive approach to Web development. In 2005, when Rails was introduced, available frameworks were complicated to setup and developed mostly in Java and PHP. It left developers frustrated when it came to starting new projects—they had to begin from scratch in Java, setup a lot of XML files, and create several lines of code just to get a simple, “Hello World!” You had to know Struts, JSP, XML, Tomcat and more before you could get a Web project going. So based on that, one all-important thing was implemented on Rails and ported to several other frameworks: convention over configuration.
That’s a simple thing, unfortunately we, the developers, tend to make things complicated and create applications that you can configure in any number of ways. To streamline things, the core developers of Rails focused on convention and configuration only in the framework’s real guts. For example, all the controllers are called by a name and a single suffix: “_controller.” The names of database are referred to in plural (“products,” not “product” or “prod.”) It helps developers find what they’re looking for, quickly.
So, What Is Ruby?
Ruby was designed to focus on simplicity and productivity, and Rails takes advantage of these traits. In this environment, the concept of “DRY” —Don’t Repeat Yourself—is important, and Ruby provides a lot clever of ways to avoid code repetition. So, developers can do more with less. It needs more CPU power, but in this age of cheaper and cheaper hardware, that’s not much of an issue. Behind the curtains, Ruby on Rails is a Model View Controller
framework, with a pattern that’s among the most useful when developing Web applications. The framework’s main components are ActionPack, ActiveSupport, ActiveModel, ActiveRecord, ActiveResource, and ActionMailer. Essentially, Rails is a framework composed of other frameworks than can be used independently. Some details:
- Action Pack: Handles requests and responses. This framework is part of Rails’s Model View Controller pattern, which serves the Web request, handling, routing, and view generation. To provide the response, it defines controllers that implement actions in order to render views.
- Active Model: Provide the interfaces for the Model part of Model View Controller. This component is new in Rails 3.0. In previous versions, the model layer was based on ActiveRecord. In the current version, you can use any ruby class as a Model. This is very important because you can use your own persistence layer and glue it into Rails.
- Active Record: This is the Object Relational Mapping (ORM) component of Rails, with a very nice zero-configuration feature. Naming and convention is the key to maintaining simple and minimal code to define classes that will be persisted in the database tables.
- Active Support: a collection of utility classes and standard library of extensions that are useful in Rails. We can find this extensions useful for several Ruby projects.
- Active Resource: Connects business objects and Representational State Transfer (REST) Web services. With ActiveResource, you can easily use REST to expose your ActiveRecord models with just a small amount of code. This is a useful way to create an API without much effort.
- Action Mailer: This framework provides the email service layer, helping out to send the forgot password emails, registration emails, invoices for billing, etc. This class wraps ActionController from ActionPack to render the emails as page views, with the same render and templates like pages.
- ORM Embedded: no configuration needed.
- Generators: for Controllers, Models, Views, Tests and other code that you’ll need. With just a command, you can have the whole CRUD (create, read, update, delete) working in your browser.
- Migrations: With ActiveRecord, the DB structure is versioned. Migrations let you go backward and forward so the app can take care of any changes on the database structure.
- Rack/Metal and Middleware: For speed, Rails provide access to the low level HTTP request/response handling, resulting in faster API access for example when rendering isn’t required. The Middleware uses the Rack interface to receive its request directly and sends the response directly to the front end. Middleware can also be used to inject fast handlers/pre-filters into requests.
- REST and Polymorphic Controllers/Resources: ActionController provides a polymorphic way to respond to the URI based on the mime type. That means you can use the same method in the controller, and provide several responses, one in XML, one in PDF, another in JSON, and another in HTML. While you have to write the code anyway, you only have to render the associated view for each mime-type. The controller is simple and easy to understand in its handling of polymorphic requests pointing to the same resource.
- Rendering engines for All Tastes: On the View side, Rails provides a default rendering engine using ERB templating. However, you can use approaches like HAML or Slim, or create your own.
- Rake and Command Line Tasks: When you have to do file maintenance for your application--moving files, running upgrade processes, etc.-- Rails works with Rake so you can automate tasks in Ruby.
- Dependencies Easier than Ever: Dependencies weren’t so well-handled in Rails initially, but then the new Bundler appeared (thanks Yehuda Katz (@wycats). It deals with them in a smart, easy-to-maintain way.
- The Community: One of the keys to success with Rails is the Ruby community itself. It provides events for all flavors, from small to big, from local to global. I highly recommend getting involved and attending events to meet developers in person.
Can I use Rails in my next project?
Yes and no. It depends on what kind of project you’re undertaking, its requirements, and so on. But generally, I think it’ll fit for applications defined with commonplace requirements. Even if it doesn’t, there are certainly other Ruby frameworks you could use. If nothing else, ask the community. (Or me.)