
Scaling Play to Thousands of Concurrent Requests - bbeneschott
http://www.toptal.com/scala/scaling-play-to-thousands-of-concurrent-requests
======
mason55
_> The user session is kept in a browser cookie, and you have to live with it.
This means that the session space is limited in size and type: you can only
store strings. If you need to store objects, you’ll have to use the caching
mechanism we discussed before. _

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.

~~~
ExpiredLink
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.

~~~
gnaritas
As long as you encrypt it, sure you can. It's no different than storing the
session pointer in the cookie.

~~~
ChrisAntaki
Though, with every HTTP request, the client will be uploading the entire
cookie. This could manifest as degraded responsiveness, especially for mobile
devices.

~~~
gnaritas
That's the trade you make when using cookies. Nothing new there.

