Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v4 Roadmap #654

Open
stancl opened this issue May 14, 2021 · 96 comments
Open

v4 Roadmap #654

stancl opened this issue May 14, 2021 · 96 comments
Assignees

Comments

@stancl
Copy link
Member

stancl commented May 14, 2021

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!

@stancl stancl self-assigned this May 14, 2021
@stancl stancl pinned this issue May 14, 2021
@kengraversen
Copy link

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
Copy link

dzymail commented May 15, 2021

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
Copy link
Contributor

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

@stancl
Copy link
Member Author

stancl commented May 22, 2021

@medvinator What benefit would that bring?

@alexrififi
Copy link
Contributor

@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
Copy link

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
Copy link

jcs224 commented May 25, 2021

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
Copy link
Member Author

stancl commented May 25, 2021

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

@a-ssassi-n
Copy link

Is this getting solved in v4?
#645

@stancl
Copy link
Member Author

stancl commented May 29, 2021

Yes

@mannieg
Copy link

mannieg commented Jun 2, 2021

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

@pilishen
Copy link

pilishen commented Jun 5, 2021

expecting a dramatic performance boost with Octane supported in V4

@stancl
Copy link
Member Author

stancl commented Jun 5, 2021

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
Copy link

Sn0wCrack commented Jun 7, 2021

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
Copy link
Contributor

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
Copy link

@ohnotnow you can always extend the command, no?

@stancl
Copy link
Member Author

stancl commented Jun 16, 2021

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

@ohnotnow
Copy link
Contributor

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
Copy link
Contributor

@ohnotnow just wrap two commands in one

@ohnotnow
Copy link
Contributor

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

@cyrillkalita
Copy link

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

laravel/framework#37720

@stancl
Copy link
Member Author

stancl commented Jun 23, 2021

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

@darkons
Copy link

darkons commented Jul 8, 2021

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Member Author

stancl commented Aug 11, 2021

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
Copy link
Member Author

stancl commented Mar 10, 2022

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 stancl changed the title v4 Roadmap & Laravel 9 v4 Roadmap Mar 10, 2022
@stancl
Copy link
Member Author

stancl commented Mar 10, 2022

3.5.2 released with Laravel 9 support 🚀

@eskiesirius
Copy link

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

@HelloAlexPan
Copy link

HelloAlexPan commented May 4, 2022

Please prioritise faster test execution, ref #250

@abishekrsrikaanth
Copy link

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
Copy link

@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
Copy link
Member Author

stancl commented Jun 16, 2022

🚀 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
Copy link
Member Author

stancl commented Jun 17, 2022

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

@anburocky3
Copy link
Contributor

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

Any ETA?

@bdsumon4u
Copy link

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

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

@Allgoodnamesargone
Copy link

Allgoodnamesargone commented Aug 24, 2022

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
Copy link
Member Author

stancl commented Aug 24, 2022

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
Copy link

J5Dev commented Aug 25, 2022

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
Copy link
Member Author

stancl commented Aug 25, 2022

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

@J5Dev
Copy link

J5Dev commented Aug 26, 2022

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
Copy link

ollivr commented Sep 15, 2022

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
Copy link

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

Any estimated time of arrival, please please please?

@stancl
Copy link
Member Author

stancl commented Oct 9, 2022

Early access to v4 for sponsors likely within a few weeks

@wskeee
Copy link

wskeee commented Oct 29, 2022

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
Copy link
Member Author

stancl commented Oct 29, 2022

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
Copy link

Can't wait for the v4..

@atapatel
Copy link

Eagerly Waiting for V4

@bdsumon4u
Copy link

Waiting...

@stancl
Copy link
Member Author

stancl commented Nov 20, 2022

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

@sinamiandashti
Copy link

is octane supported or not?

@stancl
Copy link
Member Author

stancl commented Feb 1, 2023

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

@archtechx archtechx locked and limited conversation to collaborators Feb 1, 2023
@stancl
Copy link
Member Author

stancl commented Mar 16, 2024

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.

@stancl
Copy link
Member Author

stancl commented Jul 18, 2024

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests