go-sse  by tmaxmax

Go library for HTML5 server-sent events

created 4 years ago
462 stars

Top 66.5% on sourcepulse

GitHubView on GitHub
Project Summary

This Go library provides a fully spec-compliant implementation of HTML5 Server-Sent Events (SSE) for both server and client use cases. It's designed for developers building applications that require real-time, one-way communication, such as streaming LLM responses, live notifications, or data feeds, offering a robust and flexible solution for integrating SSE functionality into Go applications.

How It Works

The library offers decoupled server and client implementations. The server component is framework-agnostic and relies on a Provider interface for message dispatching, allowing integration with external pub-sub systems like Redis or Kafka, or using the built-in "Joe" provider for in-memory pub-sub. Joe can be configured with Replayer implementations to manage event history and replayability. The client component uses net/http and the cenkalti/backoff library for robust connection management, including automatic retries and reconnection logic.

Quick Start & Requirements

Highlighted Details

  • Supports Go 1.23 iterators (range-over-func) for event reading, with a fallback for Go 1.22 via GOEXPERIMENT=rangefunc.
  • The sse.Read function simplifies consuming SSE streams, particularly useful for LLM API responses.
  • The sse.Server implements http.Handler for easy integration with existing HTTP servers.
  • The Joe provider includes Replayer interfaces for managing in-memory event history and replayability.

Maintenance & Community

  • The library is described as being in its "early stages," with contributions actively encouraged.
  • Guidance for contributing includes opening an issue first and ensuring changes are well-tested and formatted.

Licensing & Compatibility

  • MIT License.
  • Permissive license suitable for commercial use and integration into closed-source projects.

Limitations & Caveats

  • The master branch is explicitly noted as potentially containing unreleased and undocumented changes that could break backward compatibility.
  • Default Replayer implementations store events in memory, which may not be suitable for very high-volume or long-term persistence requirements without custom provider/replayer implementations.
Health Check
Last commit

2 months ago

Responsiveness

1 day

Pull Requests (30d)
0
Issues (30d)
0
Star History
48 stars in the last 90 days

Explore Similar Projects

Feedback? Help us improve.