Server-Sent Events using Channels API

[Robert Stepanek]

Is the Channels API planned to support the Server-Sent Events W3C Recommendation (http://www.w3.org/TR/eventsource/)? Given that this standard is pushed by Google it would be great to also use it on App Engine. Or does it work already with the current Channels implementation?

Many thanks,

Robert

[Nick (Cloud Platform Support)]

As you can read from the docs, the Channels API client depends on importing from your app's special route: /_ah/channel/jsapi. This special route redirects to https://talkgadget.google.com/talkgadget/channel.js, where you'll find a very well-obfuscated and minified JS client which allows you to use the magic Channel API methods like "onopen", "onmessage", "onerror", and "close". 

You can use a JS beautifier to see the code, but as you will see it's quite complex. The Channels API mirrors closely the server-sent events standard, as you can see from inspecting the methods available in the W3C doc you linked ("onopen", "onmessage", "onerror"), and has a very similar use-case profile, although it isn't compliant with the standard.

You could attempt to declare "Content-Type: text/event-stream" on your own vanilla App Engine handler, and use an EventSource object in the browser to initiate a keep-alive connection. The problem is, App Engine waits for the handler on your app to return fully before flushing the buffer and sending the response data. You can find this documented here for java, here for python, here for php, and here for go. What this means in practice is that your stream will not be "keep-alive" and will close each time one response is sent. Or, if you implement your server-sent event code server-side as most people do, it will buffer up all of its responses and finally send them all only when it terminates.

Neither of these cases are all that desirable, since the first breaks the some of the efficiency of server-sent events by requiring the connection to be recreated each time (the polling code which powers EventSource in the browser will still, however, make things appear more or less smooth and as you want; you won't be able to gain much meaningful information from open/close events, however). The second case will break the function of server-sent events entirely.

There's already a public issue tracker thread requesting Web Sockets for GAE, and even one person in the thread has mentioned server-sent events, but it doesn't have its own feature request thread yet, and they are quite separate technologies. I encourage you to create a feature request to allow server-sent events on App Engine, either as part of the Channels API or otherwise.

It seems as though you'd have more success with Compute Engine if you want to use server-sent events as they should be, today. I can't comment on the GAE roadmap or any timeline for feature implementation but I still figured I would gather a lot of information so you know exactly the state of everything. I encourage you again to create a public issue tracker thread and get as many users to star it as you can.

Hope this helped answer your question,

Nick

[Robert Stepanek]

Hi Nick,

thanks for the extensive feedback! I'm not much into Javascript and
wasn't aware that the EventSource object reconnects on closed
connections - that should suffice for prototyping. I'll look into
opening a feature request if I settle on using App Engine for my
project.

On Wed, Jun 3, 2015 at 9:26 PM, Nick (Cloud Platform Support)
<pay...@google.com> wrote:
> I can't comment on the
> GAE roadmap or any timeline for feature implementation but I still figured I
> would gather a lot of information so you know exactly the state of
> everything.

That already helped a lot. Thanks again.
Robert

[Nick (Cloud Platform Support)]

No problem, Robert, I'm glad to be of assistance. I wish you luck in developing your app.

My advice would be to have the code responsible for maintaining the connection and passing messages (whether via the Channels API client or EventSource) expose an API to the rest of your app's components, making it straightforward to switch among solutions if you find your use-case shifting, or there's an attractive feature of one solution that you'd like to make use of.

Regards,

Nick