Hacker News Reader

Comment by keithwhor | Hacker News Reader

As a thought exercise;

- What happens if the client’s internet connection temporarily drops? How do you handle client reconnections and retries?

- What if the remote server crashes through no fault of your own (AWS server rack catches fire)? How do you ensure a consistent reconnection that preserves application state?

These are just two questions that HTTP + Browsers solved decades ago.

Websockets are this cool technology that seems powerful and exciting until you realize the “boring old stateless World Wide Web” was built over decades of iteration using stateful sockets as the backbone, did most of the work for you in tandem with browsers, and is ultimately a lot cooler and more sophisticated than a lot of us give it credit for.

View on HN

Here's another one. How do you deploy a new version of your service?

Imagine a few customers open up your site and leave for lunch. Or maybe just a random crawler or bot sitting watching for some piece of information they are scraping.

These sorts of issues can be challenging with stateless connections. I can only imagine how daunting they are with persistent connections.

it is called hot-reload.

The nice thing about persistent connections is that you know when they’ve been closed so you could literally signal that the connection was going down for a deployment and close everyone’s connection. Clients can retry the connection until it comes back up or use another service to monitor the status.

Games basically do this routinely.

But you can do that sort of communication already with existing websockets, without trying to add the complexity of pushing all your regular traffic over that link.

I bet your ass that at least half of the developers reading HN don’t have caching of JS fully figured out such that when the JS changes server-side and immediately needs reloading on the client side that it does then and there instead of on the next request, the next page refresh, or never because they’ve f’d it up.

With server-fed, event-driven pages, you could potentially force refresh.

my solution to version changes in a rest api is to sent a version header with every response, the app checks it and if it does not match reloads the page, thus loading the new js.

I would not accept your wager. That being said if this was a “really big problem” I’d bet you that most developers on HN would have an idea how to address it.

I leave the browser waiting for a fetch-response from the server. The server responds only later when the page that is open in the browser was updated on server. Seems to work much of the time, but sometimes it seems Chrome closes the connection after a timeout and shows a network error in the dev-tools. FireFox not.

I assume web-sockets could make it work more robustly.

Well, this problem exists at the moment. To be honest sockets is one approach to fix it.

What happens if a webpage is loaded over plain old HTTP and then over lunch a breaking change is deployed. The page the user loaded before lunch is now no longer compatible.

Compatible with what?

It’s stateless. If the api changes from underneath and you’re polling or something, then just show an error, have the user refresh the page and move on. Or use any of the various api version mechanisms for backward compatibility. It’s not an easy problem but it’s a fairly well understood and managed one. Solving this kind of known problem isn’t, to me, a very compelling case for HTML over sockets.

You restore the state like you would on a SPA or regular server side rendered page.

A crash or someone hitting refresh on his browser is not that different in this respect.

I'm astonished that people are asking these questions while there's obvious answers like this.

WSs aren't a magic wand, they just allow you to do more with the same.

I don't see what's astonishing about it and I'm scratching my head asking the same question. If the answer is that you handle disconnections and reconnections the same way that the HTTP protocol does it, then what's the purpose of HTML over web sockets?

You basically end up with a half-assed, buggy, and potentially insecure reimplementation of HTTP running over web sockets running over HTTP at that point.

Are you going to do session management and identification by issuing a unique identifier as well? Is that unique identifier going to be valid in perpetuity or have a an expiry date? Is it going to be valid and secure across all sub-domains or will it be prone to cross site scripting attacks?

> then what's the purpose of HTML over web sockets?

Because you can do things stateless HTML alone cannot do.

No one is trying to re-implement HTTP, or even remove it from the equation.

What people are trying to reimplement (or rather, replace) is the HTML + JSON:API + React + Redux mess. Websockets is a means to that end.

Hm... great intentions, but you don’t seem to have actually answered any of the questions from the parent comment.

Unfortunately, great intentions alone won’t make this work; someone has to actually answer the hard questions about how it’s going to work too.

All the answers I’ve seen so far trying to answer them have been vague hand waving...

That doesn’t leave me with much confidence.

You are welcome to actually look at the code for any of these solutions.

Here is the documentation for Phoenix channel authentication (what Phoenix Live View is built upon): https://hexdocs.pm/phoenix/channels.html#using-token-authent...

Additionally, here is some documentation on the security considerations specific to Live View: https://hexdocs.pm/phoenix_live_view/security-model.html

Searching can probably find you more information.

>Unfortunately, great intentions alone won’t make this work; someone has to actually answer the hard questions about how it’s going to work too.

People did better than that, they already built applications with this model.

>I don't see what's astonishing about it and I'm scratching my head asking the same question. If the answer is that you handle disconnections and reconnections the same way that the HTTP protocol does it, then what's the purpose of HTML over web sockets?

The purpose is in the things explained well in TFA: single source of truth, no replicated state, simpler development, and so on...

Who said the purpose would/had to be in handing "the server caught fire" scenarios?

The purpose is to render your page the "old way" but having the dom updated like an SPA.

It works for certain things and not for others. So, it's not "the future of web software" like the title says, it's one additional possibility for when it makes sense.

What you mean by sockets in "exciting until you realize the “boring old stateless World Wide Web” was built over decades of iteration using stateful sockets as the backbone".

I should probably already know this.

HTTP is a stateless protocol built on top of TCP network sockets [0] intended to standardize transfer of hypertext. It's the backbone of the WWW.

HTTP is quite literally "hypertext over sockets" so "HTML over websockets" is functionally equivalent... with a layer of abstraction added on top. If you build web software by sending HTML over websockets you're just reinventing what already exists; it's probably why it's never taken off. I think most developers realize within ~weeks to months of working on a "websocket-everything" framework that they're doing more work, not less.

[0] https://en.wikipedia.org/wiki/Network_socket

>- What if the remote server crashes through no fault of your own (AWS server rack catches fire)? How do you ensure a consistent reconnection that preserves application state?

Why would you? Nobody seems to ensure that with regular SPAs anyway...

Reply on news.ycombinator.com