Different resources on central/tenant domain using stancl/tenancy
Hello!
I'm using stancl/tenancy with Filament admin and i'm trying to figure out how to have a different set of resources/pages/widgets for for the central domain and the tenant domains. Is it possible to have as structure like this:
App/Filament/Central/(pages, resources, widgets)
App/Filament/Tenant/(pages, resources, widgets)
And load the correct path conditionally based on the current context? Any help would be much appreciated!
22 Replies
Is this doable? I was also thinking about using policies, but the above would make things a lot more easy. Has anyone a idea?
maybe #multi-context
in v3 this is basically built-in
Will it include multitenant database (each tenant has separate db) ?
uh no
i dont like that structure lol
its often used by people who overthink performance, they forget that databases were built to scale to millions of rows
Oh no... "its often used by people who overthink performance" 👈 you're right 😔
yup 😂
just do a team_id or tenant_id column
you think google has a database for each of its users?
Yes, currently I use this...
I was thinking that the db will be very tired searching and filtering for "user_id" over and over again... 😵💫
well its much better than separate databases
use a global scope if you dont want to filter over and over
Yes I use global scope... well, many thanks... I think this thread must back to the owner's topic... 👌
Thanks for both your input! Never seen #multi-context think this will do it. Thanks.
Not sure about stancl/tenancy, but have a look at #multi-context
Oops, the other messages only loaded now 😅🙈
Is #multi-context reliable? Maybe you're using it
I haven't had the need for it so far
Just to jump in here! I am actually using multidb (stancl) and there is a valid reason for GDPR and compliance Reasons.
Just some of my thoughts maybe why it is worth a rethink over the performance aspect.
1. Multi Db/Tenant allows me to regionalise my data so clients comply with data compliance etc. (EU DB Server & US DB Server also Australia, Asia all have diiferent laws regarding data storage)
2. 1 database goes down i don't lose the entire platform.
3. Simplification of data separation.
4. Ability to easily offer export of data for end user.
5. Easy to manage data migration for enterprise clients who want customisation.
I do understand there is workarounds but multidb can be extremely useful.
Just my 2 cents 😄 @danharrin @Dennis Koch
Hi @Sander , I do exactly this using laravel modules
yeah those are very valid reasons, i think theres a point in an enterprise environment where its worth it, but for people starting out it probably isnt. is that fair?
I think the biggest thing even for non enterprise is the regional issue, If we are making an app we have to comply with EU and US laws, and for us it is essential to split the databases to have compliance.But that being said i do get that for many that is not an issue as they wont be marketing globally, but i dont think its a small percentage that it impacts not to have multidb
yeah but regionalising the db doesnt mean that everyone needs their own db, you can still have multiple tenants in one db
its much more complex to have to provision separate databases regionally on demand
Agreed! It could be done with 1 db in each region, i think though there is still advantages to the data segregation at a tenant level - its just my use case though and makes life easier as there is almost zero chance of tenant data crossover.
Thanks @cvc_web will look into Laravel modules! @danharrin Are you saying that this is "natively" possible in V3? If so i'll wait for V3 as i'm still building the Tenant side admin/functionality.
yes there is tenancy in v3, but you can still build your app in v2 and then migrate later
the rest of your app should take the most time to build so you should still do that
Thanks, alright, can you confirm the dynamic resource path part? 🙂
ping @danharrin
yes