µWebSockets

[kevinwei00]

Haven't properly evaluated this library yet, but was wondering if you have taken a look at https://github.com/uNetworking/uWebSockets.js ?

[enisdenjo]

Hey hey, thanks for opening this issue!

Honestly, I've never heard of µWebSockets 😅. It looks great in terms of performance, but, following the brief glance I had - thats where the features end haha.

I'd love to know more, can you elaborate a bit on the pros and cons of this library? Why, except for the performance boost, do you choose µWebSockets over ws?

Furthermore, it would be possible for the server library to take in a custom WebSocket implementation. Something like the client does. The only requirement for the implementation would be having the same interface as ws.

[enisdenjo]

I stumbled across a Medium article called: "Beware of uWebsockets.js!". It pushed very important problems about the library, mainly the author. TBH, I don't like what I've read...

• (about the author) ... Insults and the like are the norm in his way of treating people, and ultimately he will ban you or delete complete issues if they are exposing any flaws in his library or how he behaves.

  We might not know what we must know! Deleting issues because of disagreements or flaws which you dont want to patch is hella scary. (There is even a link to an issue in the article which got deleted...)

• it must be pointed out that this is not installing the package from the NPM registry, but from the private github repository of the package’s author.

  The main implications of this is that, 1) the repository can be deleted at any time (not very unlikely considering past events), and 2) the tag pointing to a version can be changed to point to a different commit (not very unlikely either since this was the reason for the original dispute with uWS).

  graphql-ws (and its Protocol) treats security as the first-class citizen, so this is a deal breaker for me. I will not promote unsafe libraries with this repo. Package immutability is THE thing that keeps us, JavaScript devs, safe.

• The author provides precompiled binaries, which, while being convenient for some users and platforms has the added risk of not knowing if the binaries really correspond to the source code or a specific version of the source code.

  No additional comment necessary.

Performance or Security? I'll choose security any time of the day.

P.S. I still wouldn't mind allowing a custom WebSocket implementation for the server (all implied risks with the custom implementation lay on the user then). Of course, keeping the requirement of it being a ws server compatible interface.

[kevinwei00]

@enisdenjo Thanks for the detailed response! And one that other devs must know about as well. I was really just scanning its performance claims 😅 .

[enisdenjo]

Of course! Thank YOU though, with this issue we have learned something new about the world. 😄

[ivarsg]

@enisdenjo, @kevinwei00 and other devs, I think it is worth to read also Alex Hultman's (author of µWebSockets) thoughts on the above mentioned Manuel Astudillo's article. There are always two sides of the medal, two truths of the opposite opinions :)

[enisdenjo]

Awesome! Thanks for sharing the post, there sure are two sides of every story. 😅

[evenfrost]

Honestly speaking, I think this response is childish and insulting itself, and only proves Manuel's assumptions on the library author.

[enisdenjo]

Manuel had good points, Alex had too - but this is just grownups being childish.

Alex literally gained nothing by following his moral compass and ditching the forever growing, community trusted, npm; because "he finds their Terms of Service repulsive, from a purely legal standpoint". He now has to (and will probably have to forever) hold a link to "A note on speculations, lies & allegations" in the main readme of the lib. And even with this, Google being Google - I managed to stumble across Manuel's article first. xD

Not only this, but to feel safe (since you cant just rely on Git tags, nor cant you just rely on humans) - you have to fork, make sure you have the tools to build the lib, build it, package it, deploy it manually to all your services; instead of just doing yarn add uws. He basically twisted all our hands; I, personally, would end up avoiding the lib simply because of the hassle, whatever the performance gains are...

Furthermore, he DID delete that issue. Whatever the reason, he did it. We now can only trust his word that it was actually what he said it was.

[enisdenjo]

:tada: This issue has been resolved in version 2.0.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[maxpain]

I've done integration here

[enisdenjo]

:tada: This issue has been resolved in version 4.4.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[enisdenjo]

@kevinwei00 good news, the integration has landed with v4.4.0. Would be awesome if you could try it out, given free time. 😄