Hello


As we know, Server-side  notification/push can be achieved by multiple ways 
depending upon what you want to achieve.

In my use-case , the built-in  HTTP/2 SERVER_PUSH frames  based approach is 
NOT feasible.

Another approach is web-socket. But that does not fit very well with HTTP/2

Web-push API is also not a good fit because it is based on service-worker 
and more heavy-weight compared to some in-line technology.

 

In this context, I believe I can do it with HTTP/2 + server-side-event  and 
leverage Event-Source Mechanism.

 

However , I  am interested in exploring if some streaming-based gRPC  API 
can help me.

Basically, in my use-case I want the server to send the data if/when 
available with  him.

So in simple terms

I invoke one gRPC server-side streaming API in asynchronous, non-blocking 
mode and then continue on my client-side browser work.

The implementation of gRPC server-side code will just push the data 
whenever available by calling     streamObserver.onNext(response);

If data is not available the server-side method will just sleep for a while 
before checking for the next time.

Basically, the underlying design here is the HTTP/2 stream that is spawned 
will remain open forever on that TCP connection. 



Do you think this is scalable enterprise level architecture ?  Can we keep 
the HTTP/2 stream open for long time ?

 

 

Thanks.

-- 
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/64cf617a-e346-4ff9-bafc-9c228baf7009%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to