I did a lot of websocket first development, since I ported various plain TCP based communication frameworks to websockets. You can do lots of cool stuff there, from plain request/response protocols that are faster than HTTP/1 to advanced stuff like publish/subscribe mechanisms and even protocols that keep the clients state automatically synchronized to the server side.

For advanced use-cases that's certainly a way to explore. For the average user I'm not sure whether I would recommend to go the route. You lose a lot of stuff that HTTP gives you out of the box, e.g. a request/response abstraction, dozens of frameworks and mechanisms for authorization, logging, etc. HTTP is also easily load-balanceable, while websockets are not. HTTP/2 in principal makes small request/response exchanges as fast as you could implement them with a custom websocket protocol, so there's no more gain. And SSE allow to push server updates in a form that still fits the HTTP model and frameworks pretty good. There are still lots of ways in which websockets can improve reactivity, but you have to invest a lot of engineering effort into it, which might not be worth it depending on the application.

This is cool, but I'm a bit confused. Websockets have been around for a long time now, and there are tons of popular libraries (like socket.io, but more importantly, you should check out the high performance https://github.com/uWebSockets/uWebSockets instead).

Is all this doing trying to encourage awareness that using websockets is good? If so, awesome. Else, what is it? Because it does not discuss how Websockets lose state on reload. Your game will be in a completely wrong state. Managing and maintaining state is the important thing (which is what https://github.com/amark/gun does, which is of course also "websockets-first"). When you reload your game, it should return/remain as it was, or else half your players are going to see a half-broken system!

For everyone here who seems to be working with websockets, how do you deal with the potential that a browser goes offline and misses messages? How do you reconcile changed offline state with more recent events on the server? An OT library?

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

I think websockets as you're using it is a stand-in for realtime-first development.

This territory is well explored -- services like firebase/parse are a testament to many usecases.

IMO, this isn't per-se a new paradigm in the likes of offline-first, which is advocating for local application cache/data synced with a remote store, this offering the benefit of offline apps, with the sync/realtime benefits of network connected apps.

It's a shame Server-Sent Events aren't universally supported. I find them a lot simpler than WebSockets - modifications are just normal HTTP calls, and then you can broadcast the actual result of the transactional call back down with a SSE. But Edge doesn't support them :(

Cool demo! I like that you can see all the events in real-time. I built a similar demo (https://os.alfajango.com/websockets-demo/ and https://github.com/JangoSteve/websockets-demo) a while ago to showcase using websockets with a node app for a presentation I was giving at a JavaScript user group (https://os.alfajango.com/websockets-slides/).

The presentation goes through a bit of the history and lead-up to websockets for context.

One of my favorite things about the demo for the presentation was that everyone in the room (probably about 50 people) was able to connect to the live demo in real-time and some people started finding XSS vulnerabilities in it right away, and using the app to send emojis and pictures to others in the room in real-time (all harmless stuff). It was crazy though how many events you could see streaming through the app just running from my laptop with so many people connected and interacting at once (including x,y coordinates for mouse movements a few times per second per user as well).

The presentation goes through alternatives as well, including long-polling, short-polling, and server-side events (the slides are laid out in two dimensions, so pay attention to when you can hit the "down" arrow instead of the "right" arrow for more slides). It also delves a bit into the actual websocket spec. It was a while ago though, so it doesn't go into anything HTTP2-related.

I have two projects on the go right now. Both have gone the web sockets first approach. I love it.

For me, the project I keep rebuilding to learn new languages/frameworks is Risk (though it's been quite awhile now).

After spending so much time with Phoenix channels on my main project, I couldn't resist the fun of reimplementing it over sockets. It'll probably wind up on GitHub when I'm done.

Is it wise to get hooked on websockets given that they're disappearing in HTTP2? I assume lattice is not tied to websocket as the implementation, and can switch to doing things over webrtc data (which would be even better for games since webrtc data can use UDP)

Just a heads up the the crystal language link is mis-routed in the readme.

Very cool demo. We did a demonstration of PornHub using WebSockets to bypass ad blockers[1] a few months ago., though that's more WebSocket-fallback development ;)

http://blog.bugreplay.com/post/152579164219/pornhubdodgesadb...

Can a normal web server (a Heroku dyno, for example) with a normal websocket library (https://github.com/gorilla/websocket, for example) support multiple users connected at the same time?

How many in comparison to the number of normal web clients that do some XHR call from time to time?

I think the key point is that web sockets are a TCP connection with a http prenogotiation. If you need UDP style connections (OK to miss state changes as long as it catches up) WebRTC is where it is at AFAIK.

Looks interesting - NB: Broken link in README that should go to https://crystal-lang.org/

WebSocket first seems to be the wrong way to go about this. How about build your app to accept stdin and stdout, then expose this as TCP, HTTP or whatever else?

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)

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.

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.

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.

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

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.