Integrate Serverless Background Jobs with Inngest
An Inngest skill for durable, event-driven background jobs and workflows - steps, sleeps, fan-out, and idempotency.
Why it matters
Leverage Inngest to build robust, event-driven serverless applications. This asset enables durable background jobs, complex workflows, and scheduled tasks without managing queues or workers.
Outcomes
What it gets done
Implement event-driven workflows and background jobs.
Utilize durable sleep and automatic retries for resilient execution.
Manage concurrency and idempotency for critical operations.
Deploy Inngest functions across various serverless platforms.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-inngest | bash Overview
Inngest Integration
An Inngest skill for durable, event-driven background jobs and workflows, with typed steps, durable sleep, fan-out, and idempotency keys. Use it for serverless background jobs, event-driven workflows, or scheduled functions built on Inngest, not for Redis queues, complex saga orchestration, or event sourcing.
What it does
This is an Inngest skill for serverless-first background jobs, event-driven workflows, and durable execution without managing queues or workers. Its core principles: events are the primitive that everything triggers from (not queues), each step's result is durably stored as a checkpoint, step.sleep calls are real durable sleeps rather than blocking a thread, retries are automatic but the policy is configurable, functions are just HTTP handlers deployable anywhere, concurrency limits are a first-class way to protect downstream services, idempotency keys prevent duplicate execution of critical operations, and fan-out (one event triggering many functions) is built in. A basic typed function in Next.js shows the core shape - client setup, a function with sequential steps and a durable sleep, and the serve handler:
// lib/inngest/client.ts
import { Inngest } from 'inngest';
export const inngest = new Inngest({
id: 'my-app',
schemas: new EventSchemas().fromRecord<Events>(),
});
// lib/inngest/functions.ts
import { inngest } from './client';
export const sendWelcomeEmail = inngest.createFunction(
{ id: 'send-welcome-email' },
{ event: 'user/signed.up' },
async ({ event, step }) => {
// Step 1: Get user details
const user = await step.run('get-user', async () => {
return await db.users.findUnique({ where: { id: event.data.userId } });
});
// Step 2: Send welcome email
await step.run('send-email', async () => {
await resend.emails.send({
to: user.email,
subject: 'Welcome!',
template: 'welcome',
});
});
// Step 3: Wait 24 hours, then send tips
await step.sleep('wait-for-tips', '24h');
await step.run('send-tips', async () => {
await resend.emails.send({
to: user.email,
subject: 'Getting Started Tips',
template: 'tips',
});
});
}
);
When to use - and when NOT to
Use this skill for serverless background jobs, event-driven workflows, step functions, durable sleep, fan-out patterns, concurrency control, or scheduled functions - covering frameworks (Next.js, Express, Hono, Remix, SvelteKit) and deployment targets (Vercel, Cloudflare Workers, Netlify, Railway, Fly.io). It explicitly routes adjacent needs elsewhere: Redis-based queues go to a bullmq-specialist skill, complex workflow orchestration with compensation goes to a temporal-craftsman skill, event sourcing/CQRS goes to an event-architect skill, and general infrastructure goes to an infra-architect skill. It ships a set of validation checks with fix actions - functions must have a unique ID and a serve handler, waitForEvent must have a timeout to prevent infinite waits, step.sleep should use duration strings like '1h' rather than milliseconds, and payment-related functions specifically must use idempotency keys.
Inputs and outputs
Input is an event and its typed payload; output is a durable, multi-step function execution - parallel steps via Promise.all, fan-out via step.sendEvent to trigger child functions instead of calling them directly, cron-scheduled functions (e.g. a daily digest fanning out to per-user send events), and idempotent webhook handlers keyed by an external event ID (e.g. Stripe's event ID) to prevent duplicate processing.
Who it's for
Developers building serverless background jobs, multi-step workflows, scheduled tasks, or webhook processing who want durable execution, automatic retries, and built-in fan-out without standing up and managing their own queue infrastructure.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.