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?