Hacker News Reader

Comment by pmontra | Hacker News Reader

> channel.on('update:todo' ...

> channel.push('delete:todo' ...

> Have a CRUD interface over websocket

REST over websockets. What's the advantage over HTTP? I know websockets allow for pushing data to clients, but this is pull so apparently there should be no advantage, only more code to write.

Edit: maybe you're sharing updates among all the users connected to the server. Still, for sending requests HTTP is enough. Any performance advantage by using websockets?

View on HN

This is interesting when you want near realtime performances, as you don't have all the culprint of a http request : you basically just send a few octets (a json document, or even just a simple value), and you don't have to build a request and negotiate a connection.

This is not something obvious because we have helpers to make http requests, but there are many things going on while issuing a http request (building headers, encoding body, etc) [1]. A socket (be it a websocket or a classic socket) has this advantage that all the negotiating part is already done and you just have to send the message, in whatever format you want. Decoding the request on server side is way easier too.

[1] https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Me...

HTTP/2 multiplexes requests over one socket connection, so it should solve most of problems you state.

Except browsers do not allow Push on http/2 so far

clients don't have any api to get at data pushed by http/2 - it is not a websocket replacement and can't be used for the same things. http/2 will be used to multiplex static resources to clients - not application data

> This is interesting when you want near realtime performances, as you don't have all the culprint of a http request

Excellent. How about raw TCP then?

Please anyone correct me if I'm wrong, but there's no raw socket interface in browsers, as far as I know. Websockets are the closest thing, while still ensuring usual client side security (like preventing cross site request).

This is correct. Its not far off from a normal http request, the performance savings is primarily in the TCP/SSL handshaking that goes on.

I've been out of front-line web development for a while. Are Websockets supported widely enough that a developer can reasonably assume they are available and not have to worry about workarounds such as comet/long polling?

Yes, I would say they're an expected browser feature these days, with over 94% global browser availability [0] (basically anything >= IE10).

The cool thing about Phoenix specifically is that they provide a JS client to integrate with a Phoenix Channels [1] backend that will automatically fail-over to long-polling if window.WebSocket is not available [2]. These Phoenix Channels are set up to be transport agnostic, so you don't have to write any special backend or client code to handle one way or the other, it "just works" for the most part.

[0] https://caniuse.com/#search=Websockets

[1] https://hexdocs.pm/phoenix/channels.html

[2] https://github.com/phoenixframework/phoenix/blob/master/asse...

Almost, depending on who you ask.

But Phoenix contains these workarounds and it works great. So with Phoenix Channels you can really just act like It Just Works.

(phoenix.js is one of the best parts of the library IMHO - its design beats eg socket.io dead out of the water)

The last time I did anything with Websockets was about 5 years ago and they were relatively well supported by browsers even then. I used socket.io because it automatically falls back to long polling when native Websockets are not supported. I am guessing if you needed 100% support this may still be a good option.

[EDIT] I see another commenter in this thread mentions phoenix.js beating socket.io. Thanks, I will have to look into this!

A bit tangential but one of the things I've enjoyed about using GraphQL lately is how easily it can be used over websockets. All the API work you do to support HTTP can be immediately used over websockets because the it never required a specific transport to begin with.

Phoenix channels make it super easy to setup and use websockets, but you're sort of on your own as far as figuring out how to work REST conventions into it since all the tooling that exists for REST generally assumes and requires HTTP.

It's great to be able to write the code for the API once and support it across a broad variety of transports.

Do you use Absinthe?

Pretty sure he wrote absinthe.

Hey! Yup I'm actually one of the co-authors of Absinthe. Got any questions?

That's HN for you. I should have realized after I looked over issue 156 this morning. No questions, I was just curious about experiences with it and wanted to see if that's what you were referring to. Thanks for releasing it, I can't wait to try it out.

Websockets provide full-duplex communication channels over a single TCP connection without the overhead of a http request/response cycle. For realtime applications such as the one described in this post or for a chat application, there is a significant performance benefit over plain http. Maintaining open websocket connections is also very cheap in terms of memory used as well as cpu resources.

Apart from the obvious push capabilities, yes, websocket has much less overhead and is faster than HTTPS.

Once the connection is established, you can send requests starting at 1 byte size, whereas HTTP needs the full headers on every request.

HTTPS also has a lot of handshake overhead, where you need 2-3 round trips per request instead of a single one with websocket. This can make a world of difference in a 150+ ping situation, where HTTP feels sluggish and websocket feels instant.

actually, both HTTPS and WebSocket over TLS (wss://) require a TLS handshake, so it's not like you're constantly doing that after you've loaded the page, but HTTP request/response header sizes could def be a concern.

No, there is not a handshake for every message you send over websocket. You do the handshake only when you open the connection.

HTTP keepalive should get you much of the same benefit, though? The major improvement comes from fewer headers sent over websockets?

SSL Session Reuse needs to be configured as well, otherwise every single request will have to perform a new handshake, independently of keepalive.

In practice I've always observed HTTPS requests to take at least twice as long compared to a back and forth through a websocket, even when SSR and keepalive are enabled. I don't know if having both theorically allows for single-roundtrip HTTPS requests.

Performance advantage is pushing messages from the server instead of having the client poll.

The tradeoff is dealing with half-open TCP connections (need an in-process ping to ensure the connection is still alive) and designing the app for state recovery in the case of missed messages.

Reply on news.ycombinator.com