3 ms·

> How will we avoid making a leading 'Does the user have permissions? You don't avoid it, you do it. Gathering simple user info including permissions should be

> How will we avoid making a leading 'Does the user have permissions? You don't avoid it, you do it. Gathering simple user info including permissions should be the first step at the request boundary and it can traverse the life of the request. If you foolishly use a stateless token to read permissions, you're gonna be annoyed when changes you make don't take effect immediately. I trust your seniors know this (of course different situations and caveats apply, but this is referring to the general approach).

madeuptempacct 8y ago
I am well aware of this. What you are advocating is an unnecessary database call on every single request.
- kodablah 8y ago
  That'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 ago
  What's wrong with a db call on each request? A single server can handle over 10,000 of those per second..
- nickserv 8y ago
  Generally 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.

madeuptempacct 8y ago

I am well aware of this. What you are advocating is an unnecessary database call on every single request.

kodablah 8y ago
That'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 ago
What's wrong with a db call on each request? A single server can handle over 10,000 of those per second..
nickserv 8y ago
Generally 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.