I would like to keep a connection between the web client and the server for quite some time so that I can push data to the client that emerge during the time of the connection.
I would like to know if you have considered any mechanisms like websockets or server-sent events to push data to a client who is connected to a streaming endpoint over a long time. If you have considered it I would like to ask you to share if you plan to implement it in the future and if not why. Thank you really much!
Streaming is already supported (with some limitations based on browser version / http version, etc.) as noted in the docs here: https://connect.build/docs/protocol#streaming-rpc
There's also a mention in the FAQs: https://connect.build/docs/faq#is-streaming-supported
Thanks for the response, Sebastian. Seems like there was a misunderstanding. I had read the articles before. I assumed the connect protocol (not gRPC web) would also have a web equivalent just like gRPC web for gRPC. And I thought this protocol would still be about to be shaped. I could neither find something refuting my assumption nor something proving it which is why I asked if you consider adding further specs based on websockets and server sent events to your protocol spec. Additionally, I assumed you would intentionally set timeouts on server streaming RPCs on the client side since my client-server connection was always interrupted after 10 seconds. This was an issue with my custom Ingress controller in my Kubernetes cluster though so it had nothing to do with the web implementation of connect even though it further pushed me in the wrong direction of assuming this would be intentional.
Anyway, your answer makes me assume that connect-web is rather meant to fulfil the needs it can by only using the fetch API which allows for server streaming just like gRPC web. I hope my understanding of your goals is correct now. If it's not I would like to ask you to reopen this issue and clarify your plans. Thanks again!
connect (the protocol), which is simply a fetch-compatible,
POST based HTTP protocol that brings grpc to the browser on top of
connect-compatible servers (
connect-go exists already,
connect-node is on the way, and others will surely follow).
This repository contains several TypeScript packages including
connect-web (client) &
connect-web is essentially a web-first grpc client. It provides a framework for pluggable transports and ships with transport for
grpc-web by default. Depending on your use-case, you can plug in different transports in the client and then communicate with a server as long as it is compatible with that transport. Using
protoc-gen-connect-web you can generate fully typed clients for your grpc specs.
connect-node (under development) is a grpc server (just like
connect-go) that can support one or multiple (or all) of the transport protocols, including also the raw
grpc protocol: The same server can be used for both your web / browser use-cases and your backend consumer use cases. Without requiring a complicated (Envoy, etc.) proxy layer!
I could neither find something refuting my assumption nor something proving it which is why I asked if you consider adding further specs based on websockets and server sent events to your protocol spec
connect (thankfully) doesn't use websockets but relies on modern HTTP features to cover its streaming needs :-)
|Issue Title||Created Date||Updated Date|