lock
lock copied to clipboard
BeatSwitch
Caching
I've just gone through the library, but didn't find any results for this one.
Is it possible to integrate caching somehow? IMO it is much more cheaper in performance to cache permission/privileges when using a persistent driver.
True but that's actually something which you can handle in your driver. When you build your driver you can inject any caching mechanisme you like and cache the results in the getCallerPermissions and getRolePermissions methods. I should probably write an appendix about this in docs.
Actually, I am thinking about writting a decorator for that. When getting permissions, checks for cache existence: when exists, call to persistent storage is not needed, when does not exist, retrieves the data and stores it in the cache. Of course, all this is done for every single caller. When a permission is set/removed then the cache gets flushed.
Nowadays I am using Stash for caching. Are you open for such a PR? Or should I implement it in a separate package?
Hmm I now see what you mean. I've just implemented this in the Laravel driver but truth be told this could indeed be something that could be handled in the Lock instance.
https://github.com/BeatSwitch/lock-laravel/commit/ae98f7b77a1b87ad96c0c286a1991df427cccc80
I'm actually thinking a little further ahead and perhaps if I make some changes to the way drivers are built I could drastically simplify the Driver interface. If the driver interface would just consist of the basic 4 methods (get, store, remove and has) then the 4 abstract permissions on the Lock class wouldn't be necessary anymore and we could implement this caching system in the Lock class and thus enable it for every single driver.
I'm gonna think this over because this would involve major BC breakages and quite some refactoring. It'll probably be a while before I can implement this.
As for Stash: I haven't looked at that in detail yet but I'll try to do so soon. I'm open to PR's but for this personally I'd want to try to take a stab at it first because I don't want you to do any unnecessary work if I'm gonna refactor a lot :)
Right, will wait for the changes then.
Be aware with implementing caching in Lock itself: Caching should be completely optional, and should not affect any implementation. It should be completely transparent. This is why I usually implement it as a decorator.
True but what we're implementing isn't exactly caching, it's more like saving permissions at runtime and resetting them when a store or remove event occurs. I still believe that actual caching of permissions should be done inside a driver.
That means you have to implement the (possibly) same code for every single driver. Which not just violates DRY, but makes the whole development process harder. You have to test it in once, etc.
Actually, implementing caching as a driver decorator means caching happens in the driver. From the outside at least it seems like that. The point is that a driver itself should only be responsible for data retrieving, the caching layer is just an extra. Which you cannot see at all from the outside.
Looking at your previous comment again: if you implement it in Lock, you are coupling yourself to data retrieval implementation while it is the responsibility of a driver. Also, using decorators you can also use caching for any drivers, and you can also control which of them should be cached. The other way would make it much harder.
@driesvints this is what I originally wanted:
https://github.com/guardianphp/lock-cache