5 ms·

Nice post, and interesting timing, just published a post on how to do SSE with Java: http://eranmedan.com/server-side-events-sse-in-java http://eranmedan.com/se

Nice post, and interesting timing, just published a post on how to do SSE with Java: http://eranmedan.com/server-side-events-sse-in-java http://eranmedan.com/server-side-events-sse-in-java and... I must admit the Node.js version is clearly more concise and elegant :) but still this is one of the simplest ways to do server side "push", if only IE supported it... though you can always use a polyfill: https://github.com/Yaffle/EventSource/ https://github.com/Yaffle/EventSource/ (though that polifill didn't work for me for that example, but I didn't spend much time trying to figure out why)

djKianoosh 13y ago
Nice. Do you recommend any specific reading for wiring up some backend services like a pub/sub message queue into something like the SSE example you have?
jkarneges 13y ago
Yeah I love how dirt simple SSE is. WebSockets tend to be the go-to choice for realtime push, but many applications don't really need a bidirectional socket. SSE for server->client and XHR for client->server interactions is good enough for typical REST apps. Also, (plug alert) SSE is pretty easy to throw together using https://fanout.io/ https://fanout.io/ and its HTTP streaming data transport, if you want to save yourself from having to set up any new server stuff.
- conorgil145 13y ago
  It is not immediately obvious to me what fanout.io does from your homepage. Could you add an example? Clients register to listen with the fanout.io CDN, then my app pushes something to the CDN, and fanout.io handles pushing it to all of my end clients? Can I determine which subset of users receive the message, or is it "all or nothing"? Are clients able to listen on a specific topic/name? I'd love to get more info, but I didn't see any higher level explanation and don't have time to dive into docs right now.
  - jkarneges 13y ago
    Yes, Fanout works as a publish-subscribe service. Clients listen on channels (topics), and you publish messages to channels which Fanout then delivers to the right clients. In the case of HTTP streaming, Fanout acts like a reverse proxy in front of your web server. Incoming requests are relayed to your server, and you can control Fanout's behavior depending on how you reply. For example, you can reply with a "hold" instruction saying to bind the incoming request to streaming channel C. The transaction between Fanout and your server is now complete, while the connection between the client and Fanout remains open. You can then send messages to this client by publishing on channel C. The process is explained in more detail on this post about our open source reference implementation: http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-realtime/ http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-r... Implementing something like SSE is just a matter of responding with a stream subscribe with initial response of Content-Type: text/event-stream, and then publishing event chunks using SSE formatting.

djKianoosh 13y ago

Nice. Do you recommend any specific reading for wiring up some backend services like a pub/sub message queue into something like the SSE example you have?

jkarneges 13y ago

Yeah I love how dirt simple SSE is. WebSockets tend to be the go-to choice for realtime push, but many applications don't really need a bidirectional socket. SSE for server->client and XHR for client->server interactions is good enough for typical REST apps. Also, (plug alert) SSE is pretty easy to throw together using https://fanout.io/ https://fanout.io/ and its HTTP streaming data transport, if you want to save yourself from having to set up any new server stuff.

conorgil145 13y ago
It is not immediately obvious to me what fanout.io does from your homepage. Could you add an example? Clients register to listen with the fanout.io CDN, then my app pushes something to the CDN, and fanout.io handles pushing it to all of my end clients? Can I determine which subset of users receive the message, or is it "all or nothing"? Are clients able to listen on a specific topic/name? I'd love to get more info, but I didn't see any higher level explanation and don't have time to dive into docs right now.
- jkarneges 13y ago
  Yes, Fanout works as a publish-subscribe service. Clients listen on channels (topics), and you publish messages to channels which Fanout then delivers to the right clients. In the case of HTTP streaming, Fanout acts like a reverse proxy in front of your web server. Incoming requests are relayed to your server, and you can control Fanout's behavior depending on how you reply. For example, you can reply with a "hold" instruction saying to bind the incoming request to streaming channel C. The transaction between Fanout and your server is now complete, while the connection between the client and Fanout remains open. You can then send messages to this client by publishing on channel C. The process is explained in more detail on this post about our open source reference implementation: http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-realtime/ http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-r... Implementing something like SSE is just a matter of responding with a stream subscribe with initial response of Content-Type: text/event-stream, and then publishing event chunks using SSE formatting.