Co locating queries in client side code
Co-locating queries in client-side code?
First of all -- congrats on the v1 launch! Love the product and have been using it for side projects.
One of the things that's a bit of a pain for me with Convex is having to switch between files when I'm building an app -- needing to jump between the convex directory for writing queries as well as the react component where I'm writing the app code. A fair number of my query functions are specific to the react component calling them.
Is there ever a world where it'd be possible to write query functions that are co-located w the client side component? And then in the packaging step with a bit of magic, pulling those functions out, uploading to server, and replacing them with a stub in the client package, so execution still happens server side.
Usability-wise, this would be similar to Facebook's Preparable XHP (described a bit here, but no great external-to-Facebook record: https://softwareengineeringdaily.com/wp-content/uploads/2019/05/SEDFB06-Nick-Schrock.pdf, p17), or colocating GraphQL queries w the relevant react function (similar to Apollo).
7 Replies
Very cool idea. Not possible at the moment.
Definitely some bundling magic to think through, and there are drawbacks to having server code scattered, but it's certainly a user experience that lets you put the code where you want - near the callsites that care the most.
For now, you may be able to get a lot of the benefit from reproducing your directory structure in parallel in the convex directory. I know it's not quite as good, but it might get you some of the way with what's there now.
And use cmd-click on the api object to hop to the server code , then ctrl-minus to hop back!
So far we've been following the "no magic" school here (well put in https://youtu.be/uXCipjbcQfM?t=1099 by Rich Harris) — you describe exactly how we'd need to do it, it'd be a bundler extension similar to what Next.js does with getServerSideProps
There's absolutely a world where we can do this, but it will require integration with the metaframework you're using. Right now we're excited about providing basic, clear functionality that can be used in any framework — we provide React bindings, but not much integration specific to Next.js or Remix etc.
One reason I think the cmd-click work was worth it (pre-1.0 customers will remember the pain of the migration) was that we don't plan to do code co-location soon, so jumping back and forth quickly is important.
Yeah totally -- it'd be tricky to get completely right. With an intermediate representation of queries (like GraphQL), there's no real magic happening, but I imagine it's hard to do w JS functions cleanly for all the reasons the talk describes. (And I definitely don't have the answer myself!) Definitely not a blocker, just figured I'd throw it out there as a thought I had since I was noticing the 1:1 query function to react component pattern in my own code.
That said we can do this! It requires coordination with the bundler, so if you have a favorite framework it'd be helpful to hear. This might be a community-led thing we could make smaller API additions to support, because we absolutely want to provide the primitives to make powerful integrations like this possible.
The GraphQL (or SQL, if you really lock down your permissions) approach is more feasible, and GraphQL could be done sooner. GraphQL support isn't specifically planned but it's something better understood as you point out.
Ah yeah I think I'm using vite w react, but honestly I'm a bit rusty on all the different frameworks/bundlers right now. Back in the day everyone used webpack as a bundler, but maybe nowadays there are a bunch to support. If there was support on one blessed stack, would probably move my project to it.
This could also be done as a Vite/Rollup plugin too, that's may be simpler — just concerned it wouldn't compose with popular stacks folks use so would want to make sure the interest is there.
Yup, makes sense!