How to Implement Server-Sent Events in Go

[Alex Pliutau]

Does anyone use Server-Sent Events in their projects? If yes, for which use cases?
https://youtu.be/nvijc5J-JAQ 

[Robert Engels]

Server sent events are effectively replaced by websockets. The latter is more versatile and usually has better browser support. 

On Oct 23, 2024, at 8:54 AM, Alex Pliutau <a.pl...@gmail.com> wrote:

Does anyone use Server-Sent Events in their projects? If yes, for which use cases?
https://youtu.be/nvijc5J-JAQ 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dc670d28-42e6-4388-ba64-9bbc6c5e3053n%40googlegroups.com.

[Brian Hatfield]

Here's a toy example on how to implement it: https://github.com/bmhatfield/sse

On Wed, Oct 23, 2024 at 9:54 AM Alex Pliutau <a.pl...@gmail.com> wrote:

Does anyone use Server-Sent Events in their projects? If yes, for which use cases?
https://youtu.be/nvijc5J-JAQ 

--

[Brian Hatfield]

I don't think it's quite so binary. Websockets are a lot more complex, require more sophisticated endpoints and load balancing. SSE has fine browser support in 2024, minus the ability to set auth headers. I think for cases with unidirectional communication, SSE is a choice worth evaluating.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3C9A2856-51D9-4AB5-952A-7B852E917076%40ix.netcom.com.

[Zane Attahri]

Second this, and go ever further.

If you don’t need bi-directional communication, SSE are almost always the better choice. Simpler to implement, standard, and easier to consume by non-browser clients.

[Alex Pliutau]

Yes, I prefer SSE when only server to client comm is needed. Really easy and works well on a single HTTP connection.

[robert engels]

A lot depends on the volume - you need back pressure support for high volume events over the internet - and the built-in ping/pong of WS makes this straightforward. I think it is pretty hard to do back pressure if unidirectional as well (need side endpoints, etc.).

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2A0061EB-36AA-472E-8B9D-81BBD0F779E0%40attahri.com.

[robert engels]

This might be helpful https://dev.to/miketalbot/server-sent-events-are-still-not-production-ready-after-a-decade-a-lesson-for-me-a-warning-for-you-2gie

We had an SSE and abandoned it for WS - but we were high volume.

[Sharon Mafgaoker]

Hi Robert

Thank you for sharing with us.
From 2020 still relevant?

Sharon Mafgaoker – Senior Solutions Architect 

M. 050 995 99 16 | sha...@cloud5.co.il

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/797096F1-5219-40BD-A382-AF79B435EAAB%40ix.netcom.com.

[Robert Engels]

Not sure. I worked with SSE last year and got our needs WS was much easier to deal with - for a few of the reasons cited in the article and some others. 

On Oct 23, 2024, at 7:24 PM, Sharon Mafgaoker <sha...@cloud5.co.il> wrote:



[twp...@gmail.com]

I've had good success with Go/Server-Sent Events/HTMX/templ for cross-platform tools. Quick overview:

* Go runs a webserver listening on localhost and opens the user's browser.

* Front end is HTMX with HTML fragments served using the templ HTML templating engine.

* Updates to the front end are pushed with SSE.

* Everything is distributed as a single self-contained binary, with assets bundled with go:embed.

* Cross-platform support (Linux/Windows/macOS) is trivial thanks to Go's cross-compilation.

My own SSE library that makes SSE as easy to use as Go channels: https://github.com/twpayne/go-sse

There's also https://github.com/romshark/templier which supports this kind of application, but I've not used it yet.

Regards,

Tom

[Jesús Ruiz]

If you are not using TLS end-to-end then yes, it should be applicable in 2024. Because there may be many intermediate proxies out there which may affect how it works, including the store-and-forward mentioned in the article.

But you MUST use TLS for everything, and then SSE are production ready (they were since a lot of years).

And then the choice of SSE vs WebSockets depends on the use case of your application.

Of course, you could use WebSockect for everything, as they are more general than SSEs. But I do not, and I use each for its sweet spot. If I can use SSE, it is simpler, more integrated in the underlying system (browser and server), etc.

But again, for most use cases, you can just use WebSockets and (when you can get them working reliably), they can be used for everything.

La presente comunicación tiene como destinataria la persona (o personas) a la que, de manera exclusiva, va dirigida. La presente comunicación puede contener información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la Ley. En caso de haberla recibido por error, deberá notificárselo al remitente de forma inmediata y por esta misma vía. De igual modo, deberá proceder a su eliminación, así como a la de cualquier documento adjunto a la misma. La distribución, copia o utilización del contenido de esta comunicación y/o el de sus anexos, cualquiera que fuera su finalidad, están prohibidas por la Ley. En aras del cumplimiento del Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (RGPD); y en aras, también, de la conformidad con la Ley Orgánica 3/2018, de 5 de diciembre, de protección de datos personales y garantía de los derechos digitales (LOPDGDD), queda informado de que puede ejercer los derechos de acceso, rectificación, cancelación, limitación, oposición y portabilidad, de manera gratuita, mediante mensaje de correo a la dirección electrónica datapro...@alastria.io, o bien dirigiendo un escrito a CONSORCIO RED ALASTRIA. CIF: G87936159. C/ Alberto Aguilera, nº 23. E-28015, Madrid.

The present communication is intended for the person (or persons) to whom it is exclusively addressed. This communication may contain confidential information subject to professional secrecy, the disclosure of which is not permitted by Law. If you have received it by mistake, you must notify the sender immediately. In the same way, you must remove it from your system, as well as any other document attached to it. The distribution, copying or use of the contents of this communication and / or its annexes, whatever their purpose, are prohibited by Law. In order to comply with Regulation (EU) 2016/679 of the European Parliament and of the Council, of April 27, 2016, regarding the protection of natural persons with regard to the processing of personal data and the free circulation of this data and repealing Directive 95/46 / EC (RGPD); and for the sake of compliance with the Organic Law 3/2018, of December 5, on
the protection of personal data and the guarantee of digital rights (LOPDGDD), you are informed that you can exercise the rights of access, rectification, cancellation, limitation, opposition and portability, free of charge, by email to the electronic address  datapro...@alastria.io, or by writing to CONSORCIO RED ALASTRIA. CIF: G87936159. C /Alberto Aguilera, nº 23. E-28015, Madrid.