watching a custom endpoint, rather than an api endpoint
I have a pretty complex endpoint in prisma. It's almost 500 lines of code and multiple queries.
Is the standard practice to just dump this code into a file with all the other queries/mutations within the convex folder?
Or is it possible to have some organisation and watch an endpoint instead?
Thanks
23 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
yes, i believe you would want to copy the code into a file in your convex folder (it can be a new file, or you can add a directory for it, or whatever structure you want). then expose it via an exported
query, and use that with useQuery to watch for changesDoes the limitation for the centralised code lie with the server or the client library?
@Paul what's the difference between an api endpoint and a custom endpoint?
The centralization (of being in a
file somewhere inside the convex directory) just applies to the top-level mutation/query/action, that can be one line that calls your function(s) imported from where where else
I'm butting against the design constraint of the current paradigm. For me it breaks the DX of my current codebase. I have react, encore (ts backend), restate, rust. And although it's a poc with 1 app. I will be porting 9 others across and it will be a horrible experience having all 10 apps be centralised for the database.
Coming from prisma. I can access the prisma singleton and then the tables and do queries/mutations insitu. But convex, I can't.
Why not?
What does centralized mean here, that they all share a schema file?
I meant that all the files relating to the database have to live in /convex
Got it, yeah indeed you have to expose your functions in (directories in) the convex directory
but that doesn't need to be much code, it can be just the routing
But coming from other paradigms, this is really limiting as normally database functions live adjacent to the code that's being worked on.
As in separate repos?
we recommend a single repo because code deploys happen atomically, everything gets deployed together. But you can split the code up however you want
see https://docs.convex.dev/understanding/best-practices/other-recommendations#use-helper-functions-to-write-shared-code for more on helper functions
Other Recommendations | Convex Developer Hub
{/ This page was previously the Best Practices page which has been rewritten /}
Or you can re-export your mutations etc. from the file in the convex directory where you want them exposed
Maybe could you describe another way this could work, to help understand what you want?
An example, these are all the current functions.
With other paradigms that I have used. All I have needed to do was something like and that's it. Now with convex there's more congnative load. i.e what query to use, where it's located (within convex) and where it lives (within the directory structure) and what's happening in the handler.
With other paradigms that I have used. All I have needed to do was something like and that's it. Now with convex there's more congnative load. i.e what query to use, where it's located (within convex) and where it lives (within the directory structure) and what's happening in the handler.
Running your logic in small pieces like this means you're losing transactions
I thought there weren't transactions per se? 🤔
we'd recommend implementing what logic you can in convex so you can get transactional guarantees, ie orm.findFirst sounds very low-level for a Convex endpoint
It's all one-shot transactions, code called in a query or mutation runs in a transaction
Right, I just mention the syntax comparison. with other solutions it's insitu, you can code do the query and keep on coding.
But with convex, it's now having code located elsewhere and running inside a handler. So any code that modifies the payload now has to be carried along to the handler. It cannot be insitu with the other business logic. Again, the DX suffers.
Ok I get it! Yeah it's slicker when you define all this logic in convex functions and present a higher level interface to functions outside, so it's all in one place. But some code can't run inside convex (like browser React code) so has to be in a different file, and that's a pain?
And you have backend code running on another server, so it's more layers
Today I'd recommend moving that server logic into Convex, where you'll get transactions and you won't have to jump around. But other stuff is interesting to think about
There are a few things I can imagine you want, of these sounds interesting?
1. wish queries/mutations could be constructed on another server, then that code send in to convex when the query is run
2. wish convex functions could be defined outside of the convex folder, in a file next to code that runs on another server
3. wish code could be written inline with frontend or other server code, then would be extracted by a bundler and sent in to convex at deploy time
In this instance, it's only 1 domain (backend ts) that has the issue where there's a lot of business logic in 1 place and co-mingled with the database logic. Pulling that out into convex is going to be a real chore. Hence the question on whether the react useQuery can hit an endpoint rather than the api.
What's an endpoint, code on another server?
useQuery only works with convex query functions because it subscribes to them
I don't know another way of phrasing it. But isn't it an http endpoint at some layer in the convex react library? I thought maybe there's a way of replicating that?
I would move this into convex, and make the backend ts as small as possible or get rid of it. Helpful to hear this is painful. The reactive subscriptions implementation isn't possible in another runtime, so browser code that wants reactivity needs to talk directly to the convex backend.
If you want something similar but without the reactivity, you can try TanStack Query—it's like useQuery from Convex, but is more general (works with any http endpoints) because it's not reactive. But the most convex-y way to do this is to move all that backend ts into the convex backend.
re
backend logic commingled with database logicconvex is most convenient when it does both of these
It's a shame that the current paradigm just scans the single convex directory. It would be nicer if there was a v2 which scanned the codebase for convex queries and mutations and then transpiled that up to the server. That way, the benefit of having queries/mutations adjacent to code would be there.
But otherwise, I appreciate the responses and I will have a think on what to do next.