Alternatives to engine.io

[sjmueller]

I'm curious if there's any plans to make the transport layer pluggable with other websocket implementations besides engine.io. I played around with swapping in https://github.com/websockets/ws, but had trouble since there are parts of deepstream that seem very coupled with engine.io, especially around connection semantics.

[WolframHempel]

Hi,
unsatisfying answer: No, I'm afraid there are no plans to make the transport-layer between deepstream and the browser swappable. Engine.io does a great job, has proven to be very stable, lightweight and most of all quick to connect, due to its http first, then upgrade to Websocket policy.

In general we're huge fans of a plug-in approach (hence the exchangeable storage/cache/message connectors), but what would be the benefit in being able to use a different transport mechanism?

[sjmueller]

One reason would be if your app was only targeted to modern browsers/devices, then a websocket-only implementation would be leaner. For example, I believe socketcluster v2 is planning to use only websockets.

Another reason would be to use http/2 instead of websockets, similar to what gRPC does with their bidirectional streaming.

In the grand scope of things @WolframHempel, I totally understand why a pluggable transport isn't necessarily a priority at this time, especially in comparison to something like WebRTC ;)

[WolframHempel]

Thanks, you're making a very good point and I agree that it is definitely worth considering for future updates. I'll close this issue for now, but there is a good chance that we'll open another one once we address alternative connection mechanisms