Modular Rails: Use Cases

by Thibault - November 24, 2014

In the first post of the modularity series, I shared with you what building a modular Ruby on Rails application means in terms of project organization. In this article, we’ll go over a few use cases that could use a bit of modularity.

This is the second article in the Modular Rails series. Here are the other posts:

If you don’t know what is modularity, read this quick introduction to modularity.

Before we go over a few examples of modularity uses, I want to talk about the reusability of the engines you will create.

The idea is that instead of building a monolithic application, you will build your own Devise and Active Admin gems/engines. Like this, you will have a catalogue of engines that you can reuse in different applications.

For example, you might end up with:

An User engine that deals with user creation and login
An Admin engine to represent your admin panel
A Payment gateway engine

These engines could be added to various Rails applications and customization could be added on top of it, directly in the parent app or in new engines.

For a task management application, you might do the following :

Add your User, Admin and Payment engines
Create a new engine to contain the Task feature

And you would have your new app ready in no time! That’s the power of modularity.

Web Agency & Freelancer

As a web agency or a freelancer, you probably build a lot of Ruby on Rails applications. And a lot of them probably share the same logic and features. By creating a set of engines, you will reduce the amount of work for each project. You will still have to do some customization obviously, but you will save a lot of time!

Since your client’s projects will share the same engines/gems, it’s easy for you to provide bug fixes and improvements for ALL your clients at the same time.

Generic Application

Another good case scenario for modularity is a startup creating some kind of generic application with a layer of configuration. That probably sounds abstract so let me give you an example of such an application. Take the Stack Exchange network. If you’re looking to build something like that, then modularity is your best friend. You would probably have a set of modules present in every application in your catalogue. Then, you’d have some specific modules added on top of them to customize the application for a specific niche. Maybe for one application, you want a rating system, for another one you want to have commentable questions and answers and so on. All that can be achieved by building modular applications and using Rails engines as modules.

The Spree e-commerce project is an open-source project built in a modular way that let you create and customize e-commerce applications. Check it out!

Extendable Application

Spree is also built in a way, just like Wordpress, that allows users to create extensions/addons/plugins. By creating a modular application from the start, you will have to think about extending your own code in your future modules. That means thinking about hooks and things like that. That’s all about ‘eating your own dog food’. You’re building for yourself but also for everyone else who want to provide additions to your software.

Hybrid Application

Obviously, you don’t have to go all-in. By using gems like Devise or Active Admin, you’re basically already using modules inside your application. The idea is to separate the rest of your application in the same kind of module and make them reusable. The good thing is that you don’t have to do it for all your application. Find the pieces that you could reuse for other apps, and extract these small bits one at a time. Don’t hesitate to make this code open-source if you think it can be useful to other people!