Show HN: WebSocket-first development

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&#x2F;response protocols that are faster than HTTP&#x2F;1 to advanced stuff like publish&#x2F;subscribe mechanisms and even protocols that keep the clients state automatically synchronized to the server side.<p>For advanced use-cases that&#x27;s certainly a way to explore. For the average user I&#x27;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&#x2F;response abstraction, dozens of frameworks and mechanisms for authorization, logging, etc. HTTP is also easily load-balanceable, while websockets are not. HTTP&#x2F;2 in principal makes small request&#x2F;response exchanges as fast as you could implement them with a custom websocket protocol, so there&#x27;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&#x27;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 <a href="https:&#x2F;&#x2F;github.com&#x2F;uWebSockets&#x2F;uWebSockets" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uWebSockets&#x2F;uWebSockets</a> instead).<p>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 <i></i>lose state<i></i> on reload. Your game will be in a completely wrong state. Managing and maintaining state is the important thing (which is what <a href="https:&#x2F;&#x2F;github.com&#x2F;amark&#x2F;gun" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;amark&#x2F;gun</a> does, which is of course also &quot;websockets-first&quot;). When you reload your game, it should return&#x2F;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?<p>Do you have a way to cluster websocket servers so that events are propagated to all clients?

I think websockets as you&#x27;re using it is a stand-in for realtime-first development.<p>This territory is well explored -- services like firebase&#x2F;parse are a testament to many usecases.<p>IMO, this isn&#x27;t per-se a new paradigm in the likes of offline-first, which is advocating for local application cache&#x2F;data synced with a remote store, this offering the benefit of offline apps, with the sync&#x2F;realtime benefits of network connected apps.

It&#x27;s a shame Server-Sent Events aren&#x27;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&#x27;t support them :(

Cool demo! I like that you can see all the events in real-time. I built a similar demo (<a href="https:&#x2F;&#x2F;os.alfajango.com&#x2F;websockets-demo&#x2F;" rel="nofollow">https:&#x2F;&#x2F;os.alfajango.com&#x2F;websockets-demo&#x2F;</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;JangoSteve&#x2F;websockets-demo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JangoSteve&#x2F;websockets-demo</a>) a while ago to showcase using websockets with a node app for a presentation I was giving at a JavaScript user group (<a href="https:&#x2F;&#x2F;os.alfajango.com&#x2F;websockets-slides&#x2F;" rel="nofollow">https:&#x2F;&#x2F;os.alfajango.com&#x2F;websockets-slides&#x2F;</a>).<p>The presentation goes through a bit of the history and lead-up to websockets for context.<p>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).<p>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 &quot;down&quot; arrow instead of the &quot;right&quot; arrow for more slides). It also delves a bit into the actual websocket spec. It was a while ago though, so it doesn&#x27;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.<p>For me, the project I keep rebuilding to learn new languages&#x2F;frameworks is Risk (though it&#x27;s been quite awhile now).<p>After spending so much time with Phoenix channels on my main project, I couldn&#x27;t resist the fun of reimplementing it over sockets. It&#x27;ll probably wind up on GitHub when I&#x27;m done.

Is it wise to get hooked on websockets given that they&#x27;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&#x27;s more WebSocket-fallback development ;)<p><a href="http:&#x2F;&#x2F;blog.bugreplay.com&#x2F;post&#x2F;152579164219&#x2F;pornhubdodgesadblockersusingwebsockets" rel="nofollow">http:&#x2F;&#x2F;blog.bugreplay.com&#x2F;post&#x2F;152579164219&#x2F;pornhubdodgesadb...</a>

Can a normal web server (a Heroku dyno, for example) with a normal websocket library (<a href="https:&#x2F;&#x2F;github.com&#x2F;gorilla&#x2F;websocket" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gorilla&#x2F;websocket</a>, for example) support multiple users connected at the same time?<p>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 <a href="https:&#x2F;&#x2F;crystal-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;crystal-lang.org&#x2F;</a>

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?