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

https://github.com/archtechx/tenancy/blob/54a33f93a85a5e0a4d53ac48fabacd8ebb716eec/src/Database/Concerns/TenantConnection.php#L11

[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? https://github.com/archtechx/tenancy/issues/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:

https://github.com/laravel/framework/pull/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

[Sn0wCrack]

If suggestions are still open, perhaps some kind of Laravel Scout integration?

[pilishen]

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

have been using Octane and Tenancy V3, since Octane releases a couple of months ago, yeah, it works fine. haven't caught into anything buggy or weird stuff until now. back then, I had used laravel-swoole-tw with Tenancy V3, there were some clear gotchas though hope you can go through all those specific tests and make this happen, or maybe list out things that should pay attention to when integrating octane. great thanks

[stancl]

FWIW I don't find Octane to be that useful for 99% of apps, and tenancy seems like the single most dangerous thing to use with Octane. Sure, Octane does separate Container state well, but some code may use other forms of global state and with Tenancy it's best to separate tenants as much as possible to avoid any risks. For the same reason I'd also generally use Vapor and cloud based services like S3 rather than hosting multiple tenants on the same stateful server.

That said, I'll try to make sure it's supported, but it'll always come with a disclaimer.

[plakhin]

@stancl, any approximate release date? at least for the beta

[stancl]

After Lean Admin is launched in a few weeks, I'll be working on the new SaaS boilerplate and v4 will be released alongside the boilerplate 👍🏻

[chillbram]

You already said you would look at it for v4 on issue #250 itself, but for overview purposes: having a solution for slow tests documented and in the boilerplate.

[plakhin]

You already said you would look at it for v4 on issue #250 itself, but for overview purposes: having a solution for slow tests documented and in the boilerplate.

Check https://github.com/archtechx/tenancy/issues/250#issuecomment-927124384

[Surt]

Packages in vendor for the tenant application are not migrated since the configurable path by default uses "database/migrations/tenant"
Having to manually define the multiple packages on the path configurable is not good (hardcoded code)

And this one is just an idea:

Would be great to have an API with it's own routes etc on the library. This will lead to the posiblity of creating a product like "Saas Boilerplate" but a SPA one. No need to install on your application but as a separate application (which connects through a new API to the central database). With this it would be easy to create a SPA SaaS boilerplate installable with a simple docker image and fully independant of the tenant application)

[binaryfire]

@stancl Will Lighthouse-php be supported?

Also +1 for API endpoints. That'd be really useful for deploying tenants across multiple servers.

[maxvrdev]

If you need any help with getting Version 4 released, please let me know. I can help with testing, bug fixes, etc....

[bdsumon4u]

After Lean Admin is launched in a few weeks, I'll be working on the new SaaS boilerplate and v4 will be released alongside the boilerplate 👍🏻

It's almost 6 months since you announced that 'v4' is coming. The announcement of 'Lean Admin' is also 10 weeks past. Nothing is released yet. Can we get an estimated release date, month, or year for any of these?

[stancl]

The projects (mainly Lean, with the rest depending on me finishing Lean) got delayed due to a couple of reasons, yes.

Can we get an estimated release date, month, or year for any of these?

Not with this tone. I mean, I could provide some (more accurate) estimates for those projects, but I don't want to incentivize requests written in an entitled tone.

[stancl]

Created a project here which will include all of the open issues and PRs that I'll deal with in v4.

Some of them are bugs that can be addressed in v3 as well, since the fix will be the same. But in general, all feature additions will be in v4.

[stancl]

Would appreciate some feedback on this issue, if you'd like to see the feature in v4: https://github.com/archtechx/tenancy/issues/752

[stancl]

For context: when I'll be working on v4, it'll probably be in this order:

1. Resolve issues related to the queue. I realized that we could use SerializesModels even with tenant models, but we'd need to make some small changes, possibly to Laravel itself. I'd like to do this before L9 RC1 is tagged
2. Resolve issues related to routing — Fortify/Jetstream integration, constructor DI issues, etc. I'll either try to change a bit how the Laravel routing works, or I'll introduce a new middleware-like abstraction in the package (or a separate package) to support what we need
3. Resolve issues related to filesystem tenancy — there are some minor bug reports open, and I'll need to rewrite the filesystem bootstrapper anyway. It was poorly documented in v3 and only referred to the v2 documentation, since the code was mostly the same. But even in v2 it wasn't implemented very well. The code is a bit ugly, and in Laravel 9 obsolete anyway, since it's using flysystem 2.x which has incompatible syntax with our filesystem bootstrapper
4. Work on all of the open issues that have been added to the v4 project
5. Write completely fresh docs, and tag v4

Points 1) 2) 3) aren't separate from the open issues, they'll actually close like ~5 issues that are open right now.

For the 3.x branch, I'll resolve these tasks, and everything else will be done in v4.

v4 will required Laravel 9 and therefore PHP 8.0. Depending on how good the ecosystem support is for 8.1 when I'll be working on v4, I might even go for 8.1. It'll only be used on new projects or projects that stay up to date (Laravel 9), so the PHP version change shouldn't be an issue.

That said, I wouldn't go for 8.1 in a project right now because it's still a bit rough to use. Composer shows a lot of deprecation warnings, some IDEs don't fully support the new syntax, and other minor ecosystem-related things like that.

[dzymail]

Will there be allow turning off default personal team and make teams with hierarchy?

[moisish]

hey @stancl

First of all thank you for the great package. Do you know when you will be ready for Laravel 9? Will that be on v3 or v4?

#545 I am interesting into this issue, so I would like to know if that will be solved in v4 or if should try to solve it based on https://tenancyforlaravel.com/docs/v3/early-identification/#using-a-more-complex-middleware-setup

Thanks again

[stancl]

For now I recommend following the guide in the docs.

v4 will come out a few weeks after Laravel 9. With v3 only supporting Laravel 8 for now.

I might end up adding L9 support to both v3 and v4, but I'm not 100% decided yet. There are some larger changes I'd need to make to support both L8 and L9 in the same version of Tenancy, so I'll take a look at those when L9 has a stable release.

[moisish]

@stancl Ok thanks for the prompt reply. I believe I can fix the binding issue tbh. I am more concern into L9 support which I would like to update my app as soon it gets released (stable).

Right now that's not possible with v3 and with v4 being available weeks after L9 release I think you will have to update v3 to support L9. Otherwise we will have to fork the package for some time :/

[stancl]

What's not possible with v3? Laravel 9 compatibility?

Is there a reason why you'd need to use L9 immediately after release? I think L8 will still have decent support for many months

[moisish]

L9 will be the LTS version plus I would like to get to the most up to date version with all the goodies

[stancl]

I see. In that case I'd just stick to L8 and upgrade later on — Laravel upgrades are generally very easy.

As for maintaining a fork, the reason why we can't have L9 support straight away is that concrete (and potentially complex) code changes are needed, so it's not as simple as changing the composer.json file. You'd have to handle all of this yourself if you wanted to have a fork.

[plakhin]

I'm also looking forward to upgrade to L9 ASAP. However, I'd rather upgrade tenancy package to v4 first so Laravel upgrade goes smoothly. This package is the only one that keeps us from upgrading. What can we do to speed up v4 release?

[CodeSkills]

Is it really necessary to support L9 only in v4? I think that we are not the only one who would love to already upgrade to L9 even with v3 with L9 support, what are the concrete (potentially complex) changes that need to be done?

I think that if you would make a list of the tasks needed for L9 to be done, the community would help with PRs for them.

I don't want to sound pushy or anything, but v4 looks like it won't be any time soon, so it would be nice to consider the option above.

Even Laravel Nova just updated their v3 to support L9 even when there is a full workload on v4 which will come in later on.

[eugenefvdm]

In my opinion the topic of L9 support is mute. The reason is doing your own upgrade from 8 to 9 is really not such a big deal. It's a bit technical, but if you're lazy like me you just use Laravel Shift. I upgraded V3 of the boilerplate from L7 to L8 when that wasn't available yet, and it worked perfectly. I'm quite sure just sending it through Shift again will do the job. Then once the "official" upgrade happens it shouldn't be that hard to compare notes. Anyway, just me 2c.

[stancl]

what are the concrete (potentially complex) changes that need to be done?

The main thing is updating the filesystem bootstrapper to use the new flysystem. There are different versions in L8 and L9, with completely different syntax. So if v3 were to support it, it'd need to check the Laravel version and execute different code.

If you'd like to see L9 support in v3, you can contribute the bootstrapper and I'll see if there are any other large changes needed.

[CodeSkills]

After reviewing the Filesystem bootstrapper i don't think there is much to upgrade if at all. Will try to look into it more later :-)

[stancl]

Also see https://github.com/thephpleague/flysystem/issues/1389

[scaabel]

@CodeSkills how far along are you with the upgrades? If you need help feel free to hit me up.

[michaelnabil230]

When is a version that supports Laravel 9 expected to be released? @stancl

[stancl]

If someone wants to PR the needed changes to make v3 work with L9 (w/ backwards compatibility), v3 can support L9 earlier.

Otherwise, it'll be either when I find some extra time (probably in the weeks after next week) to try adding this, or in v4.

[Yunlong2cn]

// Storage facade
Storage::forgetDisk($this->app['config']['tenancy.filesystem.disks']);
foreach ($this->app['config']['tenancy.filesystem.disks'] as $disk) {
    
    $root = $this->app['config']["filesystems.disks.{$disk}.root"];
    

    $this->originalPaths['disks'][$disk] = $root;
    

    if (!$root = str_replace(
        '%storage_path%',
        storage_path(),
        $this->app['config']["tenancy.filesystem.root_override.{$disk}"] ?? ''
    )) {
        $root .= '/' . $suffix;
    }

    $this->app['config']["filesystems.disks.{$disk}.root"] = $root;
}

Is it necessary to keep the adapter?

[stancl]

Yeah, it's because changing the config has no effect on already instantiated disks.

From the flysystem issue I linked, my impression is that in the latest version we'll have to use Reflection to change the prefix that way. Or, destruct the disk and let it be constructed again (as the flysystem maintainer suggested), but I don't know if that has any performance drawbacks.

[CodeSkills]

We are using this in our old app with another tenancy package for laravel as @Yunlong2cn mentioned, without any drawbacks.

By forgetting the drive it is destroyed, as since the config has changed, the next time it gets requested, new instance of that disk is made with an updated config. Would say the impact is none, to my knowledge.

[stancl]

You can try to send a PR

[gisostallenberg]

it'd need to check the Laravel version and execute different code

You could separate this in a package and make 2 versions with different framework requirements, just an idea...

I'd go for upgrading to v4 anyway. Thanks for your work on this!

[Oxicode]

Any news?

[Eduardowm]

News?

[stancl]

For L9 support, I'd like to merge https://github.com/archtechx/tenancy/pull/802 but there are some remaining changes to be made. If the author doesn't have time for that I'll look into it myself later this week

[woganmay]

If you need some help with this @stancl please shout - we're really keen to use Tenancy for a new L9 project this week, more than happy to help!

[stancl]

Looking at #802 I think I can get it ready tomorrow. That said, I'd love #793 to be finished because the builds are slightly broken according to some reports. Erik doesn't have time to finish it now, but if someone could fork his changes and submit a PR implementing what I mentioned in the comments, that'd make the #802 changes a lot more stable as well.

[stancl]

As I commented here https://github.com/archtechx/tenancy/pull/802#issuecomment-1061293582, 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 [email protected]

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 :)