Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 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 wrote:Hi RobertThank you for sharing with us.From 2020 still relevant?Sharon Mafgaoker – Senior So

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 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 On Wed, 23 Oct 2024 at 17:53 robert engels wrote: > This might be helpful > https://dev.to/miketalbot/server-sent-events-are-still-not-pro

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 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. > On Oct 23, 2024, at 9:48 AM, robert engels wrote: > > A lot depends on the

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 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.). > On Oct 23, 2024, at 9:44 AM

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread Alex Pliutau
Yes, I prefer SSE when only server to client comm is needed. Really easy and works well on a single HTTP connection. On Wednesday, October 23, 2024 at 4:45:07 PM UTC+2 Zane Attahri wrote: > Second this, and go ever further. > > If you don’t need bi-directional communication, SSE are almost alwa

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 'Zane Attahri' via golang-nuts
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. > On Oct 23, 2024, at 10:37 AM, Brian Hatfield wrote: > > I don't think it's quite so bina

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 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. On Wed

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 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 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

Re: [go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread 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 wrote:Does anyone use Server-Sent Events in their projects? If yes, for which use cases?https://youtu.be/nvijc5J-JAQ  -- Yo

[go-nuts] How to Implement Server-Sent Events in Go

2024-10-23 Thread Alex Pliutau
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

Re: [go-nuts] ANN: selfy for self-signed certs. rpc25519 for blazing QUIC based RPC

2024-10-23 Thread Vasiliy Tolstov
Thank you, this is very cool and helpful вт, 22 окт. 2024 г. в 23:51, Jason E. Aten : > > I wrote this RPC package recently: > > https://github.com/glycerine/rpc25519 > > `rpc25519` is a fun little RPC package that I cooked up to > get comfortable with modern (Ed25519) rather than > antiquated (RS