4 ms·
The major benefit of this approach is that you can avoid a database lookup when you have a valid JWT available. Only in cases where it's missing or expired wou
by VWWHFSfQ 1y ago
The major benefit of this approach is that you can avoid a database lookup when you have a valid JWT available. Only in cases where it's missing or expired would you need to hit the database for a refresh token.
This might not matter for trivial apps, but for very high-concurrency web apps this will matter a lot.
- 0x457 1y agoSure, but unless you're near Google scale, you probably shouldn't worry about that. IMO JWTs should not be used on public internet.
- VWWHFSfQ 1y ago> unless you're near Google scale, you probably shouldn't worry about that Even just a few million concurrent users on the website can cause a huge amount of load on the database just looking up sessions over and over again.
- 0x457 1y agoYes, that's why long time ago we figured out how to store those in some extremely fast memory store like memcached or redis. I hope people that work at scale where it's not a viable option don't need to read such blog posts to set this up. To store 1M sessions, let's say each is 2 KB, you going to need 2GB. Somewhere around 15K session look ups per second will saturate the server (+/- 5K ops/s depending on the CPU) . If you want more sessions - use more RAM, if you want more ops/s - use more servers (cache cluster). Another reason to JWT - cross-region authentication (replicating giant session store across the globe isn't a viable option)