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.<p>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 <a href="https://mercure.rocks/docs/ecosystem/awesome" rel="nofollow">https://mercure.rocks/docs/ecosystem/awesome</a> and elsewhere it seems they expect you to use raw SSE clientside according to their protocol described in eg <a href="https://mercure.rocks/spec#active-subscriptions" rel="nofollow">https://mercure.rocks/spec#active-subscriptions</a>.<p>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.
Also I could recommend <a href="https://github.com/slact/nchan">https://github.com/slact/nchan</a>. It has the same idea: hide and abstract pubsub complexity for a backend service. nchan is built on top of nginx and could be more convenient (existing nginx configuration knowledge) to deploy.
The specification appears to be very similar to FeedAPI which I have been involved with:<p><a href="https://github.com/vippsas/feedapi-spec">https://github.com/vippsas/feedapi-spec</a><p>Our focus was kind of the opposite though: Remove the event broker instead of adding one.<p>If I understand correctly, Mercure allows you to push events to the broker and clients pull log-based events.<p>With FeedAPI we focused instead of removing the broker (RabbitMQ/Kafka/...) and let clients pull log-based events directly from backends.<p>Very similar protocol though.
I use PHP/Symfony/Websockets for a real time web app.<p>I have been looking over at SSE/Mercure for a while, as Symfony recomends it for Server->Client traffic.
<a href="https://symfony.com/doc/current/mercure.html" rel="nofollow">https://symfony.com/doc/current/mercure.html</a><p>However I am yet to see a reason to swap out my currently working websocket implementation other than SSE is the new shiny thing.<p>Can anybody tell me any other benefits that I may get from making this switch?
Reminds me of WAMP (Web Application Messaging Protocol) [0], which is a WebSocket subprotocol.<p>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?<p>[0] <a href="https://en.wikipedia.org/wiki/Web_Application_Messaging_Protocol#Comparison" rel="nofollow">https://en.wikipedia.org/wiki/Web_Application_Messaging_Prot...</a>
We've been using Mercure for 3+ years in production. It's been pretty much set it and forget it. Maybe once a year do we have to maintain the server e.g. clear up space, but overall has been great for our use case (which does not need full pub/sub).
Was there a specific reason to use AGPL-3.0? Not critizing, just asking.<p>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.<p>[1] <a href="https://mercure.rocks/docs/hub/license" rel="nofollow">https://mercure.rocks/docs/hub/license</a>