Woe be onto you for using a WebSocket

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • Scout APM - Less time debugging, more time building
  • jsynchronous

    Jsynchronous.js - Data synchronization for games and real-time web apps.

    For the very reasons listed in the article, I built:

    https://github.com/siriusastrebe/jsynchronous

    a library for keeping a javascript variables synchronized between Node.js servers and clients.

    Websockets work great for message passing but it struggles with data structures more complicated than what JSON can represent. Jsynchronous syncs any javascript object or array with arbitrarily deep nesting and full support for circular data structures.

    If a computer goes to sleep, or disconnects, websocket connections (and their underlying TCP connections) get reset so you lose any data sent while a computer is unavailable. Jsynchronous will re-send any data clients are missing.

    There's also a history mode that lets you rewind to past states.

  • rsocket-java

    Java implementation of RSocket

    A few years ago I was more inclined to use WebSockets. They're undeniably cool. But as implemented in browsers (thanks to the asynchronous nature of JavaScript) they offer no mechanism for backpressure, and it's pretty trivial to freeze both Chrome and Firefox sending in a loop if you have a fast upload connection.

    I designed a small protocol[0] to solve this (and a few other handy features) which we use at work[1]. A more robust option to solve similar problems is RSocket[3].

    More recently I've been working on a reverse proxy[2], and realized how much of a special case WebSockets is to implement. Maybe I'm just lazy and don't want to implement WS in boringproxy, but these days I advocate using plain HTTP whenever you can get away with it. Server Sent Events on HTTP/1.1 is hamstrung by the browser connection limit, but HTTP/2 solves this, and HTTP/3 solves HTTP/2's head of line blocking problems.

    Also, as mentioned in the article, I try to prefer polling. This was discussed recently on HN[4].

    [0]: https://github.com/omnistreams

    [1]: https://iobio.io/2019/06/12/introducing-fibridge/

    [2]: https://boringproxy.io/

    [3]: https://rsocket.io/

    [4]: https://news.ycombinator.com/item?id=27823109

  • Appwrite

    Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!

  • zotonic

    Zotonic - The Erlang Web Framework & CMS

    We have build a nice support library for it. HTTPS://github.com/cotonic/cotonic. It helps that our backend is Erlang. https://github.com/zotonic/zotonic.

  • Centrifugo

    Scalable real-time messaging server in a language-agnostic way. Set up once and forever.

    Every time I read criticism of WebSockets it reminds me about WebSuckets (https://speakerdeck.com/3rdeden/websuckets) presentation :)

    I am the author of Centrifugo server (https://github.com/centrifugal/centrifugo) - where the main protocol is WebSocket. Agree with many points in post – and if there is a chance to build sth without replacing stateless HTTP to persistent WebSocket (or EventSource, HTTP-streaming, raw TCP etc) – then definitely better to go without persistent connections.

    But there are many tasks where WebSockets simply shine – by providing a better UX, providing a more interactive content, instant information/feedback. This is important to keep - even if underlying stack is complicated enough. Not every system need to scale to many machines (ex. multiplayer games with limited number of players), corporate apps not really struggle from massive reconnect scenarios, and so on. So WebSockets are definitely fine for certain scenarios IMO.

    I described some problems with WebSockets Centrifugo solves in this blog post - https://centrifugal.dev/blog/2020/11/12/scaling-websocket. I don't want to say there are no problems, I want to say that WebSockets are fine in general and we can do some things to deal with things mentioned in the OP's post.

  • FluidFramework

    Library for building distributed, real-time collaborative web applications

    Full disclosure I work at MSFT and on the fluid framework.

    If you are interested in this you may also be interested in the fluid framework, https://github.com/microsoft/FluidFramework

    We use websockets and solve a lot of the state management problem called out here by keeping very little state on the server itself. The primary thing on server is a monotonically increasing integer we use to stamp messages, this gives us total order broadcast which we then build upon: https://en.m.wikipedia.org/wiki/Atomic_broadcast

    Here are some code pointers if you want to take a look:

    The map package is a decent place to look for how we leverage total order broadcast to keep clients in sync in our distributed data structures:

  • Meteor JS

    Meteor, the JavaScript App Platform

  • Docusaurus

    Easy to maintain open source documentation websites.

  • SonarLint

    Deliver Cleaner and Safer Code - Right in Your IDE of Choice!. SonarLint is a free and open source IDE extension that identifies and catches bugs and vulnerabilities as you code, directly in the IDE. Install from your favorite IDE marketplace today.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts