4 ms·

Please explain why this is better than websockets. I read the Github readme, but it doesn't say what's better.

gorjusborg 2y ago
Along the same lines, what is the need for an alternative to SSE? 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.
afavour 2y ago
The site offers a little more detail: https://mercure.rocks/ https://mercure.rocks/ Basically its server sent events with some stuff on top: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events 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.
conradfr 2y ago
It's targeted at PHP apps. You can use it with Symfony's copy of Phoenix LiveView for example.
- rbrtdrmpc- 2y ago
  It is targeted to the PHP community, not the language, it has no dependency on that, it is written in go and is based on caddy. (I’ve contributed with one PR in my former job)
  - archerx 2y ago
    It’s pretty easy to set up SSE in PHP and works very well. I don’t see how adding this helps at all…
    - withinboredom 2y ago
      It's really not. Not properly anyway. You'd spend a week, probably, just getting all the synchronization stuff right. Unless of course, you don't care about losing messages during a disconnection. Or you could just install this in a couple of hours and be done with it; not have to worry about security, maintaining NIH libraries, etc.
      - archerx 2y ago
        It is very easy, I have used it on various projects including chats, live dynamic dash boards, prompters and games. The SSE setup took less than a day, never had issues with sync. Never lost messages during disconnection or any issues. I don’t know how you’ve been using SSE, but if you’ve had all these issues you must have been doing something very wrong.
    - julik 2y ago
      Fear of long-lived processes
      - archerx 2y ago
        It’s not an issue, I’ve had processes running for days without issues.
upghost 2y ago
They seem to handle a lot of nontrivial issues I have to deal with frequently like synchronization, but weirdly enough they do it with JWTs. For me the entire point of SSEs is that I can avoid using JWTs and use standard session logic which is very easy to reason about. 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.
Timber-6539 2y ago
SSE fixes some of the cargo cult practices formed around Websockets.
- whilenot-dev 2y ago
  Care to explain a bit more? (otherwise I'd feel like being cargo cultured into SSEs)
  - Timber-6539 2y ago
    Going off my personal experience I don't see SSE being mentioned anywhere at all. But I always come across some new shiny web framework/wsgi listing websockets as a feature. The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard.
    - gorjusborg 2y ago
      > The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard. I suspect the treatment as 'standard' is what thread OP is talking about. See my sibling comment in the thread. Unless you absolutely need websocket, SSE is simpler, and due to that, better. I suspect the reason many select websocket over SSE is due to its limitations (connection limit under HTTP/1.1, no client->server sends), but SSE for server->client events and normal HTTP requests for state fetching is better architecturally for bog standard apps in my experience.
- gorjusborg 2y ago
  I have certainly seen people reach for websockets to just reverse the direction of data flow from server to client. On HTTP/1.1, the main issue people can hit is the max connection limit. 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.
kdunglas 2y ago
Hi, Mercure author here. 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.
- Thorrez 2y ago
  > they totally bypass CORS 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.

Along the same lines, what is the need for an alternative to SSE? 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.

afavour 2y ago

The site offers a little more detail: https://mercure.rocks/ https://mercure.rocks/ Basically its server sent events with some stuff on top: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events 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.

conradfr 2y ago

It's targeted at PHP apps. You can use it with Symfony's copy of Phoenix LiveView for example.

rbrtdrmpc- 2y ago
It is targeted to the PHP community, not the language, it has no dependency on that, it is written in go and is based on caddy. (I’ve contributed with one PR in my former job)
- archerx 2y ago
  It’s pretty easy to set up SSE in PHP and works very well. I don’t see how adding this helps at all…
  - withinboredom 2y ago
    It's really not. Not properly anyway. You'd spend a week, probably, just getting all the synchronization stuff right. Unless of course, you don't care about losing messages during a disconnection. Or you could just install this in a couple of hours and be done with it; not have to worry about security, maintaining NIH libraries, etc.
    - archerx 2y ago
      It is very easy, I have used it on various projects including chats, live dynamic dash boards, prompters and games. The SSE setup took less than a day, never had issues with sync. Never lost messages during disconnection or any issues. I don’t know how you’ve been using SSE, but if you’ve had all these issues you must have been doing something very wrong.
  - julik 2y ago
    Fear of long-lived processes
    - archerx 2y ago
      It’s not an issue, I’ve had processes running for days without issues.

upghost 2y ago

They seem to handle a lot of nontrivial issues I have to deal with frequently like synchronization, but weirdly enough they do it with JWTs. For me the entire point of SSEs is that I can avoid using JWTs and use standard session logic which is very easy to reason about. 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.

Timber-6539 2y ago

SSE fixes some of the cargo cult practices formed around Websockets.

whilenot-dev 2y ago
Care to explain a bit more? (otherwise I'd feel like being cargo cultured into SSEs)
- Timber-6539 2y ago
  Going off my personal experience I don't see SSE being mentioned anywhere at all. But I always come across some new shiny web framework/wsgi listing websockets as a feature. The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard.
  - gorjusborg 2y ago
    > The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard. I suspect the treatment as 'standard' is what thread OP is talking about. See my sibling comment in the thread. Unless you absolutely need websocket, SSE is simpler, and due to that, better. I suspect the reason many select websocket over SSE is due to its limitations (connection limit under HTTP/1.1, no client->server sends), but SSE for server->client events and normal HTTP requests for state fetching is better architecturally for bog standard apps in my experience.
gorjusborg 2y ago
I have certainly seen people reach for websockets to just reverse the direction of data flow from server to client. On HTTP/1.1, the main issue people can hit is the max connection limit. 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.

kdunglas 2y ago

Hi, Mercure author here. 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.

Thorrez 2y ago
> they totally bypass CORS 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.