4 ms·
JWT's really can span this middle ground. They're helpful in answering the who-are-you question without resorting to elaborate db work. Even middle-ground monol
by kayo_20211030 2y ago
JWT's really can span this middle ground. They're helpful in answering the who-are-you question without resorting to elaborate db work. Even middle-ground monoliths are often deployed across more than one independently operating web server (say, JVM processes) and JWT's ensure that each server answers the who-are-you question with the same answer - the code is the same, and although the process space is different on each web server, the answer is the same. So chained requests, with API.REQ.1 to Server 1 and API.REQ.2 to Server 2 will actually work. Maybe session mechanics will work, but what if you don't actually have a session and just a bunch of API requests?
- andrewmcwatters 2y agoQuerying a database for a session id isn’t elaborate work. It’s also trivial because as TFA mentioned, literally every major web framework ecosystem with has a solution for this. God, how hard is SELECT * WHERE …, seriously. You need to share a session across websites? Wow! Connect to the database holding the sessions. Boring.
- jupp0r 2y agoEver heard of speed of light? If you really think that "just connect to the same db" was an easy solution to the problem you describe in the general sense then you haven't done so in a moderately complex system yet. It can be a good solution for a very limited set of circumstances, but that's about it.
- andrewmcwatters 2y agoIt’s bullshit. A majority of high volume systems can do this just fine. This is just engineering wank. Standard solution is query a session table on from a single location, and once you actually start to need to trim request time, it’s not even the first place you look.
- jupp0r 2y agoAssumptions you are making: * everything is located physically close together (good luck reading from a DB table in Singapore from a service in Europe for every request) * you have few enough client services that want to do this that the number of db connections does not become a problem (this is 100 by default for Postgres, you might need to tune this or deploy proxies, etc) * high availability is already taken care of (you don't want that one DB server to bring down everything in case of a failure)