Well, it's the same basic problem right?

Actor behaviors are isomorphic to a (partial)function `Any => Unit` the main purpose of this function is to _select_ only those messages from the universe of `Any` it can respond to an respond to it.  Once the selection is made we have safely transitioned from the universe of anything to the universe of a known subset.  The same thing is true about web(socket) apps or network apps in general: you get a "blob" (an Any) over the wire _early on_ decipher these blobs and see if it is a blob of interest (a value/object with expected/required properties) and continue.  The `ClientHandler` is effectively the mapper from `Any` (bunch of string data we expect to be able to parse) into objects of known shape and property.  The remainder of the code behind `ClientHandler` need never know how these values were gotten or what format the wire-protocol takes.  For instance, imagine adding a Thrift face _in addition_ to the HTTP/JSON one now.  On way is trivial, the other less so. Sure, we will likely never do that, but it's illuminating to consider these options when designing the implementation of a service: there is a layer clearly responsible for communicating with external entities and there is a layer that does the actual work.