title: Websockets: One handler to rule them all? Best case w/ backups?
body: <p>I'm working on making an iOS app that does a few things, some of which would benefit from real-time data streams (like chat)</p>
  
  <p>For right now I have a few handlers on my server, one of them gets all the threads a user has access to, another can get messages (offset, all, time-ranged, etc.) for a thread.  When a user sends a message to a thread, I get all the listeners for the thread and send them a push notification.  This works, but I was reading through the APNS docs and it says "dont do more than 3/hr" and I'm definitely doing more than 3/hr.  </p>
  
  <p>So I'm thinking I move to websockets.  I know how to synchronize pub/subs across machines via redis so I'm not worried about that, I'm more stuck on the following:</p>
  
  <p>If I start to bring websockets into the project, should I just pump all the information App &lt;-> Server through the websocket?  Create a thread -> Don't POST, just send a message along the socket.  Get a message -> Don't poll or send notification, just send a message along the socket.  Literally anything -> Don't make a request, just send a message along the socket.</p>
  
  <p>Right now I'm leaning towards loading initial state and bulk data via normal HTTP URLs (eg: Create a thread, load the last 20 messages for thread XYZ), but for data that needs to be pushed and received in real time (eg: Chat Message send/recv) do that via a websocket.</p>