Why not expose the websockets as a standard websocket server so that it can be consumed by any language/platform that has a standard websocket implementation?
https://www.npmjs.com/package/ws Pinning to socket.io versions or other abstractions leads to what happened before, you can get stuck on an old version, and the protocol is specific to the library and platforms where that library has been implemented. By using a standard websocket server, you can provide a minimal standards compliant service that can be consumed across other languages/clients, and if there are services that need the socket.io features you can provide a different service that proxies the original one but puts socket.io on top of it. --- For the RCStream use case server sent events (SSE) are a great use case too (given you don't need bidirectional communication), so that would make a lot of sense too instead of websockets (it'd probably be easier to scale). Whatever it is I'd vote for sticking to standard implementations, either pure websockets or http server sent events, and let shim layers that provide other features like socket.io be implemented in other proxy servers. On Sun, Sep 25, 2016 at 4:02 PM, Merlijn van Deen (valhallasw) < valhall...@arctus.nl> wrote: > Hi Andrew, > > On 23 September 2016 at 23:15, Andrew Otto <o...@wikimedia.org> wrote: > > > We’ve been busy working on building a replacement for RCStream. This new > > service would expose recentchanges as a stream as usual, but also other > > types of event streams that we can make public. > > > > First of all, why does it need to be a replacement, rather than something > that builds on existing infrastructure? Re-using the existing > infrastructure provides a much more convenient path for consumers to > upgrade. > > > > But we’re having a bit of an existential crisis! We had originally > chosen > > to implement this using an up to date socket.io server, as RCStream also > > uses socket.io. We’re mostly finished with this, but now we are taking > a > > step back and wondering if socket.io/websockets are the best technology > to > > use to expose stream data these days. > > > > For what it's worth, I'm on the fence about socket.io. My biggest argument > for socket.io is the fact that rcstream already uses it, but my experience > with implementing the pywikibot consumer for rcstream is that the Python > libraries are lacking, especially when it comes to stuff like reconnecting. > In addition, debugging issues requires knowledge of both socket.io and the > underlying websockets layer, which are both very different from regular > http. > > From the task description, I understand that the goal is to allow easy > resumation by passing information on the the last received message. You > could consider not implementing streaming /at all/, and just ask clients to > poll an http endpoint, which is much easier to implement client-side than > anything streaming (especially when it comes to handling disconnects). > > So: My preference would be extending the existing rcstream framework, but > if that's not possible, my preference would be with not streaming at all. > > Merlijn > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
