Introduction

The concept of background jobs and expecially long-running jobs within web applications is not a foreign one, indeed a lot of software utilizes various solutions and code snippets and it works. Within the JS ecosystem and Web Development in particular, tools for this are quite scarce, if you didn't want to go the manual route (of doing everything yourself), you didn't have much options. Till Trigger.

Breakdown

What's Trigger.dev?

Trigger.dev is a TypeScript framework for background jobs. It allows you to integrate smart webhooks, APIs and long-running tasks into your application with ease.

I was fortunate to stumble upon Trigger in my quest to build the ultimate Remix PWA stack 👀, and it has been a tool I have been using ever since in a lot of projects.

What's special about it?

There are a lot of things about Trigger I am yet to discover myself, but I would highlight some of my main pros for it.

• Longevity: This means long. In other words, it's support for long-running tasks. I am a fan and advocate of more Progressive Web Apps (PWAs) and one core thing about PWAs is long-running tasks. Tasks that can run even when the app is closed. Trigger is a fantastic complementary tool for that on the server, keeping tasks alive for up to a year if needed!

• Cron Jobs: A cron can be simply defined as a task that runs at intervals, think of JavaScript's setInterval on a larger scale. Running Cron Jobs has never been easier with Trigger, truth be told I haven't used it yet (no cause for it yet) but going through the API earlier and comparing it with how I currently handle cron jobs (on some boring server with quite a lot configuration), I am sold in this aspect.

• Integrations: This is my biggest takeaway from this all, Trigger doesn't just exist in its bubble, it's a platform that focuses on extensibility. Telegram, WhatsApp, OneSignal, Resend, Slack and a lot more can be connected with just a few lines of code and you don't have to worry about it. Deploy it and it runs forever!

• Self-Hosting: Edited this article and can't believe I forgot to add this, self-hosting option. As a massive fan of Fly.io and self-deployment (Vercel & Serverless has disappointed me enough), the option to host this incredible tool is a big win for me.

• Open-Source: Open-Source...yayyy 🎉! Seriously though, Open-Source Software (OSS) is to be celebrated and this is one that also deserves recognition and praise.

Trigger.dev & Remix

Now to the actual topic, Remix and Trigger. What makes them so perfect in my opinion? I will be discussing a few reasons why that is so (my opinions).

First of all, Remix Resource Routes. A resource route in a Remix application is a route (your normal route) that doesn't return a component. Like an API endpoint. If you've written a controller with Express, that's your app.get() handler, or @Controller annotation in SpringBoot. Trigger in Remix takes advantage of this in Remix and builds itself within a single resource route (mostly /api/trigger) without disrupting your app flow. In short, Trigger builds itself as a part of your app, not a large service you have to plug in a few env keys and download a lot of packages to get it to work.

As a continuation of that, other Resource routes can integrate seamlessly with Trigger SDK, want to send an email? Create a send-email job in Trigger, create a send-email route and within its action, run (trigger) the job. Need to tell a customer their order is on the way via WhatsApp? No worries, that can be easily handled by creating another job and triggering it at the right time. Creating powerful and smart webhooks in Remix has never been easier!

I work with Push API a lot as a part of the Remix PWA ecosystem and one thing that must be factored in is consistency; whether offline or online, app opened or closed, the push must be sent and Trigger is an easy tool that helps with that.

The last point I would make for Remix & Trigger is Trigger Events. Events are triggers that react to an event within your application or another job. I think the best way to visualize this is with examples, if you are creating a fund-raising application for example, and you want to tweet every milestone hit on the user's Twitter account, you simply have an event that triggers whenever the milestones are hit and tweet, tweet! You are now tweeting based on set goals from within your application without extra input.

There are more I can go into like scheduled jobs and resumability which help ensure consistency within your job runs so you never run the same thing twice. But this would be all 😉

Conclusion

There's a lot for me to discover within Trigger, I am still at the top layer and it's impressive. Can't wait to dive deeper and see what more is possible with it. I will be writing more about Trigger within the coming months about my discoveries and maybe a trick or two, till then have fun and keep learning 💪. Till next time 👋!