convex-best-practices
Offers architectural advice and standardized patterns for building scalable applications on the Convex platform.
Install
mkdir -p .claude/skills/convex-best-practices && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2943" && unzip -o skill.zip -d .claude/skills/convex-best-practices && rm skill.zipInstalls to .claude/skills/convex-best-practices
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guidelines for building production-ready Convex apps covering function organization, query patterns, validation, TypeScript usage, error handling, and the Zen of Convex design philosophyKey capabilities
- →Organize functions by domain
- →Implement argument and return validation
- →Optimize queries using indexes
- →Handle errors with ConvexError
- →Apply optimistic concurrency control
How it works
The skill provides patterns for Convex development, including schema-driven data modeling, reactive query design, and idempotent mutation strategies.
Inputs & outputs
When to use convex-best-practices
- →Structuring a new Convex backend
- →Optimizing database queries for performance
- →Implementing error handling for database writes
About this skill
Convex best practices
The patterns that keep a Convex app fast and correct in production. The rule that matters most: read as little as possible before you write, and read through an index.
Rules that matter most
- Validators on every function.
argsandreturns, withreturns: v.null()when nothing comes back. - Indexes, not filters. Every table read goes through
withIndexagainst an index inconvex/schema.ts. - Idempotent mutations. Return early when the document is already in the target state so retries are safe.
- Patch without reading first.
ctx.db.patch(id, fields)throws if the doc is missing; you rarely need the old value. Promise.allfor independent writes. Do not await them one at a time.- Schedule
internal.*only. Crons andctx.schedulerrun without a client, so public targets skip auth. - Thin wrappers. Auth and business logic live in plain helpers that take
ctx. ConvexErrorfor anything a client should read. PlainErrormessages are redacted in production.
// convex/tasks.ts
import { query, mutation } from "./_generated/server";
import { v, ConvexError } from "convex/values";
const taskValidator = v.object({
_id: v.id("tasks"),
_creationTime: v.number(),
userId: v.id("users"),
title: v.string(),
status: v.union(v.literal("open"), v.literal("done")),
});
export const listOpen = query({
args: { userId: v.id("users") },
returns: v.array(taskValidator),
handler: async (ctx, args) => {
return await ctx.db
.query("tasks")
.withIndex("by_user_and_status", (q) =>
q.eq("userId", args.userId).eq("status", "open"),
)
.order("desc")
.take(100);
},
});
export const rename = mutation({
args: { taskId: v.id("tasks"), title: v.string() },
returns: v.null(),
handler: async (ctx, args) => {
if (args.title.trim().length === 0) {
throw new ConvexError("Title cannot be empty");
}
await ctx.db.patch(args.taskId, { title: args.title.trim() });
return null;
},
});
The schema behind that index:
tasks: defineTable({
userId: v.id("users"),
title: v.string(),
status: v.union(v.literal("open"), v.literal("done")),
})
.index("by_user", ["userId"])
.index("by_user_and_status", ["userId", "status"]),
Name indexes after their fields in order, and query fields in that same order.
OCC and write conflicts
Convex runs mutations under optimistic concurrency control. A mutation records what it read. If another mutation commits a change to any of that data first, Convex retries it. After enough retries it fails and the client sees a write conflict error.
Conflicts come from three places:
- Two mutations writing the same document at once: counters, "last seen" fields, a shared settings doc
- A mutation that reads a wide range, such as
.collect()on a whole table, so any change in that range conflicts with it - A client calling the same mutation faster than it can commit: typing, dragging, polling
Idempotent and patch first
export const complete = mutation({
args: { taskId: v.id("tasks") },
returns: v.null(),
handler: async (ctx, args) => {
const task = await ctx.db.get(args.taskId);
if (!task || task.status === "done") {
return null;
}
await ctx.db.patch(args.taskId, { status: "done" });
return null;
},
});
export const reorder = mutation({
args: { itemIds: v.array(v.id("items")) },
returns: v.null(),
handler: async (ctx, args) => {
await Promise.all(
args.itemIds.map((id, index) => ctx.db.patch(id, { order: index })),
);
return null;
},
});
The read in complete is fine: one document, early exit. reorder never reads at all.
Event records instead of counters
A counter field on one document is the most common conflict source. Insert one row per event and count in a query.
export const trackView = mutation({
args: { pageId: v.id("pages") },
returns: v.null(),
handler: async (ctx, args) => {
await ctx.db.insert("pageViews", { pageId: args.pageId });
return null;
},
});
export const viewCount = query({
args: { pageId: v.id("pages") },
returns: v.number(),
handler: async (ctx, args) => {
const views = await ctx.db
.query("pageViews")
.withIndex("by_page", (q) => q.eq("pageId", args.pageId))
.collect();
return views.length;
},
});
Once the event table gets large, move the count to the @convex-dev/sharded-counter or @convex-dev/aggregate component instead of collecting rows.
Dedup windows
For heartbeats and presence, skip the write when the last one was recent. Pair it with a client side debounce: 300 to 500 ms for typing, a few seconds for heartbeats.
const DEDUP_MS = 10_000;
export const heartbeat = mutation({
args: { sessionId: v.string(), path: v.string() },
returns: v.null(),
handler: async (ctx, args) => {
const now = Date.now();
const existing = await ctx.db
.query("sessions")
.withIndex("by_session", (q) => q.eq("sessionId", args.sessionId))
.unique();
if (!existing) {
await ctx.db.insert("sessions", { ...args, lastSeen: now });
return null;
}
if (existing.path === args.path && now - existing.lastSeen < DEDUP_MS) {
return null;
}
await ctx.db.patch(existing._id, { path: args.path, lastSeen: now });
return null;
},
});
Put hot fields such as lastSeen in their own table so those writes do not conflict with reads of the stable document.
Pagination over collect
.collect() on an unbounded table gets slower every day and eventually hits read limits. Paginate anything a user can grow. postValidator below is a hoisted document validator like taskValidator above.
import { paginationOptsValidator } from "convex/server";
export const feed = query({
args: { userId: v.id("users"), paginationOpts: paginationOptsValidator },
returns: v.object({
page: v.array(postValidator),
isDone: v.boolean(),
continueCursor: v.string(),
splitCursor: v.optional(v.union(v.string(), v.null())),
pageStatus: v.optional(
v.union(v.literal("SplitRecommended"), v.literal("SplitRequired"), v.null()),
),
}),
handler: async (ctx, args) => {
return await ctx.db
.query("posts")
.withIndex("by_user", (q) => q.eq("userId", args.userId))
.order("desc")
.paginate(args.paginationOpts);
},
});
On the client, usePaginatedQuery from convex/react drives loadMore.
No Date.now() in queries
Queries must be deterministic so Convex can cache them and rerun them when data changes. Pass time from the client, or store a status field that a scheduled mutation updates.
export const dueBefore = query({
args: { userId: v.id("users"), now: v.number() },
returns: v.array(taskValidator),
handler: async (ctx, args) => {
return await ctx.db
.query("tasks")
.withIndex("by_user_and_due", (q) =>
q.eq("userId", args.userId).lt("dueAt", args.now),
)
.take(100);
},
});
Mutations and actions may call Date.now().
ESLint plugin
@convex-dev/eslint-plugin catches the old function syntax, missing arg validators, .filter() in queries, and top of the hour crons at lint time. Install it in every Convex project.
npm i --save-dev @convex-dev/eslint-plugin
// eslint.config.js
import { defineConfig } from "eslint/config";
import convexPlugin from "@convex-dev/eslint-plugin";
export default defineConfig([...convexPlugin.configs.recommended]);
Open references/eslint-setup.md when you need the full rule list, the TypeScript aware config, package scripts, or a custom convex/ directory.
Common mistakes
| Mistake | Why it breaks | Do instead |
|---|---|---|
.filter() on a table query | Reads every row, then drops most | Add an index, use withIndex |
.collect() on an unbounded table | Slower every day, hits read limits, wide OCC footprint | .paginate() or .take(n) |
| Read, compute, then patch a shared doc | Two clients read the same version and both write | Patch directly, or split into event rows |
| Counter field incremented per event | Every increment conflicts with every other | Event records or a sharded counter component |
| Mutation without an early return | Retries and double clicks apply the change twice | Check state, return null if already done |
Sequential await on independent writes | Slow, and each read widens the conflict window | Promise.all |
Date.now() in a query | Result changes every ms, cache and subscriptions break | Pass now as an arg |
Scheduling api.* | Public function runs with no client auth | Schedule internal.* |
Plain Error for user messages | Redacted to "Server Error" in production | ConvexError |
| Business logic inside the handler | Untestable, duplicated across functions | Plain helper that takes ctx |
Checklist
- Every function has
argsandreturns - Every table read uses
withIndex, never.filter() - Indexes are named after their fields in order
- Mutations return early when the doc is already in the target state
- Mutations patch without a prior read unless the old value is needed
- Independent writes run under
Promise.all - High frequency counts use event rows or a counter component
- Unbounded lists use
.paginate() - No
Date.now()inside a query - Scheduled and cron targets are
internal.* -
@convex-dev/eslint-pluginis installed andnpm run lintpasses
Docs
When not to use it
- →When the project does not use the Convex platform
- →When the user requires non-TypeScript backend logic
Prerequisites
Limitations
- →Strictly follows Convex-specific runtime constraints
- →Requires adherence to defined linting rules
How it compares
It provides specific architectural patterns and linting rules for Convex rather than general backend development advice.
Compared to similar skills
convex-best-practices side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| convex-best-practices (this skill) | 3 | 7mo | Review | Intermediate |
| bullmq-specialist | 25 | 8mo | No flags | Intermediate |
| agent-dev-backend-api | 3 | 7mo | No flags | Intermediate |
| convex-functions | 4 | 7mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by waynesutton
View all by waynesutton →You might also like
bullmq-specialist
davila7
BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.
agent-dev-backend-api
ruvnet
Agent skill for dev-backend-api - invoke with $agent-dev-backend-api
convex-functions
waynesutton
Writing queries, mutations, actions, and HTTP actions with proper argument validation, error handling, internal functions, and runtime considerations
supabase-known-pitfalls
jeremylongshore
Execute identify and avoid Supabase anti-patterns and common integration mistakes. Use when reviewing Supabase code for issues, onboarding new developers, or auditing existing Supabase integrations for best practices violations. Trigger with phrases like "supabase mistakes", "supabase anti-patterns", "supabase pitfalls", "supabase what not to do", "supabase code review".
convex-component-authoring
waynesutton
How to create, structure, and publish self-contained Convex components with proper isolation, exports, and dependency management
add-league
osrs-leagues
Add a new OSRS league season to the Discord bot. Use when: adding a league, creating a new league, new league season, new league type. Creates model, migrations, updates League type, config, and commands.