node
node copied to clipboard
nodejs
Adding Websocket support to core
The original thread where adding this was discussed #1010 was closed with a decision by the iojs TC to rather implement lower level buffer methods, but that was abandoned.
There is an open EPS to add the feature, but we have since abandoned the process.
Some of the people who originally were -1 changed their opinions in #1010 more recently. In fact, we already ship a partial implementation of ws in the inspector.
I think it might be worth us revisiting adding WS to core.
/cc @eugeneo @rauchg
Re: Inspector.
- Inspector WS implementation is not complete, e.g. there is no support for binary frames.
- Inspector would still need a C++ implementation that can run on a separate thread. Both JS execution and main libuv loop are suspended when the application hits a breakpoint.
i'm not wholly against this but i would like to factor in how much stuff we put into all our release binaries. if we can come up with more creative ways for shipping stuff like this i'm totally a +1 (#19307)
As discussed in #1010 and as a maintainer of ws I'm +1 on adding WebSocket to core.
@mscdex in #1010
-1 WebSockets is still something better suited for userland IMHO. Sure it's something that many people do use, but there are also many other widely used standardized protocols/APIs that could be argued as "core" to the "web" that are not currently included in node/io.js core. For example: multipart parsing/generation, Server-sent events, HTTP/2, ICMP, SSH/SFTP, FTP, SOCKS, VNC/RFB, SMTP/IMAP/POP3, SOAP, Web Workers (as an API), XHR/XHR2 (as an API), etc.
Since this original post we've added http2. While you listed a bunch of protocols not all of them are supported natively by the browser.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
https://caniuse.com/#search=Websockets
@MylesBorins I don't think node should aim to become a (DOM-less) browser. Anyway, my "vote" and reasoning still stands.
http2 is an argument against being too eager to absorb protocols into core. Neither its API nor its implementation are all that great; it would have benefited from iterating outside core for a while.
I guess you could construe that as an argument in favor of websockets: third-party modules have existed for years and their APIs and implementations have pretty much crystallized by now.
This is a great idea. While today Node is already an indispensable tool for web developers it does not enjoy the same full seat at the table of web browser tech advancement despite being held completely captive by it. Few agree on the controversial edicts like Promise and esmodules but we can definitely all agree these transition moments could have been handled better with Node being an a fully active participant instead of recipient of these challenges.
Node has a big opportunity to become a full fledged user agent (web browser) and first class support for web features will be a part of that. +1!
http2 is an argument against being too eager to absorb protocols into core. Neither its API nor its implementation are all that great;
PRs welcome.
Re: websockets
I'm still -1 for the time being. This is something that has been done quite well by userland and there are still unanswered open standards questions about http2+ws that require more thought and experimentation.
When http2 was added, I think one of the considerations were that we could do a lot of low level stuff in C++ land that was hard or even impossible(?) to do efficiently in user-land. Is there a similar reason for wanting to bring WS into core, or is it just to have more features?
@jasnell can you point me towards the open standards discussion regarding h2 + ws?
The ietf httpbis working group is working on this .... https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00
It's still super early in the process tho there is some early implementation happening.
Ideally there should be a clear general framework on how to decide whether something belongs to the core or not. I would consider points like
- is it hard to be done right?
- is it widely used?
- does it have a clear spec?
- is it likely to become obsolete in the near future?
- does it need optimizations from the core?
- will the entire community benefit from it being part of the core?
is it hard to be done right?
@kof I fully agree with all your points except this one – there is no reason to believe that code in Node core is better-written or better-maintained than userland code in general.
I think a better question in its place would be “Is it hard to do effeciently without native addons?”.
@addaleax The idea behind that point is: if it is in userland, it is likely there will be multiple competing implementations, which will result in attention not being fully focused on a single code base and as a result lower quality, just because less people are working on it or using it. I have no data to back it up.
Userland is good when a feature needs experimentation.
@kof
is it hard to be done right?
No.
is it widely used?
Yes it is.
does it have a clear spec?
Yes.
is it likely to become obsolete in the near future?
No.
does it need optimizations from the core?
Not necessarily but optimizations in core may help. In ws we have two optional binary addons. One for the masking/unmasking of frames (bufferutil) and one for the UTF-8 validation (utf-8-validate).
will the entire community benefit from it being part of the core?
Yes I think the community will benefit from WebSocket in core.
There are a lot of userland implementations. The most popular are ws, faye-websocket, and websocket. Combining the the best parts of each one of them to create a single module in core would be great imho.
+1, mainly because @lpinca has been doing a great job in maintaining ws the last few years.
So far I haven't seen any concrete comments on why implementing WS in core would be better than having it in user-land. I'm sure @lpinca have done a great job maintaining ws, but that hardly qualifies as a reason to bring it into core right?
I just think there need to be concrete examples on how core can provide a better WS implementation than user land 😃
i don't think there's anyone saying we would do a better job. i think the argument is better integration and since we can ship it with a native backing users will get a perf boost without having to install anything.
@devsnek Could you provide an example of how the integration would be better if WS was in core?
Regarding native backing then n-api and pre-compiled binaries should remove the requirement of having users compile stuff (if I understood your argument correctly).
It seems the main argument for adding ws to Core is to reduce binary dependencies. Since both native dependencies are buffer-based, I think they may be good candidates for adoption of WebAssembly. @lpinca has that been seen as a possibility?
For an API, I'd like to propose the WhatWG WebSocket API, as much as we can implement the standard (I know there will be some inconsistencies around events).
If we run into any serious problems with the API design we can attempt to work with the whatwg to update the standard. It seems like @TimothyGu has participated in this document along with @domenic.
re: http/2 + ws, if we get an implementation going we can participate in trying to solve this problem!
will the entire community benefit from it being part of the core?
I think implementing standards in core, especially ones implemented in the webplatform, can help the ecosystem focus on creating better abstractions on top of a protocol like WS, and avoid having to implement the base protocol themselves. If the various ecosystem modules share a kernel it allows there to be collaboration across projects with a shared interest, and potentially brings more people to help maintain core itself.
@watson userland implementations work and I'm a big supporter of small core but HTTP(s) and many other modules are in core because they are so popular that it made sense to create a core module for them. The same is valid for WebSocket in my opinion. Quoting @domenic from https://github.com/nodejs/NG/issues/10#issue-59860208
I think the conclusion of this line of thought leads us to a process wherein we say "yes, core is interested in supporting feature X." Then, someone---maybe an io.js collaborator, or maybe not!---goes off and builds a prototype of feature X as a user-land module. Along the way, they might need to ask for more low-level APIs from core, and those will get rolled in. But over time, this external implementation of feature X matures, and io.js collaborators start commenting on it, and the ecosystem starts using it, until we decide: yes, we should roll this in to core, and start shipping with it.
Is core interested in supporting WebSocket? That's an open question. I think it should.
@TimothyGu we didn't explore that possibility but that's definitely a good idea. We already have prebuilt and n-api based binaries for native addons. Removing binary dependencies is not the reason why I would like to see WebSocket in core though. The question is, why is HTTP and HTTP2 in core and WebSocket isn't? They all are in the same league and they all can live in userland if wanted. On top of that a good part of the WebSocket implementation is already in core as the upgrade mechanism is already available and supported in core.
@MylesBorins If we ever decide to experiment with WebSocket in core, API need to be discussed. I think we want to support piping data around so a websocket should be implemented as a Duplex stream like faye-websocket does. I guess we also want to support fragmented messages and permessage-deflate. In this case we should augment the standard send() to add the ability to specify if a message is the last one in a fragmented message and to specify if a message should be compressed or not.
I can't establish a vote for this, although would be a nice to have.
I found that WebSocket implementation isn't that solid neither in the Browser.
Is high cpu consuming and so far I couldn't see any implementation in a big scale (which I would have guess they would be using it); eg: Facebook, Twitter and Gmail, they rather relay on polling.
I guess is mainly related on the cost created on the Server side due being really hard to scale it (eg. Load balancing). Not sure Node wants to make his capacity in supporting it.
I would argue that it's actually easier to scale WebSocket than HTTP polling and it's way more CPU efficient. The protocol was designed to solve the HTTP polling problems, see https://tools.ietf.org/html/rfc6455#section-1.1. With WebSocket you have a persistent TCP connection, no HTTP headers overhead, seamlessly integration with the cluster module (no need for sticky sessions).
@kof with WebSocket it doesn't matter as long as the TCP connection is established, all messages are sent over the same connection so they all hit the same server. Sticky sessions are required for HTTP polling.
@lpinca By frequent reconnects I ment reconnects on the TCP layer (when connection is dead for real)
@kof not sure I understand. The websocket is closed along with the underlying TCP connection and a new one created.
Isn't it similar to long polling from performance perspective on bad physical connections at scale?
Yes, but ideally the majority of TCP connections are stable no? And even in the worst case scenario it's still better than long polling.
Given the discussion I'm coming around on this, but what I'd like to see is a process similar to what we followed with N-API and http2... specifically, work on the new module being done and proven out in a separate fork repo before work being committed here in the main repo. Doing so allows greater flexibility in experimentation and implementation without disrupting anything else happening in core. It also allows implementation progress to be made in advance of a full commitment to "landing" it as a feature.
I'm mostly indifferent to whether WebSockets should be in core at this point, but I lean toward the opinion that it should not. I don't feel it's anywhere near as widely used or fundamental as HTTP is, and it would end up just being more for the core team to have to maintain. That being said, my WebSocket implementation hasn't required much maintenance since becoming stable.
Honestly, I kinda feel like it doesn't really need to move into core. As it stands, the community benefits from multiple competing stable implementations, without there being so many that it's difficult to pick one. Each implementation has its own particular API that fits better for different coding styles or use cases. If Websocket was implemented in core, it would instantly become the One True Implementation and the One True API, and I'm not sure that's especially beneficial. Alternatively, it may try to be all things to all people by supporting multiple kinds of APIs, and that would create more surface area to maintain as well as more planning and design work up front. It may end up being less good than what we already have now, at least until enough work has been put into it to evolve it to something stable. And all that work would essentially be just re-inventing the wheel.
Core optimizations to support Websocket implementations might be nice. Or a new optimized C++ implementation that does a majority of its processing work off the main thread might be interesting (Websocket perfectly lends itself to an entirely async API anyway), but I'm not sure even that kind of project would need to live in core.
And all that work would essentially be just re-inventing the wheel.
The same is true for all of us working on competing userland implementations. We are writing the same parser, the same extension parser, the same frame builder, the same extensions, the same < insert WebSocket detail here > instead of solving the same problems together.
I totally agree with @lpinca. Node is already some kind of a core for these libraries which provide WS, so it should bring maintainers of these libs together.
Each implementation has its own particular API that fits better for different coding styles or use cases
Fragmentation of implementations is not good for any standard. Look at browsers. They all have different implementations of JS, CSS, etc and it's a pain for developers and users
-1 for the very same reasons as given by @mscdex. I think that already having added http2 support was wrong with respect to this.
Apart from that it’s hard to get the feature set right. Should it support reconnection management? wss? Middleware?
This quickly becomes too much, but if you don’t do it people will still stick to userland solutions.
Should it support reconnection management?
No, not a core business.
wss?
Yes, the only difference here is using the https module instead of http. This is transparent to the implementation, it's exactly the same code.
Middleware?
No, this is not a framework. It's not Socket.IO, SockJS, or Primus. The aim would be to add a building block for those framework. A low level module like http which is basically used by all userland modules that need to work with that protocol.
Exactly. That’s my point: If you need the userland modules anyway, then why introduce it in core?
I'll answer with another question. If you need express or hapi, why having http in core? 😄
TBH, I don’t know (and seeing that projects such as https://github.com/mafintosh/turbo-http are started shows that it is not even needed to be in core).
My understanding was always that core should only include things that are so vital to Node.js itself that they can’t be done in userland.
So you basically agree with https://github.com/nodejs/node/issues/1010#issuecomment-85207951. Yes, that's a valid point.
As I see it there's two ways to look at whether something should be in core:
- It can be done better/more performant in core than outside of core
- It's a widely used module/technology
Some people in this thread use point no. 1 as a criteria while others use point no. 2. As long as we don't agree on the premise of when something should be included in core, we'll not have a constructive debate.
I think this is a very important distinction and something that isn't related to WS at all. Before we deal with whether or not WS should be in core, we need to come to a consensus on this topic first.
Going to drop some thoughts here since @MylesBorins tagged me in. For context, I maintain the Faye collection of packages: faye, faye-websocket, websocket-driver, websocket-extensions and permessage-deflate. The Faye project dates back to Node v0.1. I also maintain Ruby versions of these packages (websocket-driver is the WebSocket implementation in Rails), which is an interesting source of comparison and has influenced the design of the Node versions. I don't really have an opinion on whether WebSocket should be in core, because I don't maintain core, but I do have some thoughts that might be useful if you do decide to include it.
I can talk about what's good and bad about working with WS in Node and then wrap up with some thoughts on API. First, good things.
A single HTTP server. Ruby has a dozen competing I/O and concurrency frameworks and associated web servers, which makes targetting any networking abstraction at a large user base difficult. This is the reason websocket-driver exists; it separates the WebSocket protocol from the I/O implementation. Node putting a good HTTP server/client in core means it has not generated the same competitive ecosystem in this space. This has ups and downs but one up is definitely that it enables more stuff to be built on top of it and be widely useful; like Promises it's a case of a standard being in core enabling interop in the rest of the ecosystem.
HTTPS/TLS. The TLS abstractions in Node are much easier to use than what I've seen in other ecosystems, and their API is similar enough to their plaintext counterparts that deciding whether you want a plaintext or encrypted connection nicely separates from any other concerns, at least in terms of API surfaces.
Streams. The abstraction that allows websocket-driver and faye-websocket to be piped into other streams without having to know how the destination works is really valuable. In order to contend with all the I/O implementations in Ruby we had to essentially invent a read/write API for ourselves, and it's not without problems. I've had conversations with maintainers of Ruby servers about how we should handle back-pressure and I essentially told them to do what Node does.
Buffers. Having a data type that specifically represents a block of bytes that is distinct from strings is a huge ergonomic win.
Performance. The Node implementation of websocket-driver performs well enough that I've not been tempted to use native code. In Ruby, masking is enough overhead that I wrote that in C. I've also tried porting the entire parser to C but the performance win doesn't seem worth the huge added security risk.
Now, things that could be better. I'm totally prepared to admit some of this is down to my own lack of knowledge; I don't have a huge amount of time to dedicate to this work so I might be holding a few things wrong. Also a bunch of this was developed years ago when I knew less.
HTTP parsing. It's really weird to me that there's an HTTP parser in core but
it's private and the advice is to use a third-party module that copies its API.
If we put protocols in core, being able to use their parsers but bring our own
I/O control is a huge win. websocket-driver used the core HTTP parser until
recently and I'm not sure why it couldn't be made public. Maybe there's
something in the http module I could use to send a request and be given a
parsed response object and the still-open TCP connection. But in any case
there's other complexity to contend with once you add proxies to the much and I
was more comfortable setting up a TCP socket myself and then doing all the HTTP
on top of that.
UTF-8. Validating UTF-8 is a bit tricky to do; I'm resorting to converting a
buffer to a binary string and using a regex. It would be nice if there was a
streaming UTF-8 validator/decoder in core. Perhaps there is already a way of
doing this with encoded streams? The thing is, implementing UTF-8 is not
actually hard (if all you want is "is this a valid UTF-8 byte sequence",
ignoring all sorts of unicode semantics), I've done it in other places, but it
didn't seem worth the effort here. The regex probably performs better than
anything I could do in pure JS anyway. Ruby has a baked-in method for this;
String#valid_encoding?.
Streams2. I never adopted the Node v0.10 streams API. At first this was
because I was supporting older releases, but now it's because I never figured
out how to make streams2 do what I want. In particular, it didn't seem as easy
using the basic read()/write() APIs to maintain message boundaries (i.e.
separate messages should show up as distinct data events), and to emit strings
and buffers (which we use for text and binary frames) on the same stream. I've
tried to figure this out a few times and given up. The current
implementation uses old-style streams. It's extremely basic and probably
wrong, but nobody has ever filed an issue about it.
Concurrent processing. There is a whole abstraction inside
websocket-extensions that deals with asynchronous processing in extensions, i.e.
passing messages through transforms that might be async, in two directions,
maintaining message order and closing extensions when all pending messages have
passed through them. This was a huge headache to build and it's effectively a
single reduce() call in Ruby. I'm not sure what abstractions should exist to
make this easier; it's possible that Promise and async functions might ease the
pain. This is also more of a JS problem than a Node one, but building this made
me keenly aware that JS still has a way to go to make concurrent processing
easier.
The upgrade event. Separating some HTTP requests off like this is annoying
and makes it harder to build composable middleware or add WebSocket support into
existing stacks. It's usually easier to stand up a separate server that knows
how to do WebSocket and have that be different from your app server. This isn't
a massive problem because there are also operational reasons for doing this, but
having the option of making composition easier would be nice.
Those are things that could be improved to make implementing WebSocket easier. If WebSocket were to go in core, here's a few things I think are worth bearing in mind. I'm not arguing you should adopt my code or API here, just listing some user needs/benefits that an implementation should support.
First, the API. Starting with the WhatWG spec is good. In Faye, the integration code for WebSocket is almost identical on the client and server because faye-websocket implements the same API as the browser. However, it's not enough. On the server, you want control of what extensions are in use, how they are configured, which protocol versions you support, sending ping/pong frames, additional handshake headers, using cookies with the client, using proxies (tunnel-agent helps here), and other things. The API needs to be expanded to allow all that.
Second, it would be good to separate the protocol from the I/O layer, as websocket-driver has done. I initially thought that design would be more relevant in Ruby due to the divergence in I/O libraries, but many modules in npm depend directly on websocket-driver and not on a higher-level package. I think this will be especially useful as HTTP/2 becomes more important, letting people pipe the WebSocket protocol into whatever stream they can construct over an H/2 connection.
It is tricky to say where that separation should lie. I've recently been asked to ship something that avoids doing the HTTP handshake on the client; the user wants to do that themselves and then hand the TCP socket over to websocket-driver for it to take over. However, the driver needs information from the handshake phase such as which version was negotiated, which extensions are enabled with what parameters, etc, and the thing making the handshake request needs to know what extension settings the driver supports. Some versions of WebSocket make the handshake leak into the request body as well, which makes things harder to separate. But if you're OK with letting websocket-driver send the HTTP handshake, you can pipe it into any connection you like.
That brings me to my final point, which is extensions. In websocket-extensions, I attempted to build something that would allow WebSocket libraries to interoperate with extensions in a pluggable way. Most users of websocket-driver use it indirectly, via faye-websocket, faye, or one of the hundreds of modules build on top of them. Rather than every one of those intermediate packages providing an interface for configuring extensions, websocket-extensions means extensions can be passed into a WebSocket stack as first-class objects that carry their own config. To configure permessage-deflate, you only need to know the interface to that module, and then you can pass an instance of it into anything built on top of websocket-extensions. This means other extensions could be built and added to existing stacks without every dependency between your app and the WebSocket library having to add support for it. They only need an interface for passing extensions in and they don't need to care what the extension is or how it works.
This also has an important effect on the dep graph. Something that uses faye-websocket and permessage-deflate has this graph:
.
├─┬ faye-websocket
│ └─┬ websocket-driver
│ ├── http-parser-js
│ └── websocket-extensions
└── permessage-deflate
When we had the problem with zlib causing a DoS, users were able to cope with the situation just by removing permessage-deflate from their setup, and they still had a working WebSocket stack. They were able to update just the permessage-deflate module without waiting for intervening deps to publish updates, as often happens with modules with tightly pinned dep versions. This is possible because if you're using the extension, you have it as a direct dependency, rather than getting implicitly via a chain of other packages.
This design is not something I've often seen in standard-library implementations of things. Such implementations are usually more of a black box and don't provide API contracts that can act as extension points. Such contracts allow the module not to be a bottleneck on users extending something, and much of Faye is designed with this is mind.
Ultimately I think the benefit of putting things in core is that they enable ecosystem interop as I mentioned for HTTP earlier. Whether this is a big deal for WebSocket I can't say; I think most web frameworks just embed a WS library they like and if they do expose it to the user they put their own abstraction on top. I'm not aware of much demand for people going "I like Framework X but can I swap in my own WS API", or wanting to compose things atop WebSocket such that it acts as a common interface. I might be wrong though.
@jcoglan I can’t speak much to the websocket-specific stuff, but this was a very helpful comment to me, but I would be interested to hear more about two things you mentioned:
It's really weird to me that there's an HTTP parser in core but it's private and the advice is to use a third-party module that copies its API. If we put protocols in core, being able to use their parsers but bring our own I/O control is a huge win.
Yes, that was weird to me too, so I opened https://github.com/nodejs/node/pull/16267 to allow the built-in http module to work with generic Duplex streams as the underlying resource. If you have thoughts or feedback on that, or more details on what you think would be helpful to have in core to support this, I would love that.
Validating UTF-8 is a bit tricky to do
It should be easy to get this into core if we want to. I don’t know about previous efforts, but if you have suggestions for how the API should look like, maybe just open an issue on this tracker?
As mentioned above we are using https://github.com/websockets/utf-8-validate for UTF-8 validation. It works directly on a buffer, no regex needed and has a pure JavaScript fallback. It doesn't work in a streaming fashion though.
As a (very happy) user of ws, I respectfully suggest that it makes sense to keep it in userland for a while longer. Why?
- It's still undergoing active, and excellent, work by lpinca and others. If it gets put in core then it ties together release cycles that are now independent. As things stand it's possible to use a LTS release of node, but upgrade to a recent ws version if need be. That is good (for my stuff anyway).
- (philosophical argument) Avoiding turning node into a monolith has a lot of merit.
I was kindly notified of this topic by the Node.js Weekly Mailing list. We probably want to loop in everyone that ever maintained or written a WebSocket implementation in the past to give their opinions on this matter. cc @brycekahle, @josephg, @darrachequesne, @alexhultman might have opinions on this as well.
I maintain various of WebSocket (and real-time) related projects, given advice to companies to tune their WebSocket implementation as well as maintain a web service that processes millions of WebSocket messages a day.
We see that WebSocket projects are still heavily used on Node.js, just by looking at the downloads on npm we see that that there millions of downloads each day to install WebSocket libraries. So we since the completion of the specification, introduction of WebRTC and HTTP2 it's still a technology that people choose to adopt in their projects. Or is used by the technologies, for example WebSockets can be used for handshaking in WebRTC and work is done to include WebSockets in HTTP2 again. It's not a dying breed and if you ask me, it should be have been in core since the specification was completed. It's also not an technology that can be easily implemented on top of HTTP like EventSource/Server Send Events to a real-time stream of data. So to me, it's quite clear that WebSockets is not going away any time soon and has been adopted by many already as core part of the web.
There are various of userland modules that add WebSocket support to Node.js, faye-websocket, websocket, ws, uws. They all have different approaches to solving this issue. Some are written in native code, others in JavaScript or a combination of both. In addition to these, we also have modules that bind to other existing WebSocket libraries such as libwebsocket. So the question is, is this good enough? When I look at ws I feel like have reached the end of what is possible performance wise in JavaScript. It's fast, pretty damn fast, but also uses a lot memory. And in order to go faster we had to use native addons. Projects like uws has shown that it's much more efficient to do it all in C++ as Node.js can get on the heavy side when dealing millions of connections and buffers. But what the project and the ws binary addons also showed is that user land based binary add-ons are a massive pain.
As pointed out by @eugeneo Node.js already ships with a WebSocket client, a bare minimal implementation just to interact with the WebSocket API of the WebInspector, but it's already there. It needs to be binary to work outside of the event loop to work during debugger statements/breakpoints. That means if we want to have a WebSocket implementation in core, it needs to be C++ in order to share code, that also makes things like UTF-8 validation, buffer handling, masking of frames a lot easier.
So technically, we already have WebSockets in Node core, the question is, should we expand/improve this and expose this? HELL YEAH
So technically, we already have WebSockets in Node core, the question is, should we expand/improve this and expose this?
A feeling tells me that node.js should have a WebSocket global because it already has WebAssembly, while a WebSocket server is fine to be provided by userland. That is, unless there are code sharing advantages between the two.
@3rd-Eden sorry for not tagging you in the conversation didn't want to bother. uws bindings disappeared from GitHub yesterday but afaik most of the performance and lower memory usage was obtained by not using net.Socket, similarly to what is done in https://github.com/mafintosh/turbo-net.
I'm perfectly fine with that if it can be done in a compatible way with the existing http module.
Speaking of turbo-net, there's already a turbo-ws built on top of that: https://github.com/hugmanrique/turbo-ws
@lpinca Hi 👋 any difference between using socket.io and websockt natively? I am new regarding the protocols, what difference will there be if websocket is integrated to the core of nodejs?
Thank you for taking the time to read my question 😸
@MAPESO thats a bit off topic for this. socket.io is a wrapper around a bunch of different hacks and connections (including websockets) to make sending messages between server and client possible extending back to really old browsers. beyond that it also abstracts the connections into "channels" and such. in the topic of this conversation socket.io and websockets are not at all equivalent (and as long as we're on the topic of perf, its worth noting that socket.io is pretty slow)
@devsnek I know, my question was off topic, but as I do not have much experience in protocols😄
Thanks for the write-ups @3rd-Eden and @jcoglan. I wrote browserchannel in the node 0.4 days because there were no better options. At the time websockets didn't support cookies and would often break in unexpected ways with new browser releases. Socket.io had an incoherent story around reconnection, and could arbitrarily reorder messages on reconnect. The sharejs issue tracker had more bug reports due to socket.io's bugs than due to any of my own code. I rewrote sharejs on top of faye at one point - I can't remember why I stopped using faye, but the way faye extensions work left a lasting impression on me. Its a beautiful API, and I'm still a little bit in love with it. I used that model for the sharedb extension API.
There's an interesting set of engineering philosophy around how reconnection works that is rarely discussed - if a client disconnects and reconnects, should you think of this as a new connection (and have the client and server reestablish state), or should you migrate state from the old connection? Browserchannel does the former, and socket.io the latter. I believe reestablishing state in the application is the correct choice - in practice migrating state from the old connectionn is way more complicated than you would expect. (How do you handle multiple active tabs? Do you need server affinity? A session database? Do subscriptions need object references? , etc). But of course, if you need your own reconnection logic then its harder to use someone else's magic auto-reconnection code. Socket connections are stateful. They're useful because they aren't request-response, and pub-sub does not cover all the use cases of a socket connection either.
Personally these days I use (and recommend) pure websockets for all my projects. This seems obvious but is probably worth saying anyway: If websockets enter core, the API of ws is about the level of abstraction I think we should aim for.
Most of the points I'd like to make have been made well above, so I'm going to expand and reiterate some points from above I agree with:
- I agree with @jcoglan that the streams2 API is still incoherent and confusing. I'm sad that nobody cleaned it up. To this day I still run into random issues with message framing because nobody really knows how to use streams correctly. It is very difficult to build an accurate mental model of how they work. Eg, what is the relationship between the
close,finishandendevents? Are_readand_writere-entrant (that is, can multiple invocations be running concurrently?) Even with reference to the documentation these questions are crazy hard to answer, which is an unfortunate mess. If it were up to me I would ask dominictarr and substack to put a replacement streaming library in core. But thats a separate rant. - We don't have a framework for deciding what should be in core and what shouldn't. It seems like some people think almost nothing should be in core and will vote down any attempt to add to the surface area of core. I respect this. And also
wsis widely used, stable, well understood and a centralised implementation would benefit people. Going by @kof 's criteria above, ws is:- [x] is it hard to be done right?
- [x] is it widely used?
- [x] does it have a clear spec?
- [x] is it unlikely to become obsolete in the near future?
- [ ] does it need optimizations from the core? (partially - it could definitely benefit from binary implementations)
- [ ] will the entire community benefit from it being part of the core? (no - websockets are used widely but still only in a minority of projects)
- I don't find the argument that because we have a partial websocket implementation for the inspector we should expose it particularly compelling. If the inspector needed to generate SVG files, would we add that to core too? If we're going to expose APIs for everything in core, there's a lot more stuff we could talk about exposing. (Like the http parser.)
Is there still a node technical committee with teeth? I'd like to defer the question of "on what basis do we add stuff to core" to the TC, because thats a question that affects more than websockets. If we decide nodejs should become a monolith of good and useful code, we should add ws. If we decide node should be minimal and defer to curated lists of good npm packages, there's lots of good ws libraries to recommend.
Personally I think there's a middle-ground that I'd like even better: Have an official list of recommended solid, default modules for specific tasks in nodejs. These could be decided on however we like. The official documentation should list these modules. The list wouldn't be fixed - if the community decides that ioredis is better than redis, the recommendation should change. Its the best of both worlds - we have a large, blessed, official standard on lots of stuff. And also the standard can evolve and change as fast or as slowly as we like without breaking any existing code. (Release notes for node version 20.0.0: The official recommendation for streams is now X. It has these benefits (link), see (discussion) and (migration guide)). Then maybe npm init --extended automatically adds stuff like the recommended version of streams and http2 to your package.json. And then lots of things that are in core can be migrated out, and we get a nice tight minimal core surface area, as many delicious features as we want and users have full control over when (if ever) they upgrade those modules. The recommendations for specific tasks would change less frequently over time, at the discretion of the community. But thats probably a separate discussion.
I don't think node should aim to become a (DOM-less) browser.
I think this is worth exploring a little bit, because it's sort of counter to the original vision of Node.js.
When Node.js was released in 2009 there was a broader movement to make new platform tools that were "of the Web" rather than the Web being an afterthought. Platforms like Perl, Python and Ruby were released initially without an HTTP API and the stdlib modules added later to fascilitate it felt a bit second class and there were often multiple HTTP abstractions in stdlib (Python had 2 or 3 at the time).
What set Node.js apart, other than being in JavaScript, was that HTTP was a first class citizen. In fact, early releases of Node.js included HTTP and did not include UDP, there was even some question at the time as to whether it should add it.
Node.js adopting new core protocols of the Web is perfectly in-line with its original vision and only a dogmatic originalism could argue otherwise. There may be perfectly good technical reasons not to include Web Sockets but the argument that it is somehow out of scope doesn't match the history or vision the project has had since day one.
http2
One thing I'm surprised I didn't see pointed out already was that when http2 was implemented by @jasnell he created an API and an implementation that specifically took advantage of being in core that out-perform anything possible in userland. Why can't the same be done for WebSockets?
@mikeal good argument, well made. I’m convinced; I think we should add it.
I’m curious though - what did @jasnell take advantage of in core that couldn’t be done easily in an external module?
@josephg if I recall a lot of what the HTTP/2 implementation that is unique is how we maintain data in C++ land and minimize how much it needs to be brokered between C++ -> js... if I recall this level of optimization would not really be possible in a native module as things are being handed around between node + nghttp2 + v8 + libuv
That's not true. Core has more supporting infrastructure for new code to piggyback on but there is little that you can't also do from a native module. n-api was a module before it moved into core, http2 could have been too...
...and arguably it should have been because of the much shorter feedback cycle. n-api fixed design flags within days, http2's feedback cycle is closer to 6 or 12 months.
@bnoordhuis what you are saying is incorrect regarding n-api and http2. They followed the exact same path before landing in core with the majority of the work being done in a separate fork of Node.js (https://github.com/nodejs/abi-stable-node/tree/api-prototype-8.x and https://github.com/nodejs/http2) where a team iterated over the implementation.
I would also kindly ask to stop pointing out that the http2 has severe design flows without writing what they are. Open up an issue or a PR to discuss, and keep this issue relevant to WebSocket.
@mcollina The salient point is that n-api was available as a npm module before it got built into core and that was what allowed it to collect feedback and move at a high pace.
To drive home the point why that is relevant to websockets: they shouldn't be added to core until it has evolved a stable API. I think that is effectively the case but I use http2 as an example where that didn't happen - and it's stupid of us because it's not as if it's the first time we made that mistake.
Clear now?
@mcollina The salient point is that n-api was available as a npm module before it got built into core and that was what allowed it to collect feedback and move at a high pace.
I couldn't find a reference to that module in most of our respositories, can you please add a link?
To drive home the point why that is relevant to websockets: they shouldn't be added to core until it has evolved a stable API. I think that is effectively the case but I use http2 as an example where that didn't happen - and it's stupid of us because it's not as if it's the first time we made that mistake.
This can be said to streams, async_hooks, trace_events and a lot of the new things that landed in core. Some of them are flagged as experimental for a reason.
If we want to have a WebSocket implementation in core, a team is spawn up and a fork nodejs/websocket is created. Then the team iterates on their implementation there, and then do a "big" PR with the new feature. This is the approach that we have followed for both n-api and http2. I agree that it enables a fast iteration on the API design.
I couldn't find a reference to that module in most of our respositories, can you please add a link?
Getting mildly off-topic but okay, for posterity: https://www.npmjs.com/package/node-addon-api - released some months before the first node.js release that bundled n-api.
This can be said to streams, async_hooks, trace_events and a lot of the new things that landed in core. Some of them are flagged as experimental for a reason.
True, but async_hooks and trace_events can't be done as modules, and streams... yeah, what can you say about streams?
Getting mildly off-topic but okay, for posterity: https://www.npmjs.com/package/node-addon-api - released some months before the first node.js release that bundled n-api.
~~node-addon-api never bundled n-api, it's just a C++ wrapper on top of C API of n-api. n-api itself never made to npm, and even node-addon-api was released after n-api was already landed in core.~~. You are right on this point.
Still, n-api itself landed in core 1 month before the first release of the module itself. n-api was not iterated in the ecosystem (it didn't have a significant adoption), it has always been a node core component.
what can you say about streams?
Considering how many developers are complaining in this thread, we should have iterated a bit more on them.
node-addon-api was released after n-api was already landed in core
The terminology with n-api is kinda confusing so to be clear, it was added to core in #11975 and that wasn't released until end of May. The first node-addon-api release was months before (edit: but now that I think of it, it probably depended on nodejs/node-api in some way.)
(enough derailing though)
what did @jasnell take advantage of in core that couldn’t be done easily in an external module?
Depends on what you mean by external module :-) As with just about every core module, it could have been implemented entirely as a native module. The majority of the heavy lifting in the http2 code is handled entirely at the native level with (as @MylesBorins points out) data flow being coordinated between nodejs, libuv, and nghttp2. The JS layer really only deals with the Streams API and public facing API.
More on the point for this particular thread... the initial implementation work on a possible WebSockets module for Node.js should move forward in a separate repository -- exactly as happened with other major initiatives like http/2, n-api, and now worker support. Once that work progresses beyond the rough ideas and into the coherent implementation phase, bring it back into the main repo. Thus far this has been a very successful pattern.
This repo can be created here within the nodejs github organization. I'm happy to go create it now along with the github team that will have commit access to it. Or, as was the case with the early http2 work, that can be done in someone's personal github account. It really does not matter. Let's just stop debating irrelevant side channel things and get focused on exploring this.
Just keep in mind that exploring it doesn't mean that it automatically makes it in to core. A decision will need to be made based on the specific merits of the implementation. I think there's sufficient community interest, however, to say that this is definitely something we should be looking at.
@mikeal wrote:
One thing I'm surprised I didn't see pointed out already was that when http2 was implemented by @jasnell he created an API and an implementation that specifically took advantage of being in core that out-perform anything possible in userland. Why can't the same be done for WebSockets?
Earlier in this thread, I did bring up the http2 module as an example of something that to my knowledge couldn't have been done as performant outside of core. I asked if the same was true for WS. I didn't see any answer to this, which leads me to believe that this isn't the case (sorry if I missed it).
Thus far this has been a very successful pattern.
"Successful" is subjective. It worked out okay for n-api (the C API) because we kept making breaking changes until long after the initial release. We could because there were few users.
That won't fly for a JS module. People start writing new code for those right from the start and that limits what we can change without upheaval.
A safe approach is to start out as a module under github.com/nodejs with a roadmap for migrating into core. That gives users time to try it out and provide feedback, while setting the right expectations.
And when I say 'users' I mean real users. With http2 and n-api virtually no one but the people working on it used it or even knew it was in the works until it was released.
edit: for WS there's one good argument for working in core from the get go: tight cluster integration.
And when I say 'users' I mean real users. With http2 and n-api virtually no one but the people working on it used it or even knew it was in the works until it was released.
This is entirely incorrect.
Even so, we seem to be in agreement that starting work within a separate repo is the right approach.
@MylesBorins ... I can create the repo under the nodejs github repo if you'd like, or I can leave it to you. The folks who are most interested in moving this forward can decide on the best work mode for them -- including whether that repo is a fork off core master or implemented as a separate module at first. Once some concrete progress is made there, let's revisit the question about whether it should land in core. I have created the @nodejs/websockets team and added you (@MylesBorins) as a maintainer.
Strong riposte, James. I suspect you get defensive because I brought up http2 but I'm merely using that as an example of where we (note the 'we') could have done better. Let's learn from our mistakes.
Core has more supporting infrastructure for new code to piggyback on but there is little that you can't also do from a native module.
One thing I would like to point out about native modules is that they have a significantly worse user experience for end-users. Users have to provide a compilation environment in their deployment environments; or trust a binary blob – which typically is not available for all platforms. Even if a module could be built to be just as efficient as a native module, it still wouldn't have the same first class user experience.
If it is deemed that protocols like http2 and WebSockets are central to The Web, then we should not relegate them to a less than ideal user experience.
@watson I don't know, I think a pure JS implementation that resorts to low level stuff for computational intensive operations will not be much better than a userland implementation that does the same thing. My main reason for having WebSocket in core is not performance which is always good to have but to improve ecosystem interoperability.
One thing I would like to point out about native modules is that they have a significantly worse user experience for end-users.
I agree. I advocate them as a stepping stone to built-in support, not as the eternal status quo.
That said... stuff like websockets and http2 would make interesting webassembly case studies.
My opinion is that WebSocket should be in core. Node.js was designed and has thrived as a platform for writing network services.
If I were learning Node.js today, I'd expect that network protocols that are widely deployed, have formalized specifications and fit the purpose of the platform would be supported out of the box.
I've expressed similar sentiments over the last couple years with regards HTTP/2[1], so I'm thankful @jasnell and others have done such an amazing work there.
I think a websocket server and client can be specially beneficial if:
- we can get demonstrably higher performance than userland implementations that don't build native addons
- we can expose primitives that could aid userland modules, like a reusable parser! Userland would get even better, fostering experimentation, like transporting the websocket protocol over non-HTTP channels
All in all, I'm very positive on this. The first version of socket.io had to be distributed with a .patch file to hack Node.js core to make WebSocket (Upgrade in general) work properly. Node.js is a great platform for experimenting and prototyping new ideas like that, and having solid building blocks in place from the start is a huge win.
[1] Specially after wrangling with the numerous bugs in userland implementations. These protocols are hard to get right!
Given the wide adoption of the client spec in the last two versions of nearly every major browser necessitates the adoption of a per-spec implementation in core. The performance benefits alone will make us rich beyond the dreams of avarice. But please for the love of all that is holy, stick to the spec and avoid anything, literally anything that diverges from the spec.
My opinion is that WebSocket should be in core as well, and that uws has been a game changer for many developers because it brought high performance: think about serving hundreds of thousands simultaneous clients with node+uws on a single cheap server. I would add on top of what @mikeal said, that my vision of Node.js is that it will die and be replaced by browsers in a foreseeable future. It's not browser without DOM it's cutting-edge browser with optional optimizations for servers.
Agree with @rauchg - WS usage is definitely on the rise which imo coincides with the push to not pull shift in delivery ( WS & Socket.io alone are pulled 20 million times a month ) & as @shellscape mentioned, the browser adoption is wide.
An on spec native implementation can only help further adoption & performance while giving user land a single way of implementing WS easily. All of these things would be extremely beneficial to NodeJS consumers particularly since as @3rd-Eden said, we really can't push the performance much further without WS becoming part of Node.
As @eugeneo & @3rd-Eden already pointed out, Node technically already as a degree of WS support, this could be expanded upon to bring this feature home.
I can't believe how much people are against Web Socket implementation in node, and even not happy about http2? What the hell guys? Node was supposed to be cutting edge, now years after first WS implementations, Node still don't have it, and please don't tell me to use any of the ready made ws socket frameworks. I hate them. I used ws module way back and I was happy with it. What about http2? This was long awaited upgrade, something that helps PWA become first citizen on mobile. I don't get it, every one of those spec is finalized, really a straight forward implementation in the lower level of the node code on C++.
@talamaska What makes you think you'll like the built-in websockets module better?
Note that I'm personally (mildly) in favor but the argument against adding it is that design mistakes in core modules cannot be fixed easily without breaking large swaths of third-party code.
Third-party modules don't have that problem: fix flaw, bump major, move on.
As the author of one of the earliest websocket modules (which I've since decided shouldn't be used in favour of ws, websocket, faye, etc), I would say that we've already had to make special changes to core's http module in order to support websockets: now that they are a formal specification, I see no reason that they shouldn't be entirely in core.
I agree with @3rd-Eden and @rauchg, particularly with exposing some lower level primitives that could be used to build custom websocket-based protocols. I wouldn't argue for all protocols to be build into Node.js, but web-native protocols make sense: they fit with how most people use node.js, they're expected.
I for one fully support the idea of making Websockets part of node.js core (though, let's skip the Global)
Aside: On http2, whilst I've not followed fully, it sounds like it could've benefited from being non-core for a little longer, but that's an entirely separate discussion.
Cross referencing bugs here: introducing websockets into the core could potentially help with issues like https://github.com/socketio/socket.io/issues/3212 in the long run, where people are relying on binary extensions to improve websocket speed - which is evidently not a good idea.
In the long run aren't users going to prefer http2 streaming capabilities over websockets?
Huh? I haven't read anything to suggest that http2 will supersede websockets. http2's streaming is bidirectional but not symmetric - only the client can initiate requests. Unless something changed recently, server side push doesn't bubble responses up to JS code. Also (afaik) just like http, http2 doesn't make any guarantees about preserving the order of client->server messages.
You could implement your own message-oriented streaming protocol on top of http2 using POST messages for C->S and server-sent events for S->C. But you will have to implement your own message ordering code. And you'll have load balancer problems. Websockets are sticky-by-default. That is to say, if you have a cluster of frontend servers with a load balancer, a websocket connection will stay connected to a single frontend machine for its lifetime. Configuring load balancers to replicate that behaviour on top of normal http requests is a black art. Corner me in a bar sometime and I'll tell you all about the nightmares we had getting sticky sessions working correctly through ELB a few years ago. (I understand some libraries try to silently migrate sessions. This introduces its own concurrency problems, and it doesn't work for all use cases.)
So, no. In the long run I hope websockets are reimplemented on top of http2. Although to be honest most of http2's benefits won't make much difference for websockets anyway. Over http2 the initial WS connection & handshake will be faster (since it can reuse the TCP connection it loaded the page on), but once its established it won't really matter. When websockets are implemented in http2, it will still make sense to have websocket code inside nodejs.
[@theturtle32 said:] I don't feel it's anywhere near as widely used or fundamental as HTTP is, and it would end up just being more for the core team to have to maintain.
As others have pointed out, adoption is actually high.
[@josephg said:] will the entire community benefit from it being part of the core? (no - websockets are used widely but still only in a minority of projects)
This is a false negative; it may be a chicken and egg scenario where adoption seems lower (it's not) because the tooling is not easy to use and natively available. I personally believe this to be true. Adoption will be much higher with the right low-level API.
[@josephg said:] Personally I think there's a middle-ground that I'd like even better: Have an official list of recommended solid, default modules for specific tasks in nodejs. These could be decided on however we like. The official documentation should list these modules.
Off topic, but it could easily solve the "should we" paradigm. Too much to say on that here. Can it be picked up elsewhere?
[@mikeal said:] Node.js adopting new core protocols of the Web is perfectly in-line with its original vision and only a dogmatic originalism could argue otherwise. There may be perfectly good technical reasons not to include Web Sockets but the argument that it is somehow out of scope doesn't match the history or vision the project has had since day one.
EXACTLY this.
[@rauchg said:] My opinion is that WebSocket should be in core. Node.js was designed and has thrived as a platform for writing network services.
As someone who has had to implement WS on a few different projects, I am certain of two things: usage will increase dramatically over the coming years by particular verticals (storytelling engineers, for one). As well, WS are never easy to use. As @mikeal said, one of the things Node.js has had going for it from the beginning was the sense that it was built to be interoperable with the browser. Java, Ruby, Python, Go, and all the other low-level languages have never been easy to work with in terms of browser interoperability, and one of the explicit reasons is the difficulty in interacting with basic protocols such as http. Userland has built up a nice ecosystem around WS, but the tooling and ease-of-use factor is still a hell-a-difficult.
Treat WS as the first-class citizen it deserves to be treated. This should have been done 5 years ago.
Treat WS as the first-class citizen it deserves to be treated. This should have been done 5 years ago.
Especially with the growing popularity of WAMP-based apps.
+1 on this.
From the about page
About Node.js® As an asynchronous event driven JavaScript runtime, Node is designed to build scalable network applications.
Node should definitely have a WebSocket support and Server-sent Events, TPC, UDP, HTTP, HTTP2.
A lot of IT-student in germany have to write websocket-applications. From this standpoint alone, it should be native. nodejs feels incomplete, if it isnt. You just use it natively in a browser, but in node.js you first have to find out, its not supported, then you have to decide which userland implementation is ok and future proof? At this point, i would be annoyed. Because you will feel like nodejs is not the wonderland of server-communication you thought. The next thing as student is, you have to deal with a callback hell. How many give up at this point? Let alone, that javascript wasnt very loved in the past, but is developing (ES6) very fast and has the big advantage of learning only one language in front- and backend. If that wouldnt be the case, nodejs would have died long ago - but thats just my impression.
Treat WS as the first-class citizen it deserves to be treated. This should have been done 5 years ago.
Definitely.
I have strong opposition to this. Node.js is used for far more than web applications. Adding bloat to the core hurts these other types of applications and their portability, while providing no significant benefit to those who want it. Keep Node.js light and keep WebSockets in solid modules like ws.
@bradisbell you have a valid point -- I just think WebSockets can be considered a core protocol of the web, very much like http2.
@bradisbell this is probably the most valid point I've heard on this.
I would favor, alternately, some sort of tree-shaking methodology native to Node in that case. I.e., only import what's actually imported. Obviously waaaaaay beyond the scope of this ticket (how would such a thing even be possible), but that would be my 2 cents. Best of both worlds, actually. Significantly lighten Node core, but still have core/official requires available on demand.
What is the actual decision making process for a big change like this?
It'll be controversial no matter what the decision is. But it would be nice to have a clear official resolution on which way node will move forward with this. Can we bump this to the TC or something?
there's nothing stopping someone from making a pr. if that pr was blocked for a non-technical reason (like "ws shouldn't be in core") it could be elevated to the TSC
@lpinca Mind create a PR ?
Just found go has websocket too https://godoc.org/golang.org/x/net/websocket.
In js ecosystem，new api System like Graphql subscription rely on this: https://github.com/apollographql/apollo-server/blob/678714293337be19163e7ae0f973c6d873cf3656/packages/apollo-server-core/package.json#L46.
FYI everyone: There's a new spec WebSocketStream that is intended to supersede WebSocket in the same way that fetch superseded xhr. The new spec supports backpressure.
If the decision is to add ws to Node.js, then perhaps we should skip the current API and just implement this new one, since backpressure is quite important. https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/X7rWpAkMCyg/j6K7mEEwAgAJ
(We should also wait until this API stabilizes and there is buy-in from other browsers besides Chrome)
