If the messages have ids (they should), you can listen for them on several goroutines which reconnect if needed. The goroutines can forward the messages via a channel to a filter goroutine which only forwards unique messages, e.g. keep a map using seen message ids as keys. The map can be pruned periodically so it doesn't accumulate ids which are too old and no longer relevant.
gorilla/websocket I'm connecting to some websocket (wss) endpoint and listening messages (only reading, not writing - this is important). This endpoint is always forcing closing connections after 10 minutes. Handling connection closing and reconnect will probably cause some incoming messages lost. How to handle connection in this case?
My suggestion is to keep pool of connections (2 connections or more). When first connection is being closed we can start using another (already connected) connection and start preparing new connection (or just reconnect). What do you think? Any drawbacks? "Swap" connections means stop using one gorouting and switch to another? Any ideas?
Important to note:
- Endpoint is just broadcasting messages to all connections. No personalized messages, no authentification, no session-specific state etc.
- Just reading, no writing at all.