It took a decent amount of digging, but it seems like this is trying to be a browser-compatible pubsub system more than a direct websocket replacement. The main thing they're doing is introducing a "mercure hub" between event producers and consumers (browsers) that handles delivery through SSE in a way that tracks subscribers and handles sporadic or interrupted connection.
Most of their clientside examples look pretty simple but they don't seem like they're fully implementing the logic described in "Reconnection, State Reconciliation and Event Sourcing" which seems rather complex. Maybe I'm missing something but it seems like that logic is the entire reason to use this over SSE alone.
Indeed that's how it works. One of the key point of the solution is that you don't need anything client-side. The native EventSource class is all you need (but you can use more advanced SSE client libraries if wanted).
Reconnection and state reconciliation are achieved automatically. The hub implements all the needed features: it stores sent events and automatically resend them at reconnection time if they have been lost. It's possible to do this transparently because browsers will automatically send the ID of the last received message in a Last-Event-ID header when reconnecting. This feature is just often not implemented by SSE servers (because it’s not trivial to do).
It's also possible to ask events received since a specific ID, matching one or several topics just by passing the query parameters defined in the protocol section.
By the way, we are working on a new website that will make these things more clear.
Hi Kévin! A while ago, I’ve built a hub implementation using Typescript and Deno, mainly for learning, but also to see if I could come up with a neat solution for distributed event storage in-memory, using Raft. It implements the full spec, so far, and is pretty easy to understand, if I may say so myself.
Do you still accept entries for alternative hubs? It may be helpful for others to understand how the specification is supposed to work; some parts were a little opaque to me at first, and required digging into the reference implementation to fully grasp.
And it doesn't appear you have an associated working group (WG) for your (expired) draft publication, which could help you identify if you are reinventing an existing wheel..
WebSub cannot be used by browsers because browsers cannot receive POST requests. WebSub is for server to server communications.
Mercure is basically WebSub over SSE.
The draft has been discussed several times on the HTTP WG.
>The main thing they're doing is introducing a "mercure hub" between event producers and consumers (browsers) that handles delivery through SSE in a way that tracks subscribers and handles sporadic or interrupted connection.
This is the singgle biggest issue with using SSE, so I'm intrigued.
However what confuses me is that they seem to focus mostly on the protocol, hub, and publish implementation. At least based on a quick glance at https://mercure.rocks/docs/ecosystem/awesome and elsewhere it seems they expect you to use raw SSE clientside according to their protocol described in eg https://mercure.rocks/spec#active-subscriptions.
Most of their clientside examples look pretty simple but they don't seem like they're fully implementing the logic described in "Reconnection, State Reconciliation and Event Sourcing" which seems rather complex. Maybe I'm missing something but it seems like that logic is the entire reason to use this over SSE alone.