SSE support

[strblr]

Hello,

Very impressive work! Will definitely give it a try for future projects.
Do you have any time estimation for SSE support?

Thanks!

[dinwwwh]

Does a streaming response, like those used in AI chatbots or a yield function, meet your needs? I already have something like this in mind.

[motopods]

Is there a plan to support WebSocket subscriptions? When developing real-time applications such as chat messages, if we follow the current tRPC approach and need to subscribe to multiple types of messages, SSE will quickly reach the limit of 6 connections, leading to a poor user experience. WebSocket, however, can efficiently reuse a single connection.

[dinwwwh]

Honestly, I'm not a fan of subscriptions in tRPC. So far, I only have a solid design for streaming responses, but I still need to think more about WebSocket/Server-Sent Events

[strblr]

Does a streaming response, like those used in AI chatbots or a yield function, meet your needs?

That's probably enough for chatbots, but I can think of scenarios where you'd want low-level SSE or websocket. Would also help incrementally migrate existing tRPC / rest apis.

[dinwwwh]

@strblr @motopods can you share more about your requirements/usecase

[strblr]

Chatbots, but also live query systems. I've built this for trpc: https://github.com/strblr/trpc-live
In my projects in general I just like having queries that update from the server. SSE over HTTP/1 is also gonna be too limited. So either HTTP/2 SSE or websockets. With graphql I'm using websockets just for live queries.

[dinwwwh]

Chatbots, but also live query systems. I've built this for trpc: https://github.com/strblr/trpc-live In my projects in general I just like having queries that update from the server. SSE over HTTP/1 is also gonna be too limited. So either HTTP/2 SSE or websockets. With graphql I'm using websockets just for live queries.

Okay, I believe I can extend oRPC to support streaming responses for SSE/WebSocket (using a yield function). However, this functionality will be limited to stateful servers like Bun and Node.js, and won't be compatible with serverless environments such as Cloudflare Workers, AWS Serverless.

For now, my priority is to stabilize the current implementation of oRPC. I want to ensure the existing features are solid before moving forward with new additions.

[motopods]

The tRPC subscription alternative based on a streaming solution, in general, seems fine to me. However, tRPC uses a separate long-lived connection for each individual subscription message, which leads to hitting the 6-connection limit in HTTP/1.1 almost immediately. Perhaps oRPC could reuse a single SSE (Server-Sent Events) long-lived connection and achieve the functionality of dynamically subscribing to different messages through additional POST requests. This approach could simplify the design and eliminate the need to support WebSocket.

[dinwwwh]

The tRPC subscription alternative based on a streaming solution, in general, seems fine to me. However, tRPC uses a separate long-lived connection for each individual subscription message, which leads to hitting the 6-connection limit in HTTP/1.1 almost immediately. Perhaps oRPC could reuse a single SSE (Server-Sent Events) long-lived connection and achieve the functionality of dynamically subscribing to different messages through additional POST requests. This approach could simplify the design and eliminate the need to support WebSocket.

I think resuable connection for http1/SEE seem hard, because you it only allow you send request one-time. http2/sse or websocket seem a better solution

[dinwwwh]

It now available on @next version. SSE support without any additional configuration.