5 ms·

What is the problem just build it your self. A simple template that has a login with a todo list can be extended to have a companies table. When you have added

What is the problem just build it your self. A simple template that has a login with a todo list can be extended to have a companies table. When you have added this, you can add a n to n relation between companies and users and poof you have a B2B saas app template.

x3haloed 6y ago
I think the request is more for guidance about how to do it right.
- JoeSloth 6y ago
  I’ve been trying to find some guidance too, specifically for authentication with B2B and how to be adaptable to work with different IAM/SSO platforms
eloff 6y ago
Having built a number of these, it's not that simple. For example do you put a tenant column on every table, have a separate table per tenant, or have a separate schema or database? There are tradeoffs for each approach and lots of gotchas you wouldn't expect. Like if you use a separate table or database, migrations take forever, you can run into file descriptor limits in your database, etc.
- balfirevic 6y ago
  That's true, but just looking at the code of some example application you've found online won't shed any light on what those trade-offs are.
  - eloff 6y ago
    Probably not, but there are articles on the subject that are helpful. I've found them before.
- wolco 6y ago
  Separate table per tenant? Not unless you have/expect 2 to 5 tenants otherwise you run into the issues you describe above. Having a database per tenant has always interested me. It make sense if the databases will be different (contain other tables) Adding a tenant id to the tables that require them makes sense. The best approach is to create a pivot table between users and tenants that holds user_id and tenant_id. Use the primary id of that table to represent the user at that tenant.
  - eloff 6y ago
    The limit is a lot higher than 2 to 5, but I think sooner or later it will get you. Until then you will suffer a slow death by a thousand migrations. A separate database is best used if you need an absolute firewall between the tenants for security reasons. Almost no bug can ever let one tenant see the data from another. If they share tables, it's easier to make that mistake. The downside is you can't have quieres across all your tenants, so you'll want a BI database that brings all the data together anyway.
- ozim 6y ago
  This leads to answer, which is: just start building, whatever option you will choose you will run into gotchas. So no point of overthinking it.
  - eloff 6y ago
    That there are tradeoffs with each option does not mean all options are equal at all. Doing a little research first, and thinking about which tradeoffs matter most in your particular case could save you a lot of effort rewriting things down the road.

x3haloed 6y ago

I think the request is more for guidance about how to do it right.

JoeSloth 6y ago
I’ve been trying to find some guidance too, specifically for authentication with B2B and how to be adaptable to work with different IAM/SSO platforms

eloff 6y ago

Having built a number of these, it's not that simple. For example do you put a tenant column on every table, have a separate table per tenant, or have a separate schema or database? There are tradeoffs for each approach and lots of gotchas you wouldn't expect. Like if you use a separate table or database, migrations take forever, you can run into file descriptor limits in your database, etc.

balfirevic 6y ago
That's true, but just looking at the code of some example application you've found online won't shed any light on what those trade-offs are.
- eloff 6y ago
  Probably not, but there are articles on the subject that are helpful. I've found them before.
wolco 6y ago
Separate table per tenant? Not unless you have/expect 2 to 5 tenants otherwise you run into the issues you describe above. Having a database per tenant has always interested me. It make sense if the databases will be different (contain other tables) Adding a tenant id to the tables that require them makes sense. The best approach is to create a pivot table between users and tenants that holds user_id and tenant_id. Use the primary id of that table to represent the user at that tenant.
- eloff 6y ago
  The limit is a lot higher than 2 to 5, but I think sooner or later it will get you. Until then you will suffer a slow death by a thousand migrations. A separate database is best used if you need an absolute firewall between the tenants for security reasons. Almost no bug can ever let one tenant see the data from another. If they share tables, it's easier to make that mistake. The downside is you can't have quieres across all your tenants, so you'll want a BI database that brings all the data together anyway.
ozim 6y ago
This leads to answer, which is: just start building, whatever option you will choose you will run into gotchas. So no point of overthinking it.
- eloff 6y ago
  That there are tradeoffs with each option does not mean all options are equal at all. Doing a little research first, and thinking about which tradeoffs matter most in your particular case could save you a lot of effort rewriting things down the road.