> 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.
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.
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.
Though, with every HTTP request, the client will be uploading the entire cookie. This could manifest as degraded responsiveness, especially for mobile devices.