Rails - Multi tenant application with customization framework

Question

I am organizing a multi tenant application with a single code base/application using subdomains to detect the tenant, then runs a SET SCHEMA on postgres to do the fun stuff.

My issue is that certain clients will require various levels of customization to the main codebase. Not a ton, but certainly enough to the point that I wouldn't want to start hacking the main models and controllers by adding a bunch of if statements.

Overriding views is easy enough with views load paths... but my question is: How can I provide a good framework for overriding or adding functionality to the base controllers, models and helpers to tweak things for each tenant as needed? Ideally it should be pretty seamless and not invasive to the main code, and should provide a decent mechanism for organizing the customized code.

I've investigated a few options, including using includes/extends (mixins). The issue is that in production, methods stay in the objects (understandable). I've tried hte mixology gem to work around this, but it doesn't totally work as I had intended and its a bit more invasive than I'd like it to be, I'm also unclear how to relate it to models (in the controllers I just tried mixin/unmix via before/after filters).

If anybody has any ideas on how to best approach/solve this issue, I would greatly appreciate your feedback. FWIW this is Rails3

Answer 1

If you're talking about switching databases on the fly between requests then I think you're in for a world of hurt, at least when it comes to using ActiveRecord. This will mess up the caching system severely as it remembers things based on ID, not ID + Schema, which could result in cross-contamination.

Generally, from an architectural perspective, it's best to partition your database internally and have every record scoped accordingly. For instance:

class Site < ActiveRecord::Base
  # Represents a site or installation of the application
end

class User < ActiveRecord::Base
  belongs_to :site
end

Link everything up to the main Site record, or whatever term would best describe the method you use to partition. Maintaining a consistent scope is far easier than switching schema.

If, for reasons of scaling, you want to split the database in the future, if you've been careful to tag all of a site's associated records with a consistent site_id column, you can easily transpose all of these records to a new database.

Answer 2

Would a hooks + plugins setup meet your needs? ie: build the additional functionality into another model, on whatever actions you need to modify check a hooks table to see if the user requires any extra actions, hooks table also specifies the action to take so you could easily setup different configurations for different users.

If you found a better answer to this please update.