#Server-Sent Events for Go. A tiny, dependency-free, spec-compliant library compatible with stdlib

5 messages · Page 1 of 1 (latest)

ebon belfry
#

Hi everyone,

We just open-sourced go.jetify.com/sse a tiny, dependency-free library to handle Server Sent Events in Go. It has extensive unit tests and follows the WHATWG Spec (we're intending to be fully compliant, but let us know if you find an example where we're not!)

At our company we're building all of our AI agents and related infrastructure using Go. Many LLM providers like OpenAI and Anthropic use SSE as their streaming protocol, and we needed to be able to handle it.

Existing SSE libraries seemed to be bigger than what we needed, and they often included their own server implementation – which we didn't need.

We were instead looking for something small, primarily focused on handling the SSE encoding correctly, and compatible with the http package from the stdlib – so that's what we built.

If you need SSE handling, feel free to give it a try.

GitHub
GitHub - jetify-com/sse: Server-Sent Events for Go. A tiny, depende...

Server-Sent Events for Go. A tiny, dependency-free, spec-compliant library compatible with the HTTP stdlib. - jetify-com/sse

prime obsidian
#

Hey this is great work, I will try it out.
3 questions:

  • How this is working under heavy load ?
  • Is it possible to provide custom stream ID ?
  • How it is different from r3labs/sse/tree/v2
#

I also have need to sending events to multiple different stereams, so looking if I can provide custom stream id as well.

image.png
ebon belfry
#

We've been testing it under "moderate" load, but our startup is not a super large scale, so I don't know how it'll perform for truly large scale. We could add some benchmarking to the library (and for example try to get to near zero allocations in the encoding hot path)

Each connection object represents a single stream (which is what we need internally at the moment). I had a draft implementation of Broker object that could let you manage connections across multiple stream.

r3labs is great. It also integrates with standard http, but by providing a handler.

In my use case we needed to have a dual purpose http handler: depending on a cgi param, the handler could either act as a regular RESTful endpoint, OR, switch to SSE mode. That's why we didn't end up using r3labs