The Rails Engine That Could – In Motion

at February 6th, 2012

I recently gave a talk at Groupon’s weekly GeekFest event titled “The Rails Engine That Could – In Motion”. It was an introduction to Rails Engines that highlighted a successful use of them while consulting for a client through Obtiva.

I will include here a summary of my talk as well as the slide deck.

In a nutshell, the problem that Rails Engine aims to solve is code reuse that cuts across models, views, and controllers. This usually arises whenever there is a need to reuse screens of information across multiple applications while slightly customizing the look and feel and data displayed per app.

Here is an example of such functionality:

College Search Map


Developers often reuse the data models involved by possibly offloading the model logic into gems or web services that can be reused from the different applications, but they still duplicate the controller and view logic, especially when there is a need to make adjustments.

Rails Engines solve that problem by allowing developers to reuse models, views, and controllers while supporting customizations across multiple applications.

I actually stumbled upon several patterns in my use of Rails Engines that ensure their implementation is application-agnostic (low coupling to applications) while still allowing for high flexibility for different needs. The patterns scale up in complexity to allow developers to employ them in an Agile fashion, starting with simpler solutions and scaling them up as applications demand more customizability from engines.

Here is a summary of the Rails Engine patterns discovered:

  • Common Domain: allow multiple apps to share a common domain
  • Expose Helper: customize view presentation logic in different apps
  • Expose Partial: customize a part of the view content in different apps
  • Extension Partial: allow different apps to contribute content for a specific part of the view
  • Extension Point: allow different apps to contribute content in different parts of the view
  • Configurable Features: allow different apps to request features from an engine in different combinations or adjust an engine’s configuration settings

The key benefit for relying on Rails Engines is eliminating duplication and improving productivity in the long run via code reuse cutting across the MVC layers. Refinery CMS is one public example of a Rails Engine that can be dropped in Rails applications to instantly add content management capabilities, including screens and routes. It would be interesting to see how they will shape future Rails projects as more developers find uses for them in the Rails community.

Here are the slides of the talk that I gave at Groupon’s GeekFest:

Hopefully, this will motivate other developers to avoid duplication and rely on Rails Engines whenever they need to reuse functionality cutting across models, views, and controllers.

No Tags

No comments yet

Leave a Reply

Your email address will not be published. Required fields are marked *