Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For modern applications you’ll have better ways to maintain state. As shown they cause trouble in practice. Cookies should be used sparingly.


If you want to maintain state across navigations and share that state with a server it’s the best we’ve got.


Server can store session state


Server side session state for more than authentication is way worse than "code smell."

It requires a ping to a shared data source on every request. And, the same one for all of them. No sharding, No split domains... That gets expensive fast!


You just described how the whole web operates. It works just fine.


Even if you want client side, we have better ways now than cookies.


We do, but only cookies are universally available. Plenty of unusual user-agents in the world, or people like me that browse with JS off by default.


I add some products in phone. Then I login to desktop later for modification and order. Cart is empty. That's engineering smell. A really bad one.


Thats nothing more than UX/UI.

> In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

- https://en.wikipedia.org/wiki/Code_smell


Wait, you can't shard on session ID?

And this is an ephemeral key-value store here, which is basically a best-case scenario from a performance standpoint. It's basically the last thing you're going to need to think about sharding, which is why session stores traditionally cohabitate(d) with web servers.

No, session storage doesn't get expensive fast. It's extraordinarily cheap unless you screw up the configuration very badly indeed (Apparently PHP still defaults to writing session data to disk?!)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: