9 ms·

Cookie sessions are usually stored in fast caches like redis so the performance hit is negligible. Most people will never reach the performance ceiling of a bee

Cookie sessions are usually stored in fast caches like redis so the performance hit is negligible. Most people will never reach the performance ceiling of a beefy single redis instance so why bother complicating the system?

LanceH 4y ago
Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. JWT is solving a non-problem for most people. Now, if you're talking machines talking to machines, all owned/operated by the same entity, go wild with JWT's if you want.
- unqueued 4y ago
  > Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. If you scale up high enough, it does matter. But beyond that, it is also about decoupling the server serving the content and the user database. To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables to see if a specific user for that specific session is authorized to access that content. There are going to be many joins involved. Even with good caching, it will still be a more complex operation. Even if not computationally complex, it will be logically complex. But when using a JWT, my server actually does not need ANY db access. It merely needs to verify the cryptographic validity of the included JWT header, which uses no IO. After that, it can safely trust any user metadata included in the JWT. So, if a user has paid for access to all premium content after 2018, you would just include a field for that in your JWT payload. Done. It depends of course on how your business data models work of course. But you can often put enough information in your JWT to cut out a lot of account processing logic. > JWT is solving a non-problem for most people. I think people are cargo culting JWTs.
  - P5fRxh5kUvp2th 4y ago
    When people talk about caching user information, access is one of the things cached. That complicated joining happens exactly as often with sessions as it does with JWT's.
    - unqueued 4y ago
      No, with JWT parsing it doesn't even have to look anything up, cached or otherwise. The JWT itself contains the information directly. I could have a server that doesn't have any access to the database at all, and it could still render content for the user. And if the server is for something critical, like purchases, it can still use redis on each request to verify that a JWT is still valid.
      - P5fRxh5kUvp2th 4y ago
        I was responding to this: > To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables It does this on initial logon and then stores it in cache. You can think of a JWT as cache as well. The point is, it only happens once for both.
        nithril 4y ago
        Still not comparable. Session cookie requires a session datastore server side. It then requires to enable sticky session, to replicate the session between the server or to have a distributed datastore. if user information are cached it will require either a local cache or a distributed cache. JWT token does not require that. Both solutions requires invalidation.
        P5fRxh5kUvp2th 4y ago
        I'm unsure why you're so hell-bent on arguing something so silly, but at the end of the day you made a mistaken point and I responded to it. You want to try and move the goalpost that's on you, but your point about the joins is flawed. As is the rest of it, but I'm certainly not going to waste my time.

LanceH 4y ago

Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. JWT is solving a non-problem for most people. Now, if you're talking machines talking to machines, all owned/operated by the same entity, go wild with JWT's if you want.

unqueued 4y ago
> Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. If you scale up high enough, it does matter. But beyond that, it is also about decoupling the server serving the content and the user database. To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables to see if a specific user for that specific session is authorized to access that content. There are going to be many joins involved. Even with good caching, it will still be a more complex operation. Even if not computationally complex, it will be logically complex. But when using a JWT, my server actually does not need ANY db access. It merely needs to verify the cryptographic validity of the included JWT header, which uses no IO. After that, it can safely trust any user metadata included in the JWT. So, if a user has paid for access to all premium content after 2018, you would just include a field for that in your JWT payload. Done. It depends of course on how your business data models work of course. But you can often put enough information in your JWT to cut out a lot of account processing logic. > JWT is solving a non-problem for most people. I think people are cargo culting JWTs.
- P5fRxh5kUvp2th 4y ago
  When people talk about caching user information, access is one of the things cached. That complicated joining happens exactly as often with sessions as it does with JWT's.
  - unqueued 4y ago
    No, with JWT parsing it doesn't even have to look anything up, cached or otherwise. The JWT itself contains the information directly. I could have a server that doesn't have any access to the database at all, and it could still render content for the user. And if the server is for something critical, like purchases, it can still use redis on each request to verify that a JWT is still valid.
    - P5fRxh5kUvp2th 4y ago
      I was responding to this: > To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables It does this on initial logon and then stores it in cache. You can think of a JWT as cache as well. The point is, it only happens once for both.
      - nithril 4y ago
        Still not comparable. Session cookie requires a session datastore server side. It then requires to enable sticky session, to replicate the session between the server or to have a distributed datastore. if user information are cached it will require either a local cache or a distributed cache. JWT token does not require that. Both solutions requires invalidation.
        P5fRxh5kUvp2th 4y ago
        I'm unsure why you're so hell-bent on arguing something so silly, but at the end of the day you made a mistaken point and I responded to it. You want to try and move the goalpost that's on you, but your point about the joins is flawed. As is the rest of it, but I'm certainly not going to waste my time.