I think that this question is already done, but I did not find any difference between this and gates and policies except by the database table for those features, As I understand it looks like something more related to a mindset a tool specific for development features/plugins/new sections of an app, and divide this logic from authorization logic, in that case it makes a huge sense
i write my apps pretty modular, making things partial realeases pretty easy, but lets be honest, if you are making a redesign you kinda go full release for all the only moment we has partial access was when we had 8 load balancers, and decided to make just one of theose load balancers load the redesigned app(+ rewrite backend) until we delivered 80-90% of the features of the main original app i just think this kind of package is ok if you design your app to take it into consideration from the start and most importantly if you need to do it
Can you maybe give us some more complex thing why should we use this? I mean you can make new-design permission and assign it to certain users and do the check and insert into db or logs the info. Not seeing the big picture, so thats why I asked for some more complex idea behind it?
Rather than focusing on a complex example, a practical example might make it easier to understand and relatable. E.g. In a 2 week sprint cycle, using trunk based development, with CI/CD pipelines in place, you might want to release features to an environment (say "UAT") at the end of the sprint, however the feature might not be completed by the end of the sprint. So, you would want to encapsulate the feature under a flag (like "feature-17") and set it to false for everyone (not user-specific), so that the code can still be pushed, but will not be usable/accessible for now. After some more testing or refinement, you would be more comfortable in releasing this feature. During the next deployment, you would push the code, it will get deployed and will stay "inactive", and now you can toggle the state of the said feature to "true" and make it accessible to everyone (as intended/planned). I understand there would be follow up questions about follow up code-clean-up or feature-management options, and if there are, let there be another comment based on those queries. I hope I added to the confusion 😁😅
Hi Jeffrey, you are the man !!!! Thank you so much for taking the time to share this with us. The web site's opening paragraph made me say "oh my god i dont have time to learn another package...what is this now? i dont quite get it..." but you made it so clear what it is about and how easy it is to use that now I want it desperately ! Side question though, i want to have a laravel backend serving whatever (blade or vue) and at the same time i need to have api support. Any resources explaining the different auth packages? I can see breeze includes sanctum but when i am installing it is says pick one - blade, vue or api support. Cant i have all of them?
Absolutely. Since the feature expects a Boolean response, so the response could be anything that can be processed as true or false. Yes, tenant or owner or anything else - as long as it returns true
@@JagdeepSinghKalsi ok. I have it defined like 'return $tenant->isVIP()'. Then I use @feature('vip-feature') in Blade. How will it resolve "the current tenant" to be used as a scope? With User, there's pre-programmed logic to use "the currently authenticated user", but what about other classes?
.. and I asked about other classes, because I saw how it saved references to the users in the database. It doesn't write just the user id, it prefixes it with the class name. This makes me think that it's not limited just to users
@@mityukov TBH, I have not exectued any code with the use-case that you have mentioned. However, I would love to try this. Could you please provide some info about the "Tenant" object - as in - is it a User-Type? Or a dedicatedly separate object? How is Tenant related to the logged-in user object (if it is NOT a User Type). When I am asking if something is "NOT" a user type, what I intend to know is - how are you "logging" in a Tenant? Using Auth::login or Auth::attempt (or some other Auth way to login, like Sanctum perhaps)?
@@JagdeepSinghKalsi in my example, a Tenant is like a company account. The site serves many companies (tenants) and each end user - is an employee of one of these companies. Say, we enable a feature for certain companies - so, it's only logical to use user's Tenant as the scope. Sure, I can still pass user into the callback and then check against $user->tenant->smth, but, I've seen that the package stores class name along with the id, so, I am wondering if that means that it can be taught to use some other objects as context.
So.. every time I want to test a new feature the database will be populated with records for every user to see if they have access to that feature or not? that table will become very big if I have millions of users. Also.. does it query that table on every page load?
As for the table having millions of users, I believe this is not an issue for databases as they are made to handle much more. For the caching part It is not mentioned in the documentation, so I believe each request is one database query, but since this is an package that will have the interest for a lot of people I believe they will implement it soon. There are some mentions about the redis driver on their github but was closed.
Specifically for this user-isAdmin example, I'd personally prefer to make a Gate, and then use @can('see-the-styles') in the Blade. No database whatsoever. But there are many other applications to this thing, including, like, "activate on payment completion", etc
It's really a luxury we got Laravel and all these awesome packages, can't imagine using any other php framework
Omg man you changed so much, I remember speeding through your videos with 1.5 playback speed and learning a lot of stuff. :D
I think that this question is already done, but I did not find any difference between this and gates and policies except by the database table for those features, As I understand it looks like something more related to a mindset a tool specific for development features/plugins/new sections of an app, and divide this logic from authorization logic, in that case it makes a huge sense
Nice tutorial but, how is this different from Gates and Policies?
Or even simpler a middleware and @if(auth()->isAdmin()) in blade? What about Vue components?
i write my apps pretty modular, making things partial realeases pretty easy, but lets be honest, if you are making a redesign you kinda go full release for all
the only moment we has partial access was when we had 8 load balancers, and decided to make just one of theose load balancers load the redesigned app(+ rewrite backend) until we delivered 80-90% of the features of the main original app
i just think this kind of package is ok if you design your app to take it into consideration from the start and most importantly if you need to do it
Can you maybe give us some more complex thing why should we use this? I mean you can make new-design permission and assign it to certain users and do the check and insert into db or logs the info. Not seeing the big picture, so thats why I asked for some more complex idea behind it?
Rather than focusing on a complex example, a practical example might make it easier to understand and relatable.
E.g.
In a 2 week sprint cycle, using trunk based development, with CI/CD pipelines in place, you might want to release features to an environment (say "UAT") at the end of the sprint, however the feature might not be completed by the end of the sprint.
So, you would want to encapsulate the feature under a flag (like "feature-17") and set it to false for everyone (not user-specific), so that the code can still be pushed, but will not be usable/accessible for now. After some more testing or refinement, you would be more comfortable in releasing this feature.
During the next deployment, you would push the code, it will get deployed and will stay "inactive", and now you can toggle the state of the said feature to "true" and make it accessible to everyone (as intended/planned).
I understand there would be follow up questions about follow up code-clean-up or feature-management options, and if there are, let there be another comment based on those queries.
I hope I added to the confusion 😁😅
Hi Jeffrey, you are the man !!!! Thank you so much for taking the time to share this with us. The web site's opening paragraph made me say "oh my god i dont have time to learn another package...what is this now? i dont quite get it..." but you made it so clear what it is about and how easy it is to use that now I want it desperately ! Side question though, i want to have a laravel backend serving whatever (blade or vue) and at the same time i need to have api support. Any resources explaining the different auth packages? I can see breeze includes sanctum but when i am installing it is says pick one - blade, vue or api support. Cant i have all of them?
what if it is guest user and hence User is null? can Feature::define() take in $request?
Can feature be assigned to some other scope that is not a User? Like, Tenant?
Absolutely.
Since the feature expects a Boolean response, so the response could be anything that can be processed as true or false.
Yes, tenant or owner or anything else - as long as it returns true
@@JagdeepSinghKalsi ok. I have it defined like 'return $tenant->isVIP()'. Then I use @feature('vip-feature') in Blade. How will it resolve "the current tenant" to be used as a scope? With User, there's pre-programmed logic to use "the currently authenticated user", but what about other classes?
.. and I asked about other classes, because I saw how it saved references to the users in the database. It doesn't write just the user id, it prefixes it with the class name. This makes me think that it's not limited just to users
@@mityukov TBH, I have not exectued any code with the use-case that you have mentioned. However, I would love to try this.
Could you please provide some info about the "Tenant" object - as in - is it a User-Type?
Or a dedicatedly separate object?
How is Tenant related to the logged-in user object (if it is NOT a User Type).
When I am asking if something is "NOT" a user type, what I intend to know is - how are you "logging" in a Tenant? Using Auth::login or Auth::attempt (or some other Auth way to login, like Sanctum perhaps)?
@@JagdeepSinghKalsi in my example, a Tenant is like a company account. The site serves many companies (tenants) and each end user - is an employee of one of these companies. Say, we enable a feature for certain companies - so, it's only logical to use user's Tenant as the scope. Sure, I can still pass user into the callback and then check against $user->tenant->smth, but, I've seen that the package stores class name along with the id, so, I am wondering if that means that it can be taught to use some other objects as context.
So.. every time I want to test a new feature the database will be populated with records for every user to see if they have access to that feature or not? that table will become very big if I have millions of users. Also.. does it query that table on every page load?
As for the table having millions of users, I believe this is not an issue for databases as they are made to handle much more. For the caching part It is not mentioned in the documentation, so I believe each request is one database query, but since this is an package that will have the interest for a lot of people I believe they will implement it soon. There are some mentions about the redis driver on their github but was closed.
Specifically for this user-isAdmin example, I'd personally prefer to make a Gate, and then use @can('see-the-styles') in the Blade. No database whatsoever. But there are many other applications to this thing, including, like, "activate on payment completion", etc
Feature is a nice feature. Damet garm.
Please share your theme and font please :(
They also need to focus on performance aspect. With every new update framework is becoming more bulky.
This is a package. It’s not included with the framework.