really liked the convex.sucks podcast
really liked the convex.sucks podcast one more concern I have is this;
Convex bills per function call and architecture sort of forcing for nested calls e.g. I have an action that
1) runs a query to get current user then
2) runs a query to get users subscription details then
3) runs a mutation to create; lets say atodo item then
4) runs a mutation to update user's todo item quota
which means 5 calls for 1 main user action
for every other case e.g. host your api in vercel, lambda, etc this is still 1 function call
are there any plans to optimize this?
5 Replies
hey @Oren !
it's true that on AWS lambda, you'd only pay for the top-level action call. however, your AWS lambda would still need to talk to a database (say, DynamoDB) to implement the behavior for these queries and mutations.
so, the per-function call cost for queries and mutations on convex is more analogous to the read request units and write request units on DynamoDB (https://aws.amazon.com/dynamodb/pricing/on-demand/#.E2.80.A2_Read_and_write_requests).
that said, if you'd like to decrease your function call costs, you could combine (1) to (4) into a single mutation that reads all the data you'd want in your action, performs the writes, and then returns the reads.
Amazon Web Services, Inc.
Amazon DynamoDB Pricing for On-Demand Capacity
Learn more about Amazon DynamoDB's pricing for on-demand capacity mode.
heh jinx @lee 🙂
yeah, I guess 1 mutation that calls an action (because i have an http call in between 3 to 4) does solve the problem but kind of forces to write repetitive code because 1-4 mutation and queries I have are re-usable anywhere else atm. Anyways would love to see some scaled app pricing examples as mention in the podcast 👍
oh mutations can't call actions 😦
so 1 action that calls 1 mutation + http call is the most optimal way I can see now
@Oren mutations can schedule actions, but no -- they can't invoke and use the results of actions
another note re: all these function calls
we're about to "fix" our plans soon
which means current pro, we're actually really happy with
but it will probably be called "Launch"
very few teams run into problems when they're, say, developing with the pro plan
they in practice aren't using all 25M function calls a month (they're much more likely to use all their built-in database bandwidth)
but, once they really start getting adoption
they need a different plan
that plan doesn't exist yet, and it will be called "Scale"
(we're stealing this from Neon. Great names.)
Scale makes function calls way cheaper
but charges you for runtime inside mutations/queries
that way (a) as you optimize your queries/mutations you get a cost benefit [since it's clearly cheaper for us to run]; and (b) in particular, cache hits are very cheap, since they take 0ms inside javascript. they're basically rust-only
for busy sites, this can make usage-based pricing dramatically cheaper, and give you more control over your own destiny as you optimize
the "platform fee" (aka seat fee) will likely be higher, however. b/c at that point, the productivity benefits per engineer are pretty obvious and teams don't really mind paying more on that dimension.
for scaling/adopting sites, net-net their bill goes down in this scenario, and also: the "future math" on success seems a lot clearer and more flexible than the current simple "function call" pricing
but the more billable items we add to plans, the more people have to be expert at convex to like/understand their charges. which is why we sought to keep the first paid plan (pro) pretty simple, and hide a lot of different things inside a vague container "function calls"
Thank you Jamie this gives me more confidence going all in on convex 👍