I generally agree that the .map() trick doesn't actually replace GraphQL without some sort of server-side optimizations to avoid turning this into N+1 selects.

However, if your database is sqlite in a Cloudflare Durable Object, and the RPC protocol is talking directly to it, then N+1 selects are actually just fine.

https://www.sqlite.org/np1queryprob.html

▲

ryanrasti 4 days ago | parent | next [-]

Agree, and to add, from what I see, the main issue is that server-side data frameworks (e.g., ORMs) aren't generally built for the combination of security & composability that make them naturally synergize with Cap'n Web. Another way to put it: promise pipelining is a killer feature but if your ORM doesn't support pipelining, then you have to build a complex bridge to support them both.

I've been working on this issue from the other side. Specifically, a TS ORM that has the level of composability to make promise pipelining a killer feature out of the box. And analagous to Cap'n Web's use of classes, it even models tables as classes with methods that return composable SQL expressions.

If curious: https://typegres.com/play/

▲

benpacker 4 days ago | parent | next [-]

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.

	▲	ryanrasti 3 days ago \| parent [-]
		> but I don't we've solved the map problem. Agreed! If we use `map` directly, Cap'n Web is still constrained by the ORM. The solution would be what you're getting at -- something that directly composes the query builder primitives. In Typegres, that would look like this: ``` let friendsWithPhotos = friendsPromise.select((f) => ({...f, photo: f.photo()}) // `photo()` is a scalar subquery -- it could also be a join ``` i.e., use promise pipelining to build up the query on the server. The idea is that Cap'n Web would allow you to pipeline the Typegres query builder operations. Note this should be possible in other fluent-based query builders (e.g., Kysely/Drizzle). But where Typegres really synergizes with Cap'n Web is that everything is already expressed as methods on classes, so the architecture is capability-ready. P.S. Thanks for your generous offer to help! My contact info is in my HN profile. Would love to connect.

▲

kentonv 4 days ago | parent | prev [-]

That is actually pretty interesting!

Have you considered making a sqlite version that works in Durable Objects? :)

	▲	ryanrasti 3 days ago \| parent [-]
		Thanks, Kenton! Really encouraging to hear you find the idea interesting. Right now I'm focused on Postgres (biggest market-share for full-stack apps). A sqlite version is definitely possible conceptually. You're right about the bigger picture, though: Cap'n Web + Typegres (or a "Typesqlite" :) could enable the dream dev stack: a SQL layer in the client that is both sandboxed (via capabilities) and fully-featured (via SQL composability).

▲

qcnguy 4 days ago | parent | prev [-]

I wonder if there's a way to process the RPC encoding inside a stored procedure, using the various JS-in-DB features out there.