Scaling Play to Thousands of Concurrent Requests(toptal.com)
toptal.com
Scaling Play to Thousands of Concurrent Requests
http://www.toptal.com/scala/scaling-play-to-thousands-of-concurrent-requests
1 comments
It is right that the cache is not done in a per-user basis - still, it is an option. The downside is that you have to associate to which user the data belongs by yourself. Its an extra effort, so its better be worth that effort - in my case the page is the same for all users, so this is not a problem.
Also, this is not an _Scala_ characteristic - it is the way Play Framework works. Other Scala frameworks might (and most do) things differently.
Also, this is not an _Scala_ characteristic - it is the way Play Framework works. Other Scala frameworks might (and most do) things differently.
A browser cookie isn't a replacement for server-side sessions. You cannot store sensitive data (e.g. safety related information) in a browser cookie.
As long as you encrypt it, sure you can. It's no different than storing the session pointer in the cookie.
Though, with every HTTP request, the client will be uploading the entire cookie. This could manifest as degraded responsiveness, especially for mobile devices.
That's the trade you make when using cookies. Nothing new there.
Encrypted cookies? Just what hackers have been waiting for.
I think maybe part of what he was saying is that the session gets abused -- devs sometimes put things in there which are not actually unique to the user, because it's easy to do. And that's not even really an option here, unless it's a string.
That is exactly the message! =D
I think by "caching", he meant "take all the session data you can't store in the cookie and out it in a cache server like Redis."
It could be Redis, but Play Framework has a Caching mechanism built in already :)
This isn't quite right, or at least is presented weirdly. Caching is not done on a per-user basis whereas sessions are tied to a user. Scala chooses to use client-side sessions so that applications are automatically non-sticky which allows for effortless failover and horizontal scalability.
The caching mechanism will cache the output of a template but it's going to be cached for all users. Again, it makes for easy horizontal scalability, but you'd never say that the caching is an alternative to session data. They're for two totally different use cases.