Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
In case people don't know, Mark Nottingham (the author) is the chair of the HTTP working group at the IETF. He isn't just some guy with opinions on the internet. (Sorry mnot!)
I've never found pub/sub quite the right abstraction, because almost every implementation I've seen has race conditions or issues on reconnect. Usually its possible to lose messages during reconnection, and there's often other issues too. I usually want an event queue abstraction, not pub/sub.
I met mnot a few years ago when we (the braid group) took a stab at writing a spec for HTTP based streaming updates[1]. Our proposal is to do state syncronization around a shared objects (the URL). Each event on the channel is (explicitly or implicitly) an update for some resource. So:
- The document (resource) has a version header (ETag?).
- Each event sent on the stream is a patch which changes the version from X to Y. Patches can either be incremental ("insert A at position 5") or if its small, just contain a new copy of the document.
- You can reconnect at any time, and specify a known version of the document. The server can bring you up to date by sending the patches you missed. If the server doesn't store historical changes, it should be able to just send you a fresh copy of the document. After that, the subscription should drip feed events as they come in.
One nice thing about this is that CDNs can do highly efficient fan-out of changes. A cache could also use braid to subscribe to resources which change a lot on the origin server, in order to keep the cached values hot.
[1] https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...
We've done some revisions since then but have been working on getting more running code before pushing forward more with the approach. Most recent draft & issues: https://github.com/braid-org/braid-spec/blob/master/draft-to...
Could use pushpin[1] and have several fallbacks, like SSE -> Websocket -> polling.
Thats not a summary, any more than "action movie" is a summary of Iron Man.
That XKCD comic is funny because names a common technical motivation. But it doesn't summarize the work because it removes all the interesting & relevant technical details.
Its also really done at this point. That link has been posted 733 times in HN comments[1]. It was funny the first time, but its time to let it die.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Here is an event stream abstraction that has very strong semantics (exactly once in most cases) with simple usage examples, native HTTP and websockets APIs, strong atomicity and durability guarantees [1].
What it doesn’t have is clustering and a father that’s != null at marketing =]
Very interesting. I've implemented something similar. It evolved out of the co-browsing solution I developed for the company I work for.
The solution uses mqtt. Clients subscribe to a topic on the server, and the server publishes patches to update the view. Patches can be incremental (patch against the last frame), cumulative (patch agains the last keyframe) or a new keyframe. It allows for server side rendered views. Multiple clients can subscribe to the same view and keep in sync. See: https://github.com/mmzeeman/zotonic_mod_teleview
An example proof of concept application: https://github.com/mmzeeman/zotonic_mod_doom_fire/
You might also checkout https://rsocket.io/
> I'm not up to date with the less popular web frameworks. Which frameworks do that?
One of them is https://github.com/phoenixframework/phoenix_live_view which is a component of Phoenix / Elixir.
It will render your initial page over HTTP but then when you transition pages or perform actions using various functions it provides you it will send a diff of what's changed over WebSockets. These actions could be limited to only the 1 user using the site, such as clicking different links in a nav bar to transition between page A and B.
The alternative to this is doing what other frameworks like Rails has done with Hotwire Turbo where they make these types of transitions of actions over HTTP. Turbolinks started to do this back in 2015 or whenever it came out and now more recently with Hotwire Turbo there's ways to only update a tiny area of the page (again over HTTP) but it also optionally supports using WebSockets for when you want to broadcast things to all connected clients, such as updating a counter somewhere or maybe showing a new reply on a blog post, etc..
Laravel has Live Wire and there's also HTMX which is back-end agnostic which all use HTTP for a bulk of their behaviors to send server rendered HTML over the wire.
I've been working on a pub/sub server that supports both Websockets and SSE as a hobby project for a couple of years. It have been successfully implemented and is used in production on some high traffic sites with 300k+ simultaneous connections. If someone are interested the projects webpage can be found here: https://github.com/olesku/eventhub