EventSource landed in Aurora 6. It is a new and simplified way to open long-lived connections to a server, and let the browser create events as the server streams messages to the client. It is also available in Chrome and Opera and there are fallback solutions for other browsers.

Creating a wall/feed for a social app…

…in a few lines of code (full project available on Github).

The messages

The server will send two kinds of messages:
 ● simple messages, starting on a new line prefixed with “data:”
 ● messages with specific event names, similar to simple messages but with “event: <anEventName>” on the previous line

In this case, simple messages are treated as users’ statuses and specific events will be inserted in the timeline with specific colors, although they could appear in different places on the page. The message data will be sent as JSON, although it could be flat text strings.

The server

The server will be a dummy .php script that reads sample statuses from a text files and stream them, one at a time, to the client, using appropriate headers.

The Client

The client will create an event source and register event handlers for each specific event name, as well as an onmessage handler for simple messages.

The missing pieces of the code are available on Github.

Fallbacks

Here is a short list of polyfills/fallbacks available for other browsers:
 ● Remy Sharp’s polyfill
 ● Yaffle’s polyfill
 ● Rick Waldron’s jquery plugin

Have you got examples of EventSource based Web app to share?

21 comments

Post a comment
  1. louisremi wrote on June 16th, 2011 at 7:44 am:

    It should be noted that the EventSource specification currently prevents the server script from being hosted on a different domain.

    The first implementation we deliver complies to the specification, but we think this possibility could benefit developers, as it is a good practice to serve persistent connections on their own domain.

    We are going to experiment with making EventSource Cross-Origin compatible, and you can follow our progress here: https://bugzilla.mozilla.org/show_bug.cgi?id=664179

    Reply

  2. David illsley wrote on June 16th, 2011 at 11:09 am:

    The piece of the puzzle I’ve been missing is dealing with failures… Dropped connections etc. Do I have to worry about this, or will reconnection happen automatically ?

    Reply

    1. louisremi wrote on June 16th, 2011 at 11:18 am:

      Interesting questions: We do not have any documentation about that yet, but reading the spec should help you: http://www.w3.org/TR/eventsource/#eventsource
      I’ve noticed that (at least in Firefox) the connection is closed if the user hits the Esc key in my demo.

      Reply

  3. David Illsley wrote on June 16th, 2011 at 11:37 am:

    :( I looked at the spec a couple of weeks ago and it’s nowhere near specific enough for interoperability. Was kinda hoping that Mozilla might be setting the standard… too many flaky/hostile mobile networks and laptop lids which close to assume the connection is robust.

    Reply

  4. sonny wrote on June 18th, 2011 at 10:39 am:

    Good article despite I wouldn’t have use a “Wall” example since it’s typically the kind of application that would benefits from being WebSocket (bi-directional) powered.
    Instead I would have use an example where a radio website would be able to push the name of the current song to listeners.

    Reply

    1. louisremi wrote on June 20th, 2011 at 8:13 am:

      Hey Sonny,
      Let me disagree, on those kind of walls you typically receive way more data than you send, and the data that you send back don’t need to be treated in near-real-time.
      With EventSource you can use a standard Web server to stream data to the client (WebSockets need a special setup on the server side), and use XHR to send data to the server from time to time.

      Reply

  5. alain wrote on June 21st, 2011 at 5:53 am:

    I like the demonstration, works just fine !
    I read today this article about the evolution of the API :

    http://blog.whatwg.org/weekly-back

    I think this wall example would be more “complete” with a multi-client version, louisremi, can you confirm that we would need some kind of server database access to realize such an application ? Since the php file is not aware of the different clients, I think we need something like that (that could be a flat file on the server maybe).

    Reply

    1. louisremi wrote on June 21st, 2011 at 6:18 am:

      Yes, you need something like a message queue on the server to handle multiple clients

      Reply

  6. alain wrote on June 21st, 2011 at 6:26 am:

    Thanks :)

    Reply

  7. Vitaliy Kupets wrote on July 11th, 2011 at 5:54 am:

    I would be happy to see WebSockets ready finally instead

    Reply

  8. davide wrote on July 16th, 2011 at 4:52 am:

    Hi, thanks for posting on this interesting feature.
    Is the approach shown above, i.e. the server, say sse.php, running an infinite loop and waking up every N seconds to check if there’s any event/message to send, the only one to use always?
    The question comes from the idea of using events in an MVC application as follows: while the user is visiting a certain page of the site, say fun.php, an event needs to be sent. Would it be possible to send the message directly from fun.php rather than passing the data to build the message to sse.php (via queue, etc.)?

    Reply

    1. louisremi wrote on July 20th, 2011 at 6:40 am:

      You can definitely send events from the script generating the page being visited.
      For performance reason, you might want to host long-lasting connection on a different server hosting more appropriate technology, such as node.js for example.

      Reply

  9. Jerome Louvel wrote on July 21st, 2011 at 12:09 pm:

    Great to see “Server-Sent Events” moving forward into Firefox. What is cool about it compared to Web-Sockets is that it doesn’t invent another protocol and fits perfectly with HTTP and the REST architecture style.

    It might not cover 100% of real-time use cases, but does what it does in a very standard, simple, yet powerful way. In the Restlet Framework, we are planning on adding its support, both server and client-side.

    Reply

  10. Louis-Pierre Beaumont wrote on August 9th, 2011 at 2:06 am:

    Hi,

    Thank you for this nice demo. Between I can’t get EventSource working on my machine. I’m always getting an error stating that Firefox cannot establish a connection with the server.

    I made a little program that listens for connections then enters a simple loop
    that sends events every 2 seconds. When i point my browser to it’s url, I can see the updates. But When using new EventSource(urlOfProgram), nothing.

    Do I need to host both the page and program on the same address AND port?

    Reply

    1. louisremi wrote on August 13th, 2011 at 12:21 am:

      Yes, there used to be such a restriction on server-sent events.
      You’ll soon be able to use CORS headers to have the event source on another domain

      Reply

  11. Louis-Pierre Beaumont wrote on August 9th, 2011 at 5:16 pm:

    About my last comment:

    I’m now hosting the page and program on the same address AND port and everything works perfectly.

    Reply

  12. Aaron wrote on August 16th, 2011 at 9:12 am:

    On Apache+PHP, won’t this inevitably max out the number of concurrent connections allowed?

    Reply

    1. louisremi wrote on August 17th, 2011 at 2:11 am:

      Sorry Aaron, I’m no specialist of Apache and PHP and cannot answer that question.

      Reply

      1. Davide wrote on August 17th, 2011 at 2:23 am:

        I had the same concern and, not having found any clear answer yet, I refrained from using SSE at least for now.

        Reply

  13. Srirang (brahmana) wrote on September 7th, 2011 at 3:28 am:

    Hi,

    Are these persistent connections counted towards the maximum simultaneous connections to a host limitation? AFAIK, the limit is currently 6 simultaneous connections to a host.

    I am guessing that these are indeed counted and that is one of the reasons why the author suggested that these should be hosted on a separate domain.

    Reply

  14. Victor wrote on September 28th, 2011 at 4:46 am:

    This EventSource polyfill supports CORS in (IE8, Firefox, Chrome, Safari):

    https://github.com/Yaffle/EventSource

    Reply

Add your comment

  1.