Show HN: WebSocket-first development

Thanks for linking that lib btw

If state matters, shouldn't we consider using Server Sent Events (SSE)?

If the site is hardcore SPA, and has a single "mysite.com/" URL, then you're right that state is only represented in terms of websocket events. However, if we have URLs like "mysite.com/users/alice" or "mysite.com/conversations/alice-bob-23", those resources will stay current, so that reloading them will reflect websocket events that took place since the last load. If the events are coming really quickly, there might be a race condition, but that's easy enough to solve by including a "last event" token in the page itself, that can be included in the websocket URL.

Author here...Well, I started down the websockets path because of how awesome I found crystal to be. I wasn't intending to do this a few months ago, it just sort of took on a life of its own :)

The framework as I've written takes state into account; in fact it was/is a design goal. There are three types of server objects currently - WebObject, StaticBuffer and DynamicBuffer. A WebObject stays instantiated on the server even when no users on viewing it (at some point it will be garbage collected).

At any time, rendering that object will produce the exact representation as seen by someone who has viewed it and been updated with websockets. In fact, the card game is a good example of this. Start a game, draw a few cards, start another game, and then go back to the first. It'll be in the same state you left it in, complete with the events that occurred while you were gone. This was one of the top goals.

DynamicObjects are just arrays of WebObjects in a configurable buffer - think of a list of sports scores, where each item handles its own update.

StaticObjects are an array of simple strings of html (think of tail to view a log file).

That's a good and important question. I think the solution depends on your application requirements. If all you need to do is get the updated current state in the browser then it's enough if the browser resubscribes after each connect. It would then get pushed the new current state and can display it. If you are not only interested in a current state but all state transitions (or events that describe them) then it gets harder, since you would need to store all the events somewhere on server side, and only remove them once a browser has acknowledged that they have been consumed. In such a model the difference to fetching the events via HTTP would probably not be too big.

At work, we dispatch messages to clients using websockets (on a pretty massive scale).

>How do you deal with the potential that a browser goes offline and misses messages?

It depends on how long the browser goes offline for is it a transient disconnect (< 2 minutes) or is it an extended period of being offline. We deal with those two specific cases differently. In the first case, we use a sequence based system wherein each message contains an incremented counter. The server also holds a buffer of the last N messages sent to the client (N calculated by the expected velocity of messages being sent to the client). If the client disconnects, the server will keep that buffer alive for a few minutes (accumulating new messages in the buffer as well). The client can then reconnect, telling the server what the sequence number of the last message it received was. The server can then replay missed messages. In the case of an extended disconnect - we'd treat this as a fresh connection, where we do a full re-sync of state. The client then relies on the real-time event stream to keep its state updated.

>Do you have a way to cluster websocket servers so that events are propagated to all clients?

Yes. Our cluster is built in Erlang/Elixir and consists of several components for fanning out messages. For example, we're able to fan-out 1 message to ~25,000 clients in <0.1ms. (The use-case here is in a massive chat-room - we're able to fan out a message to all the connected users quickly).

I'm working on a browser game, that does all communication to the game server through WebSockets.

Here I have the clients ping the server every 2 seconds, and if I haven't received a message with in 10 seconds (including other messages than ping) I consider the client dead.

Each socket is assigned to an individual player, and if that player opens a second connections the old one dies.

To be honest - In regards to the missed messages and order of events, I just cross my fingers and hope TCP does that for me.

In regards to the clustering, I have my map split up into sections, so most of the messages that needs to be send, are only to the people in that sector. So I rarely send a message to all players.

I'm still experimenting, so I'll probably still have a lot of edge cases that I'll have to cover. But for now it seem to work well.

I answered this on a different thread, but I've specifically designed things for this scenario. The framework has a class named WebObject. Once instantiated, it stays persisted on the server, and can take on additional subscribers.

At any time, "updates-applied" browser version of the current state of the object can be created with a call to the #content method.

So when a "updatable" occurrence occurs on the browser, you send an update method withe the changes. The changes are packaged up into messages that sent to each subscriber, where they modify the dom.

It's a bit of a reversal, probably, with how people use frameworks that dynamically change content. I make the assumption that the server's instance is the only keeper of object state. Changes made on clients either change object state or they don't; if they are not sure, they send an event back to the server which handles it.

A @WebObject can also have properties that are themselves WebObjects, and the current card game actually has three: ChatRoom, GameStats, and GameObserver.

This pushes the responsibility for rendering content directly where it belongs: on the object where the rendering occurred in the first place.

But it has the side benefit of keep object state, too. The CardGame doesn't have to worry about the state of the ChatRoom (though it can observer and send events to and from it).

The bottom line is that there are only two ways the browser rendering could be wrong: 1) Some packets were missed, or 2) The developer didn't send the correct events, or sent them in the wrong sequence.

The first case could be solved by creating a delivery confirmation layer over the objects.

The second case is probably a little more dicey. The more data contained in a single updatable chunk, the harder it is determine when state changed. That's helped tremendously by the idea of nesting WebObjects (A Room has CardGames which have Players and Games, which have Decks and Cards....each of which take care of updating themselves)

> this isn't per-se a new paradigm

If you look how regular websites work, I think it is.

In my last project, people were kinda baffled, why the changes they made, didn't propagate to the other users instantly.

5 years ago everyone knew you had to refresh a page to see changes. Today everyone seems to expect these changes to be pushed to them.

It also was a fight to get this whole stuff working with React and Redux. So I think, if you want to build a good realtime site, you have to think about this stuff before choosing libraries, if you want to get good results.

For example, GraphQL has subscriptions that can be delivered via Websockets.

I think that realtime-first is correct. Websockets is just a protocol that support bidirectional communication. Plain old HTTP requests paired with Server Sent Events over H TTP/2 are technically bidirectional communication over the same connection too.

Google is also working on GRPC for the browser. Tomorrow it could be a completely different protocol, but it's all in the pursuit of making the app more realtime.

Yes, you are completely right. It should have been titled "Realtime-first development with Websockets".

If you're interested in Realtime-First development, Meteor has been doing it since 2013 and is very production-ready at this point: https://www.meteor.com/

Does anyone know why Edge would make that kind of decision? SSE has been supported forever.

Based on http://caniuse.com/#feat=eventsource only IE/Edge doesn't have it, and there are polyfills for those, e.g. https://github.com/Yaffle/EventSource/blob/master/README.md

Or there are more problems?

Want to use SSE for one small project soon (haven't used it before, and don't want Websockets as they're an overkill for a basic event stream), would appreciate any info about how things could go wrong.

For this sort of thing, albeit only with a .NET backend, I've always used SignalR to handle these browser/server OS incompatibilities. It'll negotiate a common protocol, whether that be WebSockets, SSE, or falling back to long-polling.

Speaking of web sockets and simplicity:

I never understood why web sockets aren't just a straight break out of HTTP(S) to a naked TCP or SSL socket. Why all the extra complexity? All it does is degrade performance and bloat software.

I hate the way protocols are designed by committee, virtually guaranteeing that everything has layers upon layers of cruft that have never actually been needed by anyone for anything but must be implemented because it's in the spec.

But isn't channels the Phoenix abstraction (middleware) for websockets/sockets per se?

What I mean is why not write a sockets Phoenix channels transports adapter to be used instead of the default one & continue using the existing codebase? :)

Short answer, I don't know. I don't know that they'll disappear, they are just so efficient.

That said, lattice is completely event-driven. The #on_event and #emit_event methods act as entry and exit points. As long as I can have string come and go between the server and client, HTTP2 would be fine.

This seems like a pretty good article covering it

https://www.infoq.com/articles/websocket-and-http2-coexist

Websockets won't disappear!

It's just the case that you can't upgrade from a HTTP connect/request to a websocket connection, since at that point the connection is already in HTTP/2 mode and both HTTP/2 and websockets need complete control over the TCP stream.

But: You can still make a HTTP/1 request to the server and upgrade to websockets. Both servers and clients will speak HTTP/1 in parallel to HTTP/2 for a loooong time - most likely forever.

I haven't explored that a lot, but my thought was that the amount of setup/teardown for polling goes away, so it's at least an order of magnitude (guessing) better.

I have written the framework to use a single socket connection for all updateable objects on the page.

It can. I have a demo deployed on Heroku for this app (https://github.com/JangoSteve/websockets-demo), and I've seen it handle maybe about 40 or 50 clients at a time on a single dyno before (and each client streaming a bunch of events), even though it's intentionally implemented in the simplest (i.e. inefficient) fashion possible. The request overhead for normal HTTP request/response goes away, since you only need the request headers and handshakes once at the beginning for a persistent connection.