centrifuge VS jetstream

There are libraries which provide more advanced APIs for creating real-time applications, for example https://github.com/centrifugal/centrifuge

Yes, but there are two excelent libs for golang websockets - https://github.com/gobwas/ws - https://github.com/centrifugal/centrifuge

What https://github.com/centrifugal/centrifuge does:

Have you considered https://github.com/centrifugal/centrifuge? It also uses Gorilla WebSocket for WebSocket transport at the moment – but it's hidden inside and may be replaced if needed since Transport interface is pluggable. It's more heavyweight though than both Melody and Gorilla WebSocket but provides much more functionality out-of-the-box.

Not a Socket.IO compatible but maybe you will find it useful/interesting: https://github.com/centrifugal/centrifuge

Thanks! BTW, Centrifugo's core is based on https://github.com/centrifugal/centrifuge Go library - which theoretically can be more flexible and extensible solution for Go developers than Centrifugo server since server dictates some auth/permission/channel/api rules.

Hello, +1 to WebSockets. If you need to choose WS library – go with https://github.com/gorilla/websocket or https://github.com/gobwas/ws. You can also look at Centrifugo server (https://centrifugal.dev/, supports WebSocket, SockJS bidi transports, also EventSource, HTTP-streaming, GRPC unidirectional transports and many builtin features) or https://github.com/centrifugal/centrifuge Go library.

Maybe https://github.com/centrifugal/centrifuge would be a better fit for op use case (the library Centrifugo is based on, still evolving and has not v1 release though). Centrifugo is a standalone server and may limit developers that pursue the lowest latency due to attempt being generic. Don't want to say that Centrifugo performs bad - but it's mostly about features available out-of-the-box and simple scalability to many machines.

With Centrifuge v0.16.0 it's now possible to use a bunch of unidirectional transports for cases where bidirectional communication not really needed. New release includes several examples for unidirectional GRPC stream, EventSource, Fetch Readable Stream (all links in release notes) and even unidirectional WebSocket (ha-ha!). Previously I could not find a good way to fit this into Centrifuge protocol – now I think I found a pretty elegant solution. I believe this could give developers more choice especially for simple use cases without frequent dynamic subscriptions/unsubscriptions (though with new API it's possible to subscribe/unsubscribe specific client cluster-wide). The additional beauty of unidirectional approach is that it does not really require using specific Centrifuge libraries for different environments (since bidirectional communication is pretty hard to use without extra library on top of client-server framing protocol) - just use native browser APIs or GRPC-generated code to connect and receive real-time updates.

Centrifugo can use Nats as PUB/SUB broker. I also tried to use Jetstream to implement Centrifugo history/recovery semantics – unfortunately Jetstream does not fit us very well as streams must be created over a separate call to admin API, and it's not possible to iterate/paginate over Jetstream streams to be suitable to current Centrifugo message history and recovery semantics (I asked about support for this – unfortunately the issue was closed and required API not implemented - https://github.com/nats-io/jetstream/issues/266, suggested solution is far from optimal for our use case).