Roadmap for v3 #3250
Comments
|
Looks like a great plan. I'm switching from nodejs to golang, and found there is no socket.io 2 implementation. What do you think of golang server support for v3? I'll be happy to take part in this development. |
|
@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) |
|
@darrachequesne Thank you for quick reply, yes I'm talking about server side golang-socketio. |
|
Updated Java client would be nice too. |
|
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. |
|
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... |
|
One thing that has always bothered me about There has been a historical inconsistency in the handling of namespaces and middlewares. |
|
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:
Con:
|
|
@Twois interesting! It would work for workers on the same host, but what about multiple hosts? @perrin4869 good idea 👍 |
|
I left a lot of ideas here: #3311 please read :) Will close that one and continue discussion here. |
|
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. |
|
@darrachequesne its a good, question. I will thinking on it. |
|
Require Nodejs 8 and above since earlier versions are at maintenance at best, see https://nodejs.org/en/about/releases/, at the very least nodejs 4 should be dropped(I noticed from .travis.yml that you support it) |
|
Has 3.0 related work started in any branch/repo? Just checking if there's a place to stay informed on how it's going or contributing. |
|
I would like to see improved support for error-handling on the server-side. This has been brought up in a few other issues, but more specifically, it would be great if:
The problem, at present, is that there's no way to add any kind of tracking or logging to an error once it has been
Generally speaking, Thanks for your hard work, and keeping at it! |
|
@darrachequesne Any update on v3 being a reality? I haven't seen any progress on this since 2018. |
|
A short update: my current contract was recently updated, and I should be able to dedicate one day per week (1/5th) to the project maintenance. Thus work on v3 should be resumed shortly. |
|
Really keen to help out on this project in one way or another. If there is a way to identify how I can do this let me know - I just don't want to potentially fix things for them to not be merged! So would rather wait for some guidance, if help is wanted. Cheers |
|
Compression is already supported (https://github.com/socketio/engine.io/blob/a05379b1e87d2e4cde40d3e30b134355883f4108/lib/transports/polling.js#L249-L298). The WebSocket compression (
Totally agree. Card added here
I'm not sure I understand. Could you please explain the use case?
You should already be able provide your own parser, like socket.io-msgpack-parser
👍, added here. |
That would be great indeed. Added here
Not sure what we could do. Do you have a suggestion?
Totally agree 👍 , added here |
|
Here's what I had in mind for fixing #2124 The client will now send a Which would mean that the middlewares that are registered for the default namespace won't apply anymore to clients that wants to get access to a non-default namespace // server-side
io.use((socket, next) => {
// not triggered anymore
});
io.of('/admin').use((socket, next => {
// triggered
});
// client-side
const socket = io('/admin');On the client-side, I think we should also make a clear distinction between the Right now: const socket = io('/admin', {
query: {
abc: 'def'
}
});results in requests like Besides, since there is no I propose to rename it to const socket = io({
query: {
abc: 'def'
},
authQuery: {
abc: '123'
}
});would result in requests like @perrin4869 would it make sense? Edit: regarding tradeoffs, there will be more HTTP requests on startup... While we currently have: |
|
@darrachequesne Thank you for taking this into consideration! It's nice to get some closure here, finally able to simplify the code I had back then :D |
|
Following the idea of how js shapes works: https://web.archive.org/web/20200201163000/https://mathiasbynens.be/notes/shapes-ics. To improve performance, wouldn't it be better to use arrays to store references for socket connections? More and more connections, countless ids and using objects to do this with each new connection, a new shape is generated and more memory is consumed, depending on the lifetime of a node and the number of connections it can have, this is probably will have some negative performance impact. |
|
@perrin4869 the trade-offs come from the current implementation, as we first establish the Engine.IO connection and then we proceed with the Socket.IO connection. Which gives, if the HTTP long-polling transport is enabled (which is the default):
But it surely could be improved. For reference, the change was implemented here and here. Besides, the @ferco0 we'll now use a |
|
A few notes:
Any feedback is welcome! |
|
@darrachequesne that's ok. |
|
@darrachequesne Many npm open source projects try to decrease the amount of dependencies. It is somewhat of a trend within the community. The main reason is that many organisations require checking licenses of all used dependencies when they are used in projects, to not run into legal issues. Having fewer dependencies helps with this of course. As an example, Helmet (a great security package for the Express web server) went to a zero-dependency install in the latest release 4.0. With that in mind, is there a plan to decrease the amount of dependencies in socket.io in release 3? |
|
@thernstig that's a good question! We've indeed tried to reduce the number of dependencies in Socket.IO v3: Here is the dependency tree for the server: I think that we only need the |
|
Note: [email protected] and [email protected] have been published I've added some examples with ES modules and TypeScript. |
|
@darrachequesne I leave that entirely up to your discretion 😄 |
|
@michaelegregious regarding your comment, I know it's been quite a while but did you have specific API in mind? I agree that the current API could be improved. It was implemented as a way to have a catch-all listener (discussed here), and not with error handling in mind. We could also add a way to warn users about unhandled events (404 responses in Express, http://expressjs.com/en/starter/faq.html#how-do-i-handle-404-responses). |
|
@darrachequesne great to hear your working on the next version of socket.io !! Thanks in advance for all your work on this library. I am currently testing [email protected] and [email protected] and I am trying to use the new syntax for joining a room and emitting to sockets in that room. I can not get the server to emit to the client socket using your example in the change log file.
Attached are screenshots that show the socket js file being used on the client and the code for the node.js server client side js file client side socket.on event server side join syntax inside the io.on("connect", I tried all the methods in the last sceenshot to get it to emit to the client and nothing works. Please let me know if you need anymore info. Thank You |
|
@darrachequesne I downgraded to 3.0.0-rc2 and join the room using join with the callback method called "room1" which is triggered but none of the emit events get sent to the client
I also uninstalled 3.0.0-rc2 and installed socket.io 2.3.0 for Server and Client and confirmed the above code works as expected. So I believe something is broke with the 3.0.0 rc versions |
|
@szarkowicz Hmm... I can't reproduce the behavior you are describing: https://github.com/socketio/socket.io-fiddle/tree/issue/v3 The following code seems to work as expected: socket.join("room1");
io.to("room1").emit('hello', 1, '2', {
hello: 'you'
});Do you get any error in the console? Do you get a |
|
@darrachequesne thanks for confirming. I have traced it back to using the redisAdapter causing the issue. Once I comment out the following code the rc3 version of socket.io works as expected.
Have you tried using redis with the v3 of socket.io? Thanks |
|
@szarkowicz yes, you are absolutely right, the Redis adapter needs to be updated to be compliant with Socket.IO v3, it will be updated right after the 3.0.0 release (which should be soon now). In any case, thanks a lot for the feedback 👍 |
|
@darrachequesne okay sounds good!!! I will just not use if for now and continue to test without it. Do you have a time when you think v3 will be released? No worries - thanks again for getting back to me and for working on all enhancements for the next version!! |
|
@darrachequesne Thanks so much for these updates! Sorry for my delayed response! We're not using Here's the note I put in our app's readme to explain the issue: So, in thinking thru this again, if you've already incorporated the ability to add a custom middleware to I'm looking back at that code and all my event handlers look like this (if it's helpful to see): Oh! One more thing I'm remembering. Here's a work around I used to be able to monitor outgoing events for the purpose of logging/error-handling: Here's the way I used the outgoing middleware if it's helpful to see: Thanks again for all your hard work! I'll try to respond more quickly next time.
|
|
@michaelegregious thanks for the examples you provided. (and no problem for the delay!) Technically speaking, I'm not sure we can catch the errors thrown by an async listener: socket.on("test", async () => {
throw new Error("catch me?");
});
try {
socket.emit("test");
} catch (e) {
// won't catch the error
}So I think it's better to let the user handle the errors by himself, either with the code you provided ( socket.on('quotes', async (params, cb) => {
try {
await dispatchQuotes(socket, params);
} catch (err) {
cb(err);
}
});What do you think? What is currently implemented for v3:
// server
io.use((socket, next) => {
next(new Error("unauthorized"));
});
// client
socket.on("connect_error", (err) => {
// err instanceof Error === true
// err.message === "unauthorized"
})Which also means that "error" is not a reserved event name anymore.
// server
io.on("connect", (socket) => {
socket.onAny((event, ...args) => {
});
});
// client
socket.onAny((event, ...args) => {
// ...
});Does it sound good to you? Do you have any suggestion? |
|
Hi everyone! [email protected] and [email protected] are out. You can test them with We plan to release 3.0.0 by next week. The migration guide has been created: https://socket.io/docs/migrating-from-2-x-to-3-0/ (some details are missing, like the reserved events on the client side) As usual, feedback is welcome! |
|
I have a doubt, i don't know if here is the right place for it, but it's possible to define the socket id on connection, for example, to use the client id come from db? Changing the "id" prop of the socket object on connection middleware makes the sincronization with the client? |
|
@darrachequesne Thanks for the RC4 update.
Going to be doing lots of testing over the next few days with rc4. Thanks again for all your hard work. |
|
@ferco0 it's not currently possible, the Socket#id is generated here. In your example (client ID from db), what happens if the same user opens a new tab? (since the Socket#id must be unique)
(it was named
There is currently no API for that, apart from digging into the adapter: Besides, the Redis adapter has an allRooms method, but it was not reflected in the public API. |
|
Okay really appreciate the info to get the clients and rooms for both with Redis and Non Redis. I will probably start testing with just socket.io v3 until the Redis adapter is updated. |
You could take a look at https://github.com/formium/tsdx as an alternative. |
|
🚀 Socket.IO v3.0.0 is out! 🚀 The release notes can be found here: https://socket.io/blog/socket-io-3-release/ Thanks to everyone involved in this thread for your ideas/feedback ❤️ |
|
@darrachequesne, that all makes good sense to me. I forgot about that issue re. async middlewares (in my current project we've created a Thanks for all the improvements!
|
@michaelegregious could you please open a feature request for that? Thanks! I'll close this issue now. Discussion about the release: #3674 |
This list is open to suggestions!
That is obviously the major pain point of the project.
Currently the client emits a
pingand waits for apongfrom the server, relying onsetTimeout()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
pingis 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.
generateIdmethod asynchronousThis 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!
The text was updated successfully, but these errors were encountered: