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.
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.
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..
This is the singgle biggest issue with using SSE, so I'm intrigued.
I read the Github readme, but it doesn't say what's better.
WebSockets are hard to secure (they totally bypass CORS as well as other browser built-in protections), don't work (yet) with HTTP/3 and for most use cases require to implement many features by yourself: reconnection in case of network failure, refetch of lost messages, authorization, topic mechanism…
Mercure, which is built on top of SSE (it's more an extension to SSE than an alternative to it) fix these issues.
However, SSE (as well as WebSockets) can be hard to use with stacks not designed to handle persistent connections such as PHP, serverless, most web servers proxying Ruby, Python etc apps. Even for languages designed to handle persistent connections, it's often more efficient and easier to manage persistent connections with ah-hoc software running on dedicated hardware.
That's what Mercure allows. Mercure provides a "hub", a server that will maintain the persistent connections with the browsers, store events, and re-send them in case of network issues (or if asked for old messages by a client). To broadcast a message to all connected users, the server app (or even a client) can just send a single POST request to the hub. The hub will also check that clients are authorized to subscribe or publish to a given topic (that's why JWT is used).
The reference implementation is written in Go, as a module for the Caddy web server, and his very efficient/optimized (it can handle thousands of persistent connections on very small machines).
Install a Mercure hub and you have all these features available without having to write any code. Client-side, no SDK is required, you can embrace the built-in EventSource JavaScript class.
You can reimplement the Same Origin Policy serverside by checking that the Origin header equals the Host header. Even more secure would be to check both against an allowlist (this protects against DNS rebinding, which the Same Origin Policy doesn't protect against).
>as well as other browser built-in protections
I'm curious what those are.
>for most use cases require to implement many features by yourself: [...] authorization
Isn't auth of websockets generally the same as auth of any Javascript-initiated HTTP request (e.g. fetch())? Check that the cookie looks good? Now, in the cause of OAuth tokens, websockets are more difficult than fetch(), because you cannot attach an Authorization: Bearer header to a websocket. But OAuth is less common than cookies for websites.
Having written WebSocket CORS with Authentication (Cognito) I know this isn't quite true. The initial connection is a standard HTTP request that returns a 100 series, with preflights and everything. That initial request has all the headers you might want to sent to a server for auth. It's a bit odd IMO but the auth string is sent in the web socket constructor, second argument, really easy to miss. Happy to provide both server and client code examples.
https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/W...
You might consider updating the readme to make it clear what Mercure/SSE does that WebSockets doesn't.
If it was me, I'd also put in the readme what WebSockets does that Mercure/SSE does not, such as bidirectional communication, low latency client-to-server messages, binary data transfer, etc.
By the way I'm sure JWTs are fine not trying to step on any toes I'm just not an expert with them and I know there are footguns so with security stuff I stick to the most boring technology I have access to.
Basically its server sent events with some stuff on top:
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
One big benefit of SSE is that you can put them behind a CDN, making scaling a lot easier. No idea about what Mercure brings there, though.
This connection limit does not apply when using SSE over HTTP/2+, because server connections are multiplexed onto a single connection.
I also prefer starting with SSE where possible, as it is simple conceptually, easy to implement (even from scratch), and doesn't introduce a secondary client to server path. Having that ability (even if unused) tends to create a temptation to use it, and when that happens it introduces a choice of whether to use normal HTTP requests or make an equivalent request over websocket.
Using websocket for things HTTP can handle is a mistake, in my opinion, because HTTP is simpler than websocket to fetch state.
Of course, if you need websocket, you need it, but there are some that just want to play with it in production or add it to their resume. I suspect that dynamic is what causes the 'cargo culting' you talk about.
There are some issues with SSE in HTTP/1.1, but HTTP/2 pretty much fixes those.
I am curious what problem(s) are being targeted with this solution.
You can use it with Symfony's copy of Phoenix LiveView for example.
There is also an issue with SSE I've noticed that websockets doesn't seem to have as much of a prevalent issue with, and that is being blocked by corporate firewalls.
https://github.com/vippsas/feedapi-spec
Our focus was kind of the opposite though: Remove the event broker instead of adding one.
If I understand correctly, Mercure allows you to push events to the broker and clients pull log-based events.
With FeedAPI we focused instead of removing the broker (RabbitMQ/Kafka/...) and let clients pull log-based events directly from backends.
Very similar protocol though.
I have been looking over at SSE/Mercure for a while, as Symfony recomends it for Server->Client traffic. https://symfony.com/doc/current/mercure.html
However I am yet to see a reason to swap out my currently working websocket implementation other than SSE is the new shiny thing.
Can anybody tell me any other benefits that I may get from making this switch?
I find the title odd, because, why would you want to replace server-sent events with WebSocket, if the great thing about SSE is the simplicity, both client- and server-side?
[0] https://en.wikipedia.org/wiki/Web_Application_Messaging_Prot...
And does it work well with non-browser consumers like native mobile apps?
Native mobile apps are also entirely supported. It's a very common use case. Most mobile languages have SSE client libraries.
The biggest issue with SSE is that there is unfortunately alot of deployed software that will downgrade incoming connections to HTTP/1.1 so even if the client would have otherwise supported HTTP/2 or higher its not presented the ability to do so.
Tried to read about the license and was greeted by a tl;dr summary of the AGPL-3.0 license [1]. I am no lawyer but my gut tells me that providing such a summary is an invitation to strange disputes. Take care.
For example, Creative Commons has a visual/bullet point explanation of their licenses. That's entirely okay, as the legal text is the core license.
I had a similar discussion with a lawyer once about a TOS that also included a summary. The lawyer told me that as long as you make it clear that your summary is just a summary, and is not the agreement, and you point out the actual agreement, you're okay.
In this case, the OP is pointing to the legal text clearly and merely summarizing it's most salient points.
Again, IANAL and this is not legal advice.
