My inclination would be to set redis as your cache system, store the permissions in the database but have your app attempt to read the permissions from the cache, if they are not there - then build the cache. Make sure you tag the cache keys so you can delete them when permissions are changed.
Don't try and use a cron to build the permissions as that will fail when you get too many users, plus redis is meant to store only semi-persistant data - updating it via a cron turns it into a completely persistent data store.
Although all this only applies for high traffic systems, if you're not building a high traffic site then you're doing premature optimization.
Looks like loading the whole two tables into cache would be best seeing as these will not be updated very often and I can hook those events to flush the cache.
@hailwood thanks for the reply, sorry didn't see it before I wrote my own after some research.
This is a generic platform that will be used by some high traffic installs (in my mind anyway; generally ~20 people on the site at any one time during the day).
Yeah, with the Laravel Cache class I've seen that events should be enough and I don't need a cron job. It's my Linux brain clicking on before my web dev one does.
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast