4 ms·

When I was working in a queue feature (for example to buy tailor swift ticket), and was proud of my complicated real-time solution using websockets and CRDTs...

When I was working in a queue feature (for example to buy tailor swift ticket), and was proud of my complicated real-time solution using websockets and CRDTs...then a more experienced guy came, rearchitected in a much simpler way using just the DB with long-polling, not real real-time (but who cares), and it ended up simpler to deal with network splits or crashes. Learned the hard way you can never rely on the network if you require consistency, and it's also often simpler code-wise.

jpeggtulsa 2y ago
One of the earliest projects I took over from a higher level developer was an auction website back around 1998. The site worked like eBay in as far as you could put a maximum bid, and it would automatically bid higher than the last bid up to that point. The problem was, it was all dependent on users being on that page so that the auto-reload http header would fire again and refresh the page. If nobody was on the site watching the auction, no automatic bids would happen and nobody would be declared the winner.
- bombcar 2y ago
  The number of "web cron" things in tools like Wordpress and friends is insane; I've been bit a number of times by this - if nobody hit the site for a day, none of the crons would fire. Big website, no problem. Small internet site, big problem. (Yes, for some cron + wget/curl was whipped out)
dehrmann 2y ago
People often forget that you have to poll to handle lost network connections, IP changes, etc., so there isn't always a real-world win to web sockets.
- mdavid626 2y ago
  How about reconnecting the websocket from the client?
  - dehrmann 2y ago
    Sounds like polling. On an inactive connection, whatever it is, you have to always be polling to see if the connection is still alive.
    - mdavid626 2y ago
      What do you mean? The client knows when the websocket connection goes down and just reconnects. How is this polling?
      - malkosta 2y ago
        Because it always needs some sort of keep alive, which is many times hidden inside the client/web framework
        mdavid626 2y ago
        But isn't a keep alive bit better than a "full" polling?

jpeggtulsa 2y ago

One of the earliest projects I took over from a higher level developer was an auction website back around 1998. The site worked like eBay in as far as you could put a maximum bid, and it would automatically bid higher than the last bid up to that point. The problem was, it was all dependent on users being on that page so that the auto-reload http header would fire again and refresh the page. If nobody was on the site watching the auction, no automatic bids would happen and nobody would be declared the winner.

bombcar 2y ago
The number of "web cron" things in tools like Wordpress and friends is insane; I've been bit a number of times by this - if nobody hit the site for a day, none of the crons would fire. Big website, no problem. Small internet site, big problem. (Yes, for some cron + wget/curl was whipped out)

dehrmann 2y ago

People often forget that you have to poll to handle lost network connections, IP changes, etc., so there isn't always a real-world win to web sockets.

mdavid626 2y ago
How about reconnecting the websocket from the client?
- dehrmann 2y ago
  Sounds like polling. On an inactive connection, whatever it is, you have to always be polling to see if the connection is still alive.
  - mdavid626 2y ago
    What do you mean? The client knows when the websocket connection goes down and just reconnects. How is this polling?
    - malkosta 2y ago
      Because it always needs some sort of keep alive, which is many times hidden inside the client/web framework
      - mdavid626 2y ago
        But isn't a keep alive bit better than a "full" polling?