feat: support async iter as rpc result#20
Conversation
| post(serialize(<Response>{ t: 's', i: msg.i, r: iterRes, d: false, e: error }), ...extra) | ||
| } | ||
| if (msg.i) | ||
| return post(serialize(<Response>{ t: 's', i: msg.i, r: undefined, d: true, e: error }), ...extra) |
There was a problem hiding this comment.
I'd say we probably only return the d flag when it's not finished to save some bytes for regular calls. Maybe u for unfished or s for stream?
There was a problem hiding this comment.
Currently, d flag would be only posted when fn return result is iterable. In case of regular calls, it would be undefined. Is this u expect?
|
That's a very interesting idea, thanks for bringing this up! I will do a proper review a bit later. From a quick scan, my main concern right now would be how we handle the timeout or disconnection in middle of the iterations. |
|
For long-running tasks, whether iterable or not, it may need to implement a heartbeat mechanism to handle timeout or disconnection cases. I would prefer to do it in business code due to its complexity, keep birpc stay simple 👀. |
|
Looking forward to ur thoughts ~ @antfu |
|
I wonder if you would consider implementing this as a separate library or an integration on top of birpc? birpc is designed to be simple and lightweight, while the complexity of this PR goes a bit beyond the scope for such a rarely used feature. |
|
Thank you for your reply! First, I really love the API design of birpc, which offers a fantastic DX. I’d prefer not to reinvent the wheel. However, I find it challenging to handle multiple returns from a single RPC call under the current ping-pong mechanism. Perhaps you have a better approach in mind? I would love to hear your thoughts. The context here is that I'm building a browser extension that needs to stream OpenAI results from service worker and relay them back to the content script via RPC calls. IMO this type of usage is becoming increasingly common in the current AI era. I’m hoping to add this as a primitive feature to birpc, and I want to ensure it remains opt-in so it doesn't disrupt existing usage. |
|
Revising this idea again and I think it's probably out of scope of birpc. Thanks for your work on this, but sorry, I think it's better for you to create a separate lib or something on top of birpc. Thanks! |
Description
Currently, birpc can only handle result of rpc calling once, that make it hard to handle streaming multiple results (e.g. ReadableStream, Async Generator).
This pr check if fn result has
Symbol.asyncIterator, if ture, post the result sequencially and consume it on the other side.Linked Issues
Additional context