1
5 Comments

Rails Multitenancy and/or Devise

In the process of getting my MVP out, I'm currently using Rails/Devise for users auth and basically as a way to handle multitenancy. (Controller actions check for users and make decisions based on that. E.G. If Post.user_id == current_user.id then you're the owner..etc). This works fine for me.

I've gotten some suggestions to look at Gems like Apartment that do multitenancy. I'm little confused because isn't what I'm doing multitenancy? I don't need subdomains (which looks like 90% of that Apartment Gem is all about). Is handling multitenancy through Devise alone a good/strategy?

  1. 1

    In your case, this is not multi-tenancy. To give you an example in your case of multi-tenancy you could have a new tenant for each user. With this new tenant, you would basically not have to check Post.user_id == current_user.id but you could simply get all the Post in the user's tenant with a Post.all and only the ones of the user would be returned.

    Multi-tenant application is great in SaaS products so like that you make sure that data are separated between your users and it might simplify a lot the codebase avoiding a lot of checks like the one you describe.

    There are still some things to be careful about multi-tenant. First, it will be complicated for you to get all the data of all your tenant at once eg: all the posts of the platform for all users. If you application really needs to have scoped data for each user (or it can be a tenant based on anything you want) then tenants might be a good solution but if not and you just want to check the authorization then this is not the best use of tenants and it that case I would recommend having a look at gems like https://github.com/CanCanCommunity/cancancan

    1. 1

      This is exactly what I'm trying to figure out. I've never used multitenancy before, so I assumed those types of actions are tricky.

      My app will need to know things like 1). most liked post (through every tentant) 2). search for posts tagged with X (through every tentant).

      For my app, I don't need customizations per tenant, or subdomains. In my case, I'm trying to weigh the benefits of going multitenant: queries will be quicker? Don't have to manage authorization at app level.

      1. 2

        The subdomain is something required for a multi-tenant database (it's a nice feature in a saas product but independent of the multi-tenant).
        If you need to access to the data of all the tenants, then the multi-tenant might not be a right solution as in a simple approach you will have n queries for n tenant that can be done in 1 query with no tenant, so if you have a tenant per user, then it might be inefficient.
        If, on the other side, most of your queries always contain a reference to the same entity (user, for example) and you have to do this filter everywhere in your codebase then the multi-tenant might simplify your codebase.

        I would recommend starting with no tenant, and if later on, you need it, then migrate your application to multi-tenant. The migration no tenant to tenant is smooth, while the other way around is complicated and might be risky.

  2. 1

    What you do is not multi-tenancy — it is when you have a scoped database that user from outside of the scope won’t have the access on the database level to the data.
    What you do is just check on the data level.

Trending on Indie Hackers
Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 18 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments