benpacker

I get segfaults all the time when using it with Bun and the new Node neo api. What’s your recipe, are you not getting these?

Does this have support for generators / streams, or any ideas how you'd do it? With LLMs that an increasingly large part of client/server communication.

I think crossing a language barrier here would be hard: you'd need a codegen step to compile the RPC spec to Typescript for the client-side DX and that would need take into account the full range of differences in serializability across the languages.

For cross-language RPC, I think we're still better sticking to a well defined system where the spec is data (OpenAPI, GraphQL, etc.) instead of the spec being code that only one side understands.

This seems really cool and I'd be happy to help (I'm currently a pgtyped + Kysely user and community contributor), and I see how this solves n+1 from promise pipelining when fetched "nested" data with a similar approach as Cap'n Web, but I don't we've solved the map problem.

If I run, in client side Cap'n Web land (from the post): ``` let friendsWithPhotos = friendsPromise.map(friend => { return {friend, photo: api.getUserPhoto(friend.id))}; } ```

And I implement my server class naively, the server side implementation will still call `getUserPhoto` on a materialized friend returned from the database (with a query actually being run) instead of an intermediate query builder.

@kentonv, I'm tempted to say that in order for a query builder like typegres to do a good job optimizing these RPC calls, the RpcTarget might need to expose the pass by reference control flow so the query builder can decide to never actually run "select id from friends" without the join to the user_photos table, or whatever.

Would love to see pics of the interior!

My understanding is that your first read is right and your current understanding is wrong.

The client sends over separate 3 calls in one message, or one message describing some computation (run this function with the result of this function) and the server responds with one payload.

This seems great and I'm really excited to try it in place of trpc/orpc.

Although it seems to solve one of the problems that GraphQL solved that trpc doesn't (the ability to request nested information from items in a list or properties of an object without changes to server side code), there is no included solution for the server side problem that creates that the data loader pattern was intended to solve, where a naive GraphQL server implementation makes a database query per item in a list.

Until the server side tooling for this matures and has equivalents for the dataloader pattern, persisted/allowlist queries, etc., I'll probably only use this for server <-> server (worker <-> worker) or client <-> iframe communication and keep my client <-> server communication alongside more pre-defined boundaries.

You can do with with trpc WebSocket transport

It’s the same - just saying it works in both.

I like it because I can do full stack development, including the database, with a single system level dependency (Bun).

Cloudflare + SSE with any substantial delay is a nightmare

All frontier multi modal LLMs can do this - there’s likely something lighter weight as well.

In my experience, the latest Gemini is best at vision and OCR

This is more of an HTMX native

It’s frustrating that this is necessary but it definitely makes sense, and I will probably add it to several projects soon.

Thanks for your hard work!

You can connect and run SQL, but there’s no built in support for versioning, testing, and rolling back DDL.