v4 Roadmap

[stancl]

Update: Version 4 is now in early access, see the #announcements channel on our Discord

Hey everyone,

Soon (in a few weeks) I'll start working on the next major version of Tenancy for Laravel.

v3 has worked extremely well, with me writing most of the code in spring 2020 and very few changes being needed for a year. The core is really solid.

That said, there's always room for improvement, which is what version 4 be focused on.

Currently, I have these changes planned:

• Fix all of the unresolved bugs. Most aren't fixed yet because they're low-severity in impact, and high-complexity in fixing. Some would require changes to the codebase that'd result in breaking changes, hence the major version.
• Improve the documentation. Both UI-wise and content-wise. I'll try to write more step-by-step guides for implementing common features and improve the structure & writing of the current pages.
• More compatibility with the ecosystem. Jetstream, route model binding, API auth packages, and more.

In short, the major version won't have too many changes, and most will be quality of life improvements.

But those are my plans. If you would like to see any new features or changes, please share them below. I'd love to hear any feature suggestions or other feedback, because I'll be working a lot on the package now, and I'll have a chance to work on features that would normally not be possible to add due to breaking changes.

Thank you!

[kengraversen]

Samuel - thanks a lot for all the great work you put into this. I completely agree with your priorities. Security, stability and compatibility are for many the most important factors. New features are less important and historically a source to problems with the three mentioned areas.

[dzymail]

Great news, Thank you for providing such a good package.
looking forward to the new version of the SaaS template. I hope the template can fit the following situations out of the box:

1. In a tenant, users can belong to multiple Jetstream teams/groups and have different team roles and permissions in different teams/groups.
2. limit how many members a team can have by subscription.
3. one user can have multiple profile types.
4. connecting Google account or Facebook/Microsoft.
5. more payment providers.

[alexrififi]

It would be useful if the connection name used in trait TenantConnection is taken from the config

tenancy/src/Database/Concerns/TenantConnection.php

Line 11 in 54a33f9

return 'tenant';

[stancl]

@medvinator What benefit would that bring?

[alexrififi]

@medvinator What benefit would that bring?

Convenience when working with code.
I creating service with 3 app level: director, partner and client

Partners are tenants of the director (implemented by package spatie/laravel-multitenancy).
Clients are tenants of a partner (implemented by package stancl/tenancy).

Each partner and client has its own database.
There are several models that are common for both the partner and the client (for example, webhooks).
Therefore, there must be a different connection, it is implemented like this

    public function getConnectionName(): ?string
    {
        return match (level()->current) {
            'director' => 'director',
            'partner' => 'partner',
            'client' => 'tenant'
        };
    }

As you can see, it would be convenient to name the connection not tenant, but a client and do so

    public function getConnectionName(): ?string
    {
        return level()->current;
    }

It would be possible to call the client's level a tenant, but this would potentially add confusion.
Thank you for your attention and a wonderful package, I hope I explained clearly.

[cyrillkalita]

I was wondering a little about about the structure of App\Providers\TenancyServiceProvider
Would it make sense to extract Pipelines into into own namespace? Something along the lines of:

        ....
        Events\TenantCreated::class => TenantCreatedPipeline::class,
        ....

So that ServiceProvider gets less crowded?

[jcs224]

I would love to see an implementation of Postgres Row Level Security.

Right now, there is a trade-off with the current options of multi-database vs. single-database tenancy.

• Multi-database: easier app development, higher ops complexity
• Single-database: less ops complexity, have to add more tenant-specific code to your app

Postgres RLS: Best of both worlds without the drawbacks?

Since you can already separate the tenants by schema rather than full DB for Postgres, perhaps implementing an RLS version is feasible? It seems like the holy grail of lower ops complexity but not having to worry about so many WHERE clauses.

AWS blog has a great article about RLS and multi-tenancy specifically:
https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/

[stancl]

@jcs224 That's a great suggestion. I'll definitely try to do that in v4!

[a-ssassi-n]

Is this getting solved in v4?
#645

[stancl]

Yes

[mannieg]

@stancl Thanks for the great package. I was hoping V4 would improve performance with testing.

[pilishen]

expecting a dramatic performance boost with Octane supported in V4

[stancl]

You shouldn't really. Octane is nice, but I don't think it'd provide a dramatic boost in performance for almost any applications. Proper database performance practices will go a lot longer way.

[Sn0wCrack]

One thing I'd be interested in is a way to manage a Tenant's resources within the central application's Nova, especially if they could be included in a similar way to how Nova's relationship fields worked.

It would be very nice to be able to see a list of all users configured in the tenant portion, it could be very handy in combination with the User Impersonation feature, as you'd pretty easily be able to create an action to impersonate a user and redirect to the tenant's application.

[ohnotnow]

Tiny little thing - but it would be nice (for me) to be able to run something like php artisan tenants:migrate --with-main or something that also ran your 'normal' migrations.

[cyrillkalita]

@ohnotnow you can always extend the command, no?

[stancl]

I think putting php artisan migrate && php artisan tenants:migrate in your deployment script is the best way to go about this

[ohnotnow]

It's more for places you're doing docker/k8s things. You can have a pod that runs your migrations like

  ...
        command: ["php"]
        args: ["/var/www/html/artisan", "migrate", "--force"]

so you can only have one 'command' and it doesn't understand shell things like &&. It can be worked around fairly easily, and as I say - it's a tiny little thing. Just be handy. Possibly only for me I admit :-)

[alexrififi]

@ohnotnow just wrap two commands in one

[ohnotnow]

Yeah - I know - it was just a tiny little suggestion to save a tiny bit of work (for me) :-)

[cyrillkalita]

.. and file storage is now something that can be build at runtime:

laravel/framework#37720

[stancl]

Cool, we're already doing that using lower level calls but this provides a nice API for that

[darkons]

Improvement:

Tenants table migration have onDelete cascade reference to delete its domains. This is good but you can't use Listeners on DeletingDomain/DomainDeleted events to perform your own actions.

The proposal is remove onDelete cascade reference and use TenantDeleted pipeline to perform domains deletion.

Apparently it is not necessary to do the same with onUpdate reference, but it might be good to remove all database cascade references and get full control through Events.

[MrHaroldA]

I'm still a novice at Tenancy, but this is what I would like, or what I did not find yet ;)

1. Table prefix Tenancy.
2. Tenant identification by bearer token (Laravel Sanctum / API).
3. Automatic removal of created databases in tests.

I know this is probably easily implemented in custom code, but if you're going for a great out-of-the-box experience, these might be nice additions.

[Intrflex]

I'm still a novice at Tenancy, but this is what I would like, or what I did not find yet ;)

1. Table prefix Tenancy.
2. Tenant identification by bearer token (Laravel Sanctum / API).
3. Automatic removal of created databases in tests.

I know this is probably easily implemented in custom code, but if you're going for a great out-of-the-box experience, these might be nice additions.

1st one already exists in tenancy config files :), API identification is quite easy, just implement your own token system using the UUID system already built-in setup a middleware that checks the API token exists against the user and against user agents or a fingerprint of the users setup problem solved

[binaryfire]

Will v4 support Octane? And if so, will both Swoole and Roadrunner be supported?

We're building a new app using Octane at the moment and would love an easy way to add multi tenancy.

[stancl]

Tenancy and Octane could be a bit complex, but looking at how Octane separates things, it should probably work fine. I'll try to specifically test that, though it probably won't be a guaranteed feature

[stancl]

As I commented here #802 (comment), I'd really appreciate if someone could test 3.x-dev with a real world S3 setup. I'll be tagging a release tomorrow morning, so this would help a lot. Thanks!

[stancl]

3.5.2 released with Laravel 9 support 🚀

[eskiesirius]

Any updates in v4? i would like to use this in my future projects.. thank you so much!

[HelloAlexPan]

Please prioritise faster test execution, ref #250

[abishekrsrikaanth]

Will v4 support Octane? And if so, will both Swoole and Roadrunner be supported?

We're building a new app using Octane at the moment and would love an easy way to add multi-tenancy.

@binaryfire Do you currently face any issues using Tenancy with Octane? I see you have requested support and wanted to understand if there is anything that is not presently working when using tenancy with Octane? I want to use it as well and would like to know how your experience has been?

[binaryfire]

@abishekrsrikaanth Hey there. Haven't started using the package yet so I can't say. We're waiting on v4 before we add multi tenancy to our app.

[stancl]

🚀 We're starting work on v4 now. If you'd be interested in beta/early access, please email me at samuel+v4@archte.ch

Right now I'm specifically looking for people who are:

• very experienced with the package
• able to provide useful input/suggest improvements from their experience with the package
• willing to test v4 as I gradually add more things to it

Later on all sponsors will get early access to it, weeks before the main release ❤️

Thanks a lot!

[stancl]

Full announcement: https://archte.ch/blog/june-2022-update

[anburocky3]

Full announcement: https://archte.ch/blog/june-2022-update

Any ETA?

[bdsumon4u]

Full announcement: https://archte.ch/blog/june-2022-update

We're very excited. Can you please tell us an estimated time of arrival?

[Allgoodnamesargone]

What's up with the Octane support?
I have seen several benchmarks indicating it makes application at least 3x faster.
But i prefer my largely used application be slower than buggy and messy.

And oh, THANKS for the package and the continuous support.

[stancl]

Octane support is something we want to look into but it probably won't be an official/guaranteed feature.

I don't think Octane has that much benefit in production apps.

it makes application at least 3x faster

It might speed up your application, but the main part that slows down production apps is the network, not the app. The app can take 30ms to compute a response but you'll be dealing with 100ms request latency.

[J5Dev]

While I may seem like I am asking for an ETA on V4 (an I maybe kind of am, lol), but we are wanting to start working on an iteration of our existing application which supports MT, and of course would love to be using this package as a number of our team have used it before, so have an aspect of trust with it's capabilities.

My issue is timelines and company expectancy. I would love to just hold fire and go at V4 from the off as it would of-course be cleaner, however I also don't want to have a team idling while we wait for the release... hence my following question.

Given the ETA could be some time (I'd rather it was and not have you guys overworked and rushing stuff out), then what is the current thought on what the upgrade path will look like from V3 -> V4? As in, would it be viable to start a new project now on V3, and just do the upgrade when V4 lands given it would be a minimal upgrade, or, would we potentially face a 'easier to redo it all' situation when V4 lands due to a more complex upgrade path.

Very keen to hear your thoughts on that side of things... or an ETA date of course 😜

Many Thanks

[stancl]

The upgrade path will definitely be very straightforward, especially with multi-db tenancy

[J5Dev]

The upgrade path will definitely be very straightforward, especially with multi-db tenancy

Thank you very much for clarifying, I will get started and look forward to getting stuck into the package :)

[ollivr]

Hello, I was an early sponsor and also the boilerplate . I'd love to take a look at the early access version if possible.

Thanks,

Erik

[captchapays]

Full announcement: https://archte.ch/blog/june-2022-update

Any estimated time of arrival, please please please?

[stancl]

Early access to v4 for sponsors likely within a few weeks

[wskeee]

Hey, it's great to use your code. One small suggestion I have for using this is that when you customize the tenant_id field, it can be placed in the configuration file so that you don't have to worry about it being replaced when the code is updated.

If you'd like to customize the column name to use e.g. team_id instead of tenant_id — if that makes more sense given your business terminology — you can do that by setting this static property in a service provider or some such class:

use Stancl\Tenancy\Database\Concerns\BelongsToTenant;

BelongsToTenant::$tenantIdColumn = 'team_id';

Note that this is universal to all your primary models, so if you use team_id somewhere, you use it everywhere — you can't use both team_id and tenant_id.```

[stancl]

Static properties used for configuration are of course equally backwards compatible as normal config keys, so there'd be no difference. But yes, in v4 we moved a bunch of them to the config file.

[eskiesirius]

Can't wait for the v4..

[atapatel]

Eagerly Waiting for V4

[bdsumon4u]

Waiting...

[stancl]

As mentioned on Discord, early access for sponsors will be opening before the end of this month.

[sinamiandashti]

is octane supported or not?

[stancl]

Locking this now since v4 early access is open to sponsors. New feature ideas can be submitted as issues or mentioned in #tenancy on Discord.

For details about the early access, see #announcements on our Discord: https://archte.ch/discord

[stancl]

v4 is now mostly finished, we're working on the final major feature now. After that it's just some refactoring, writing new documentation, and working on the new boilerplate.