Debounce expensive Convex operations like LLM calls and metrics computation to run only after periods of inactivity, reducing costs and load.
npm install @ikhrustalev/convex-debouncerA server-side debouncing component that prevents expensive operations from running too frequently by waiting for periods of inactivity. It provides three debouncing modes (sliding, fixed, eager) to handle different scenarios like LLM calls, metrics computation, or batch processing. The component schedules functions to run after configurable delays and automatically manages cancellation and rescheduling based on incoming triggers.
Convex Debouncer lets you wrap expensive operations like AI API calls or complex calculations so they only execute after a specified period of inactivity. This prevents costly redundant operations when users type rapidly or trigger multiple updates in succession.
Use Convex Debouncer to batch LLM API calls by delaying execution until user input stabilizes. The debouncer cancels pending operations when new requests arrive, ensuring only the final input triggers the expensive LLM processing.
Convex Debouncer reduces backend load by grouping expensive computations like analytics calculations or data aggregations. Instead of running on every database change, operations wait for quiet periods to execute efficiently.
Convex Debouncer cancels previous pending operations when new requests arrive within the debounce window. Only the most recent operation executes after the specified delay period, preventing race conditions and redundant processing.
Yes, Convex Debouncer allows you to set custom delay periods per operation. You can use short delays for UI updates and longer delays for expensive operations like LLM calls or complex database aggregations.
Convex Debouncer works with any Convex backend operation including mutations, actions, and queries. It provides a wrapper that manages the debouncing logic while preserving the original function signatures and return types.
Convex Debouncer preserves error handling from your original functions. Failed operations throw errors normally, and you can implement retry logic or error boundaries as needed without affecting the debouncing mechanism.