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