Rails: configurable extensible modular application

Question

I'd like to use Rails to build an extensible modular application that can be configured to match one's requirements.

Let me explain what I understand under "extensible" and "modular". For example, let's say I'm working on a blog application engine and I have a model named BlogEntry that contains, well, what a simple blog entry normally contains - title and content. Let's assume I want this application to be able to run in 2 modes:

• With simplistic BlogEntry having only 2 attributes - title and content
• In enhanced mode - when BlogEntry is extended to have more attributes, for example, it would be linked many-to-many with separate models named Tag.

My goals are:

• Letting end user deploy an application in either basic form or extended functionality form using some simple mechanism, such as installing additional package, enabling / disable configure switch, uncommenting a line in config file, etc. Of course, there could be much more than 2 "modes" - these additions are mostly independent and several of them could be enabled simultaneously.
• Clear separation of codebases - one that implements only basic functionality and one that implements additional pluggable stuff (such as additional attributes for existing models or new models); these changes should be propagated not only in models itselves, but also should be reflected in controllers, in views, in gem requirements, in tests, in routing rules, in database migrations required to support extended functionality models, etc.
• Have some object-oriented principles used for models, controllers and views: for example, basic model BlogEntry is just a simple standalone class, when plugging tags functionality includes some sort of enhancing module in BlogEntry class, adds some code to BlogEntryController and even adds some output in certain designated places in views of blogentry.

Thus, if one doesn't want any complex functionality, application stays pretty simple and basic. If one wants extras, application can be extended with several plugins and thus it doesn't end up a huge one-app-that-does-everything bloatware.

In fact, such pluggable functionality exists in virtually any major high-level web development platform, for example, MediaWiki, Moodle, WordPress, etc.

Searching for "modular rails" so far yielded:

• Rails engines - basically, if I understood correctly, it's a method to separate big application into several smaller, quasi-independent applications and build links between them - that's not what I want. This also allows reuse of some common Rails code in several different application, which again is not what I want.
• Rails plugins - basically, a mechanism to easily include external libraries in forms of gems into a project (with additional bells and whistles, such as plugin-provided generators) - but it's a solution for a developer which requires extensive integration with plugin. This generally won't fit good in a scheme where end-user admin has to decide whether he wants this functionality or not - there's not simple configuration process to either enable or disable it.
• Application templates - basically, a ready-made application wrapped in a generator to be able to generate applications like that quickly. This might be useful for code reuse, but has nothing to do with configurable modularity concept.

I bet there are zillions of ways to achieve what I'm talking about. What would be the best one? Where can I see a good example of such modular application?

Answer 1

I think Rails Engines is indeed what you want.

I have contributed to several applications that are delivered as Engines to accomplish basically what you describe. Here's one of them which is mainly developed by me: http://github.com/team-umlaut/umlaut

It's not always entirely straightforward, there are a bunch of places where you need to make decisions about how you are going to set things up, and Rails documentation or obvious conventions don't neccesarily guide you. I agree that the (very limited) Engines documentation doesn't neccesarily lead you down this path. But Engines are sufficient to do what needs be doing. Also give you enough rope to hang yourself and over-complicate things.

I would recommend creating an Engine skeleton with rails plugin new name_of_engine --full -- but not --mountable. I think --mountable is over-complication without benefit for this particular kind of engine use case. (Others might disagree; yeah back to that thing about choices and best practices not always being clear for this case).

Rails plugins are basically deprecated; the only kinds of plugins currently supported are plugins-as-gems -- of which an Engine is the most powerful kind (that can do the most kinds of interactions with Rails), which you will want for this kind of thing.

And I agree with you on why app templates are not sufficient here -- although you might want to supply an app template to create an app with your engine in the gemfile to it and any neccesary local stubs generated in the local app. I did that in the latest version of umlaut, but didn't until recently, it's not strictly necessary and I would leave it until after you have at least a basic proof of concept.

Rails doesn't neccesarily encourage this, but it is possible and works out with enough work, and I agree with you is appropriate for certain things.