-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternatives to engine.io #37
Comments
Hi, 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? |
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 ;) |
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 |
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.
The text was updated successfully, but these errors were encountered: