Roadmap for v3

[darrachequesne]

This list is open to suggestions!

• Improve the documentation

That is obviously the major pain point of the project.

• Reverse the direction of the ping-pong mechanism

Currently the client emits a ping and waits for a pong from the server, relying on setTimeout() to check whether the connection is still alive or not. But there are reports of throttled timers on the browser side, which may trigger random disconnections.

A solution would be that the ping is emitted from the server to the client, but that is a breaking change which will also break other client implementations..

Related: #5082

• Update the source code to ES6 in every project

• Migrate to webpack 4 (or another bundler, if need be)

• Remove the sticky-session requirement when using multiple nodes

• Default to websocket, and use XHR polling as fallback

Currently polling is established first, and then upgraded to websocket if possible.

• Make the generateId method asynchronous

This one is also a breaking change. Related: socketio/engine.io#535

• Update the Typescript bindings, if need be

• Triage issues

No release date for now, as I'm not sure how much time I will be able to dedicate to those points in the following weeks. But any help is welcome!

[theromis]

Looks like a great plan.

I'm switching from nodejs to golang, and found there is no socket.io 2 implementation.
googollee/go-socket.io#188

What do you think of golang server support for v3? I'll be happy to take part in this development.

[darrachequesne]

@theromis are you talking about a golang client (which will connect to the Node.js server) or an actual golang server? (I think some work has been done here too: https://github.com/graarh/golang-socketio)

[theromis]

@darrachequesne Thank you for quick reply, yes I'm talking about server side golang-socketio.
Project mentioned by you is almost dead (last commit more than a year).
https://github.com/googollee/go-socket.io project looking for maintainer.
And non of them support socket.io v2.
I thought may be original greatest nodejs socketio developers could be interested in golang development too :)

[jflebeau]

Updated Java client would be nice too.

[cemck]

A socket.io package for server side swift like https://github.com/vapor would be very nice too since there is a swift client already.

[theromis]

Sounds like if server side socket.io will be written in some native language like C/C++ it can be used everywhere including nodejs, golang, java, rust and what so ever...
What's wrong with this approach?
My personal opinion socket.io is like de facto standard for modern world. Why not to make it ideal?

[perrin4869]

One thing that has always bothered me about socket.io which could be addressed in the next major release could be #2124 and #2343

There has been a historical inconsistency in the handling of namespaces and middlewares.
Also, the client emitting a reconnect event makes more sense in my opinion, after it connects to the namespace rather than it being just the Manager's reconnect event... For example, if there is some authenication error in a sub namespace middleware, the client will still get a reconnect event which I think is counter-intuitive.

[Twois]

From node version 10.5 there is a new Worker Threads, which is currently in experimental state, but when it released, I think it can be a better way for use socket.io instead of using redis server.

Pro:

• less dependency (redis)
• native support of multi threading
• more control

Con:

• only will work from that nodejs version what release the worker thread (10.x || 11). But this can be handled.

[darrachequesne]

@Twois interesting! It would work for workers on the same host, but what about multiple hosts?

@perrin4869 good idea 👍

[MickL]

I left a lot of ideas here: #3311 please read :) Will close that one and continue discussion here.

[darrachequesne]

@MickL would you have some time to migrate the socket.io repository to Typescript, as an example?

[MickL]

I am afraid my knowledge of network technology and information security is limited. I rely on high level frameworks like Express or Socket.io.

As far as i see socket.io is already written OOP and documented well so it would be a no brainer to simply port it. My idea was to go as modular as possible so someone like me could contribute more easy and the client ist treeshakable. Also going more reactive could be an idea to make things simpler. Anyway im not enough into the code so both ideas could possibly make no sense in this project tho.

[Twois]

@darrachequesne its a good, question. I will thinking on it.