multi-tenancy

is multitenancy only for apps that have users?

is multitenancy only for apps that have users?

Maybe. It depends on how you define it. Think about Basecamp for an example. Each user of that system logs into their own subdomain and manages their own data, without ever being able to access or see any other user's data. Yet if you are the owners of Basecamp, you think of it as one big site, with many users. Each user can make changes to the application that govern how it will appear to their clients, and that doesn't affect another user's clients' view of the site. Think about the most popular Gem in this arena -- it's named Apartment. What does an apartment have? Individual rooms where renters can change whatever they like without affecting anyone else in the building. Yet the owner thinks of it as one big building.

So it's philosophical first, and then practical. What is the application you are trying to build? Is it meant for one client, or many users, each with their own group of sub-users? Or something else?

Walter

Re: [Rails] multi-tenancy Sunday, January 21, 2018, 5:28:17 PM, you wrote:

What can my user’s users do for me Let’s say I have only 10 users but one of those users has a large number of users What’s that do for my site? Am I gonna show my ads on their pages?

This is how I approached multi-tenancy in my application: Every user can be a part of one or multiple accounts (groups) through membership model. And because someone has to be in charge of the account (pay bills, admin stuff, etc), membership model has a boolean flag is_owner.

In application, all authenticated user routes are scoped by :account_id. After user logs in, he selects an account he want to open, and I redirect him to scoped overview page with account_id (for ex. https://example.com/123/overview). To avoid passing account_id parameter to every link on a page I set default_url_options to include it automatically.

To ensure that all shown data is part of that account, data models have account_id column, and I query those models through account association, for example:

@posts = current_account.posts

(current_account is a helper method which returns account object from params[:account_id])

And of course, I do user account/membership authorisation on every request so user could not access other accounts data by changing account_id in address bar.

Rolandas

Sunday, January 21, 2018, 5:28:17 PM, you wrote:

>> is multitenancy only for apps that have users?

> Maybe. It depends on how you define it. Think about Basecamp for > an example. Each user of that system logs into their own > subdomain and manages their own data, without ever being able to > access or see any other user's data. Yet if you are the owners of > Basecamp, you think of it as one big site, with many users. Each > user can make changes to the application that govern how it will > appear to their clients, and that doesn't affect another user's > clients' view of the site. Think about the most popular Gem in > this arena -- it's named Apartment. What does an apartment have? > Individual rooms where renters can change whatever they like > without affecting anyone else in the building. Yet the owner > thinks of it as one big building.

> So it's philosophical first, and then practical. What is the > application you are trying to build? Is it meant for one client, > or many users, each with their own group of sub-users? Or something else?

> Walter

Walter,

What's Basecamp? It sounds like something I need.

Basecamp is a project management system, initially designed for designers and developers, but taken up by a lot of different kinds of users. It was one of the first "software as a service" success stories, and (funny enough) it is the project from which Ruby on Rails was extracted. Originally built for 37Signals by David Heinemeier Hansson, before he joined that firm, and before 37Signals stopped doing "client work", it was initially used to manage the firm's client work. When they figured (correctly) that other firms could use this tool, they built the multi-tenant version, and the rest is history.

Walter