Multi tenancy for rails and active record

The term “software multitenancy” refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance – including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.

Multi-tenant application mainly has three type of users.

1) Admins
2) Managers
3) Users

Advantages of multi-tenancy:

1) Cost savings
2) Scalability
3) Service
4) Upgrades

Examples of multi-tenant applications

Application like GitHub, where each user or organisation can have their own separate area within the application or Heroku where each user has their own separate app group.

We, at mallow tech has built a multi-tenant app for one of our client and we have used gem called “Apartment” to achieve multi-tenancy

Apartment provides tools to help you deal with multiple tenants in your Rails application. Apartment ships with cleverly-named “elevators” for switching between tenants. Apartment can support many different “Elevators” that can take care of this routing to your data.

1) Switch on subdomain
2) Switch on first subdomain
3) Switch on domain
4) Switch on full host using a hash
5) Custom Elevator

We can switch between tenants on each request but still If you have some models that should always access the ‘public’ tenant, you can specify this by configuring Apartment using Apartment.configure. This will yield a config object for you. You can set excluded models like so:

config.excluded_models = [“User”, “Company”]

In gem apartment https://github.com/influitive/apartment, we can use separate databases for each company. This makes system more secure by considering data will not be sharable to other company.

By default, ActiveRecord will use “$user”, public as the default schema_search_path. This can be modified if you wish to use a different default schema be setting:

config.default_schema = “some_other_schema”

With that set, all excluded models will use this schema as the table name prefix instead of public and reset on Apartment::Tenant will return to this schema as well.

Apartment will normally just switch the schema_search_path whole hog to the one passed in. This can lead to problems if you want other schemas to always be searched as well. Enter persistent_schemas. You can configure a list of other schemas that will always remain in the search path, while the default gets swapped out:

config.persistent_schemas = [‘some’, ‘other’, ‘schemas’]

With this information hope you would have got some idea on how to build a multi-tenant app and please share us your feedbacks, if any and we will try to get back

Logesh M,
ROR Team Lead,
Mallow Technologies.