Why Trigger.dev?
- Long-running, reliable tasks: Write typical async code, no unfamiliar syntax to learn.
- Automatic retries, concurrency, and scheduling: Configure your tasks in your
trigger.config.ts
file. - Local dev that matches prod: Run and debug jobs locally and view everything in the dashboard.
- Scales with you: Deploy your tasks to Trigger.dev Cloud with no infrastructure to manage. Or self-host.
How to migrate to Trigger.dev
Step 1: Set up Trigger.dev
- Create an account at Trigger.dev Cloud.
- Create an organization and a project.
- Install the CLI and run the local dev server:
Step 2: Convert your Mergent task to a Trigger.dev task
Example: Basic Mergent Task
Here’s a simple Mergent task that processes an image:processVideo.ts
The same task in Trigger.dev
trigger/processVideo.ts
- In Mergent, your task is an HTTP handler; in Trigger.dev, it’s a
task()
function that gets deployed on a managed worker for you. - Trigger.dev gives you a typed payload, not a raw HTTP request.
- No need to handle HTTP status codes or errors—Trigger.dev handles retries and failures for you.
- You can export multiple tasks from a single file.
Scheduled task example
Mergent scheduled task: You’d set up a schedule in the Mergent dashboard to hit your HTTP endpoint on a cron.dailyReport.ts
trigger/dailyReport.ts
- In Trigger.dev, you can define the schedule right in your code (or attach it in the dashboard).
- No need to set up HTTP endpoints for each scheduled job.
Triggering your tasks
Mergent: You’d trigger a task by calling the Mergent API, specifying the URL and payload.- You can trigger tasks immediately, or add logic inside the task to delay execution (using
wait.for
orwait.until
). - No need to expose HTTP endpoints for every task.
- Mergent tasks are HTTP handlers; Trigger.dev tasks are functions that get deployed on a managed worker for you.
- Scheduling and retries are built-in and configured in code.
- Trigger.dev tasks are type-safe, and easy to debug.
- You don’t need to manage endpoints or handle HTTP manually.