technical debt/overhead
ik the Convex team just tells us to avoid adding technical debt/overhead, but in my use case, it means cutting down (3-15)x(batch.length) mutations/queries per expensive action (all of the actions are expensive, either calling a GPU endpoint/model provider). The technical debt in question is massive, as each function will highly likely require backtracking to the root function in case of change, or it can compromise auth. Am i being paranoid?
6 Replies
Sorry, I don't understand what you're asking here. is this a cost question?
yes
generally speaking teams just write whatever they want on convex, and if there's a performance or optimization problem we need to deal with once they actually have traffic, we just fix it as needed then
so I'd say don't avoid anything, just ship your code
hmm but theres an additional concern of latency, i tried doing it for one action and it shaved off latency by 100-150ms from 300ms avg
1. you can write your project in C++ using intel's DPDK or seastar from scylla folks and directly map the NIC and the disk into address space in your program. 2. other extreme -- vibe code your project using MIT scratch
everything else is in between
faster is cool, but it's all about fast enough
there's always more optimization available
I'm not trying to be pedantic or pithy, I'm only saying this b/c of the implication of convex's "advice" -- just clarifying
my advice is just ship and fix perf. or cost when it matters, and only as much as necessary
b/c making anything faster ahead of time, the well is infinitely deep
got it, i think i'll jus make those actions use postgres db on fly or sm, it will simplify a lot of stuff