Hello, I choose grpc to replace a REST data interface together with Server-Events (SSE /Signalr /Websockets) with a single "non proprietary " protocol.
I found a downside of grpc in terms of Server-Sent-Events: There will always be a blocking thread. -> https://github.com/grpc/grpc/issues/8718#issuecomment-354673344 My own implementation: https://pastebin.com/HwPY6nLX So far i found no other way to implement (Server-Sent-Events), than to have the requesting thread to block for eternity (or at least for event subscription time) with a responseStream. This results in an enormous amount of threads "hanging in sleep" ( number of subscribed clients * number of server side events). In Terms of scaling this is a bottleneck i am trying to adress here. Has any of you better implementations or ideas? In conclusion I wonder if there are any plans to make grpc a better SSE/Signalr/Websockets alternative in terms of server side events, cause in my humble opinion the only problem is that currently a responseStream cannot survive the life-time-end of the initial request. Thanks for your time in advance Michael -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/24d14cca-e51d-4a03-ba43-39ea4e1680f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
