> What if the server side was stateless before?
Then that's a pretty bad design choice to begin with? If some state is required for operation, but the website keeps it only on client? Not least of all reasons, for security?
Then that's a pretty bad design choice to begin with? If some state is required for operation, but the website keeps it only on client? Not least of all reasons, for security?
As a concrete example for a common use case, websites show your user or first name in the top right corner. It's common to put this in a cookie set on login/logout. This avoids querying the user directory service (from the frontend or a different backend service) on every pageload. Security wise it doesn't matter if the user tampers with it, it's a display only thing. (More often than not it's signed anyway, and the cookie contains other things as well.)
Cookies meant to be presented back to a server can be signed and (optionally) encrypted. This is also a very widely used pattern ("cookie secret" is a good search term for concrete implementations in frameworks).
I was talking about statelessness on the server side. If you remove cookies from HTTP, you now need a database on the server side.
You also get extra communication (between the client/DB, or the web service/DB), whereas previously the data would've already been available in both (the client has the jar, and the web service gets it in each the request). Turning a local memory read into a network request can be a difficult architectural change.
Also, DynamoDB reads are priced per unit ;-)