Mercure: A WebSocket alternative for server-sent events

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&#x27;re doing is introducing a &quot;mercure hub&quot; 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:&#x2F;&#x2F;mercure.rocks&#x2F;docs&#x2F;ecosystem&#x2F;awesome" rel="nofollow">https:&#x2F;&#x2F;mercure.rocks&#x2F;docs&#x2F;ecosystem&#x2F;awesome</a> and elsewhere it seems they expect you to use raw SSE clientside according to their protocol described in eg <a href="https:&#x2F;&#x2F;mercure.rocks&#x2F;spec#active-subscriptions" rel="nofollow">https:&#x2F;&#x2F;mercure.rocks&#x2F;spec#active-subscriptions</a>.<p>Most of their clientside examples look pretty simple but they don&#x27;t seem like they&#x27;re fully implementing the logic described in &quot;Reconnection, State Reconciliation and Event Sourcing&quot; which seems rather complex. Maybe I&#x27;m missing something but it seems like that logic is the entire reason to use this over SSE alone.

Please explain why this is better than websockets.<p>I read the Github readme, but it doesn&#x27;t say what&#x27;s better.

Also I could recommend <a href="https:&#x2F;&#x2F;github.com&#x2F;slact&#x2F;nchan">https:&#x2F;&#x2F;github.com&#x2F;slact&#x2F;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.

Does it still have the limitation of SSE ie; it&#x27;ll stop working after you open 6 tabs?

The specification appears to be very similar to FeedAPI which I have been involved with:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;vippsas&#x2F;feedapi-spec">https:&#x2F;&#x2F;github.com&#x2F;vippsas&#x2F;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&#x2F;Kafka&#x2F;...) and let clients pull log-based events directly from backends.<p>Very similar protocol though.

I use PHP&#x2F;Symfony&#x2F;Websockets for a real time web app.<p>I have been looking over at SSE&#x2F;Mercure for a while, as Symfony recomends it for Server-&gt;Client traffic. <a href="https:&#x2F;&#x2F;symfony.com&#x2F;doc&#x2F;current&#x2F;mercure.html" rel="nofollow">https:&#x2F;&#x2F;symfony.com&#x2F;doc&#x2F;current&#x2F;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:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Web_Application_Messaging_Protocol#Comparison" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Web_Application_Messaging_Prot...</a>

We&#x27;ve been using Mercure for 3+ years in production. It&#x27;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&#x2F;sub).

I like it; too much stuff to write yourself with websockets.

Does it play well behind a load balancer? For example Cloudflare&#x27;s?<p>And does it work well with non-browser consumers like native mobile apps?

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:&#x2F;&#x2F;mercure.rocks&#x2F;docs&#x2F;hub&#x2F;license" rel="nofollow">https:&#x2F;&#x2F;mercure.rocks&#x2F;docs&#x2F;hub&#x2F;license</a>