search

tmaxmax / go-sse

Fully featured, spec-compliant HTML5 server-sent events library
https://pkg.go.dev/github.com/tmaxmax/go-sse
MIT License
325 stars 17 forks source link

Server Setup #33

Closed lee-aaron closed 3 months ago

lee-aaron commented 4 months ago

Hi,

I have a few questions. I am working on a side project that just streams stock api data to a React app. I have another microservice that ingests the stock data and writes it to a Postgres DB but I'm also planning to add Redis (or some Pub/Sub system) to emit it to my api microservice.

I'm exploring the use case for SSE vs websockets and I think SSE seems to fit my use case more but am wondering if this is scalable across many topics (i.e user from React app picks some stocks to listen to price updates from).

It just seems like there's a central server for handling all topics but are there performance benchmarks / some suggestions on system design for my use case?

Thanks

lee-aaron commented 3 months ago

Oh hmm I guess given I'm using gin as my choice of routing, I can just implement SSE through their syntax but I could look to use channels etc to scale better

tmaxmax commented 3 months ago

Hi there!

If you use channels you will basically end up implementing go-sse's Joe provider. You will still only have a single central server handling all clients.

I haven't implemented an end-to-end benchmark of the server's performance yet (but it is planned, see #7 for info on the long-term evolution plan for the library). Though based on intuition I wouldn't expect it to be a bottleneck for an emerging product – the default implementation should be an easy to get running, well performing starting point!

go-sse should also be easily compatible with Gin, as it exposes a standard-library compatible interface. If I'm not mistaken, Gin is also based on the standard library.

Finally, with go-sse you can swap the provider later, when your performance requirements change and you need to scale, from the default, centralized, channel-based Joe provider to something else – Redis Pub/Sub, Postgres LISTEN/NOTIFY for example – without changing the code in your codebase. Just a new sse.Provider implementation and you're ready to go! And by that point in time there may already be some implementations available in the wild, as the library will keep maturing and the usage around it will grow.

As the creator and maintainer of this library, I'm making my job here to pitch it as a solution to your problem. Should you still find that an alternative is better suited for you, that's in the end more important to me – after all it is about the product we develop, not the libraries we choose.

I'm here if you have any further questions!