title: CQRS and WebSockets
body: <p>When we have to add push updates feature to a system based on CQRS, it seems that make sense let the "read" model to be responsible of manage those push messages. This make a lot of sense when long polling and server events were used (mostly unidirectional)</p>
  
  <p>But WebSockets are bidirectional persistent channels. It is an already established connection that can be used for both get the push updates and send commands. The thing is that the WebSocket connection becomes handy for lot of things like auto-completion search boxes due its reduced latency and statefulness. At first sight, from the technical point of view, there is no justification in using another endpoint (ie: HTTP POST receiver) when there is already a capable channel in place and ready.</p>
  
  <p>Where would be the right place to enable a WebSocket endpoint?</p>
  
  <ul>
  <li><p>Read model: It makes sense for push updates for the client and answering queries like auto-completion search boxes, but if it accepts "writes", it would has read and update models in the same place again.</p></li>
  <li><p>Update model: It makes sense to accept client inputs. It makes a little sense for send push updates to clients, since they are triggered by other client inputs. But it makes no sense for request-response things like searches for auto-completion searches.</p></li>
  </ul>