Native support for EventSource

[SamyPesse]

EventSource is a good and simple API to easily implement streaming. At the moment, it's easy to generate an event source stream from a Cloudflare Worker, but it's not easy to consume one from a Clouflare Worker.

Most polyfills are incompatible with Cloudflare Workers:

• event-source-polyfill uses fetch options that are not supported by Cloudflare, I'll publish a fork
• eventsource relies on http/https module and doesn't work well with the browserify polyfills

While it's definitely possible to make a polyfill of EventSource works on Worker, it'd be great if this API could be natively supported, especially as the API surface is light and not browser-specific.

It looks like @cloudflare/ai also consumes an EventSource API, but it's unclear what polyfill is being used there and if the Cloudflare team could publish it as an open source package.

[kentonv]

Hi Samy,

In principle there's no reason we shouldn't implement this. But, it will take some engineering effort. We'd have to implement a parser for this format, etc. It may be difficult to find time between everything else on our plate.

How widely-used is EventSource today? Does it have benefits over WebSocket, aside from being a simpler underlying protocol?

If there is a polyfill that works with Workers and is sufficiently lightweight, one possibility is that we incorporate that polyfill directly into workerd, rather than implement EventSource natively. That would keep the engineering investment minimal.

[SamyPesse]

How widely-used is EventSource today?

I don't know. I'm seeing it more and more used with AI (ChatGPT uses it, OpenAI APIs use it). Cloudflare even has a blog article about it: https://blog.cloudflare.com/workers-ai-streaming

At GitBook, we use Server-Sent-Events / EventSource for:

• Channel notifications using Ably (https://ably.com/docs/protocols/sse)
• Streaming results from our API

Does it have benefits over WebSocket, aside from being a simpler underlying protocol?

Server-sent events are a lot easier to implement on the server side when it's uni-directional (very common with AI streaming, etc).

I don't think there are a lot of other benefits because WebSocket is designed to be a bi-directional/complete solution to the problem of maintaining a stream between server and client. But I don't think everyone will go into using this more complex solution.
Ex: Cloudflare and OpenAI have been designed SSE APIs for AI and no one shipped a WebSocket API for AI.

If there is a polyfill that works with Workers and is sufficiently lightweight, one possibility is that we incorporate that polyfill directly into workerd, rather than implement EventSource natively. That would keep the engineering investment minimal.

I couldn't find a good polyfill that works well in Cloudflare Workers, and I went into implementing it directly in my codebase using a low level parser (https://github.com/rexxars/eventsource-parser) and fetch.

I think a minimal implementation could be done using fetch and a parser like eventsource-parser.

Another polyfill could be forked to remove the use of fetch options like credentials, etc.

[kentonv]

Interesting. @irvinebroque seems like the left hand (Workers AI) is creating APIs that the right hand (Workers) can't consume here! Should we plan to add EventSource support?

[irvinebroque]

This is really interesting, thanks @SamyPesse for all the context above.

one possibility is that we incorporate that polyfill directly into worker

This is where my mind went too, since APIs in workerd can be written in TypeScript. Seems like clear win to me — @SamyPesse — would someone from your team be open to collab on a PR with an engineer on our team? I'd imagine we could scaffold out any native wiring, and let you drive the TypeScript side?

cc @jasnell re: Web APIs
cc @xtuc re: Workers AI

[jasnell]

Draft implementation in #1782

[scenaristeur]

seems to be the same subject i've got some results but it is not usable cloudflare/cloudflare-docs#12195 (comment)