[Question] Do you consider supporting long-lasting server side streaming?

Hi Nico!

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!

I see.

There is 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-node (server).

connect-web is essentially a web-first grpc client. It provides a framework for pluggable transports and ships with transport for connect and 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 :-)

This was really helpful when it comes to understanding what this project currently covers and in which direction development goes. Thanks a lot!