Modular Rails: F.A.Q

by Thibault - January 29, 2015

Last article in the modularity series, let’s talk about general stuff. I structured this article as a F.A.Q so if you have more questions, just leave a comment and I will answer it.

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

1. What is modularity?

Modularity is about isolating the functionalities of your application into independent and interchangeable components. With Ruby on Rails and my approach, it implies creating modules as Rails engines and build your application bloc by bloc. Ruby on Rails applications are usually monolithic.

2. Why would I want to build a modular app?

The main advantage of a modular applications is to have reusable and interchangeable components. For example, you could create a forum engine for one app and reuse it in another one. Of course, you can write more specialized engines adapted to your business.

3. When should I use modularity?

Checkout this article about Modularity Use Cases!

4. I’m building my first Rails application. Should I make it modular?

I don’t think it would be a good idea. Building modular applications requires a good understanding of Ruby and Rails. Create a few regular Rails applications before you checkout modularity and see if it fits your needs.

5. What is Modular Rails?

Modular Rails is the book I’m currently writing where I exposed everything I’ve learned in the past years about building modular applications with Ruby on Rails. You can subscribe to my newsletter below to get the latest updates. If you want to learn more about the book progression, checkout this page.

6. How should I use Git with my modular app?

The best way to organize your modular application is by separating everything in different repositories. Each module should have its own repository just like the parent application. This setup allows different teams to work on different modules and branches easily while sharing a common parent application.

7. How to reuse my modules easily?

The easiest way to share and reuse your modules is to package your Rails engines as gems. You can then push them to RubyGems and easily add them to your Gemfile.

8. What if I want to keep my modules private?

You can! And it’s not even hard. Instead of pushing your modules to RubyGems, you can push them to your own private RubyGems! It can easily be setup on a cheap VPS, making your gems available easily and privately. You can still use the Gemfile to get them by adding one line at the top specifying your private gem server.

9. How to version my modules?

The best way to version your modules is to follow the Semantic Versionning. You should give it a read, but here’s the summary:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

The full article is available at semver.org.

10. Is it hard to push a modular application live?

Is pushing a Ruby on Rails application which has a few gems in its Gemfile hard? Because that’s basically what you will be doing once you packaged your engines as gems. A modular application can be pushed very easily to Heroku or to any kind of VPS/Server.