3 ms·
I am well aware of this. What you are advocating is an unnecessary database call on every single request.
by madeuptempacct 8y ago
I am well aware of this. What you are advocating is an unnecessary database call on every single request.
- kodablah 8y agoThat's exactly what I'm advocating, it's not unnecessary, and should be trivial. If you are afraid of overhead, you can have a caching layer ala Redis or Memcache or even local process memory (but don't eagerly optimize, the costs are trivial to make this call). Either way, you need to communicate with an updated cache or a user record of store. Don't trust information sent to you from the client because it may not be accurate with updates (there are exceptions to this when you can tolerate staleness, but for the general approach this is what you want to do).
- zepolen 8y agoWhat's wrong with a db call on each request? A single server can handle over 10,000 of those per second..
- nickserv 8y agoGenerally a big DB query is made when the user enters the site or makes the first API request to load all relevant user data. Then the data is stored in a cache system, which will be faster and cheaper than having the user send the data on every request. Most modern web frameworks will do this out of the box with a little configuration. Specifically, I've had good results with Redis, applicable for the majority of web apps. In some rare cases where even local network is too slow, use of local memory storage has worked well (at the cost of greater memory usage and more complex invalidation procedures). But before optimizing user permissions, in my experience there is much more to be gained from optimizing other types of DB queries.