Distinguish between workspaces

[bennylope]

From #238

This is not an issue. I'm trying to find a solution and hope to get an answer here.

Users can register on my website with an e-mail address. After logging in, users can create workspaces.

Team members can be invited to each workspace. The team members can only see the team members in this workspace.

The user can then switch between the workspaces.

For the separation, I've seen sites create a different subdomain for each workspace:

david.example.com
james-smith.example.com
lucy3.example.com

Are there other options? I saw on a website that they don't use anything like that in the URL or in the links. I wonder how they can tell which workspace the user is in. Can you give me some keywords so I can continue searching.

I would like to know if this is the right place for my project.

I also saw that there is a package django-tenants. Would that be more suitable for my project?

• @tildebox

Yep, there are several options for doing this. Each has advantages and disadvantages ("it's tradeoffs all the way down" ™️)

1. Subdomains is in someways an obvious choice. It's an especially good choice if you want to use middleware to identify the organization (which is what the aforementioned django-tenants uses) or allow custom content hosting (e.g. allow customers to use a CNAME record to point to their microsite)
2. A session value is another choice. That website you saw with nothing in the URL was probably using this. This requires a mechanism by which the user chooses the organization they want to use (whether clicking a link or preferably making a POST request) and then your app sets the organization in the session and checks that session value when making organization related queries.
3. The default way django-organizations works, or at least the views, is with a URL path parameter, e.g. an organization slug or ID. You could still use middleware to identify the organization, but the views here check for a named path parameter.
4. You could also use a URL query parameter - wouldn't recommend this, but you could.
5. As with a session value, you could store this in a JWT and/or pass as a separate header value in requests. This makes sense only in limited situations, i.e. where you're already using and dependent on JWT.

django-organizations views are premised on the third option above, but there's nothing stopping you from using any other strategy. I exclusively implemented with subdomains when using the predecessor to django-organizations. Those sites also entailed public-facing, organization specific content where we wanted to support serving over customer domains. Since then, for most of the applications I've worked on using a path identifier (e.g. slug, ID, GUID, etc) has more than sufficed.

What about django-tenants? I have sadly not used djagno-tenants myself, but I've given it a few serious looks; the use of separate schemas is very attractive as it provides a nice fail safe where you basically can't query the wrong data. However the project and the strategy come with tradeoffs. Most of the multitenant SaaS applications I've worked on are not just multi user but mutli-account per user. Nothing stopping you from doing that with django-tenants or separate schemas! However in practice this usually means some kind of mixed data presentation, e.g. a user seeing multiple resources owned by different organizations to which they have access. This is simpler with a common schema. I've also been warned off by second-hand war stories about migration issues with per-customer-schemas. YMMV! I would not discount django-tenants or the per-customer-schema model without taking a deeper look yourself (or if you're not using PostgreSQL).