Show HN: Trigger.dev V2 – a Temporal alternative for TypeScript devs | Hacker News Reader

Show HN: Trigger.dev V2 – a Temporal alternative for TypeScript devs

trigger.dev

172 pointseallam39 comments

Back in February, we posted a Show HN about building a “developer-first open source Zapier alternative” (https://news.ycombinator.com/item?id=34610686). This was v1 of Trigger.dev.

During the months since, we’ve gathered a lot of feedback from early users and realized that what developers actually wanted was more like an easier-to-use Temporal with integrations.

Here’s what we’ve learned so far:

- Serverless timeouts make it hard for anyone to write reliable background jobs. So our current product makes that easy for Next.js and other full-stack React frameworks. Long-running server support is coming soon.

- We simplified the architecture to make it far easier to self-host. This was the most common comment in our previous Show HN.

- We made it much easier to contribute to. You can now add new API integrations for any service we don’t already support. Either publicly (we appreciate PRs) or privately in your existing codebase.

We’re open about what we’re building (https://trigger.dev/changelog) and what we’re planning on doing next (https://trigger.dev#roadmap) as we believe community feedback ensures that we’re solving real problems.

So here’s where we’re at, and where we’re headed:

  [x] Easy self-hosting.
  
  [x] Serverless. Long-running Jobs on your serverless backend.
  
  [x] Integration kit. Build your own integrations, or use ours.
  
  [x] Bring-Your-Own-Auth. You can now authenticate integrations as your users.
  
  [x] Dashboard. View every Task in every Run.
  
  [x] Cloud service. No deployment required.
  
  [x] React hooks. Easily update your UI with Job progress.
  
  [x] React frameworks. Support for Next.js, Astro, Remix, Express.
  
  [ ] More frameworks. Support for SvelteKit, Nuxt.js, Fastify, Redwood.
  
  [ ] Background functions. Offload long or intense tasks to our infrastructure.
  
  [ ] Long-running servers. Use Trigger.dev from your long-running backend.
  
  [ ] Polling Triggers. Subscribe to changes without webhooks.
  
  [ ] And lots more…

I’d love to hear your thoughts on background jobs. Have we missed anything off the list? What should we be building next?

https://github.com/triggerdotdev/trigger.dev

Open articleView on HN

I moved from n8n to trigger.dev a month ago. Maintaining all the workflows in GUI was just too time consuming and difficult. I already use NextJS for my app, so switch to trigger.dev was easy, not maintaining and making changes my workflows in IDE takes about 80% less time. So far I am very happy with my decision to switch.

My initial thought when opening your website was that this was a job queue, like BullMQ. Not a "link things together like IFTT/Zapier/N8N but in code" platform. I don't think I'd use "Background Jobs framework" to describe what you're building, as that term has very different associations. Am I right in saying this is like BullMQ, except with integrations? If so, I'd focus more on the integration part of your marketing.

That's really interesting. What associations do you have with "Background Jobs framework"?

Quite a lot of our customers are using us instead of Temporal. Not for linking stuff together use cases.

Temporal calls itself a “Durable execution platform”, which I think emphases the persistence aspect of a message queue. I remember Cadence which is Temporal’s predecessor called itself a “workflow orchestration framework”. I think it’s a better term.

Just a background job queue library basically. Maybe with a fancy dashboard. That was my first impression.

You could also use Netflix Conductor which has typescript support and all the features listed here and more.

+1 to this. Conductor is a far better experience.

Coming to Next.js from Laravel, being able to hand things off to a long running worker is one of the things I missed the most. We're currently handling this with a non-ideal solution and will definitely check Trigger.dev out when you launch that feature.

Great, you can subscribe to updates on our discussion here: https://github.com/triggerdotdev/trigger.dev/discussions/400

We'll be updating it as we make progress and open it up for early testers.

May I ask what made you to switch from Laravel to Next.js?

Would like to know this as well. I switched from my last company’s WordPress app over to our Laravel side of things (with Vue/Inertia on the front end) and I really liked it. I’ve heard of Next.js here and there but seeing in the context of “switched from Laravel” I’m very curious.

I won't use this because of the weird way of framework integration.

Just give pure api call, instead of forced convention on file system level.

Because i don't use any of "popular" frameworks, that means i have no integration ? No.

I've been using Firebase functions and Firebase function cron jobs for this purpose... but it's definitely a roll-your-own situation.

This project could go so many different ways and solve a bunch of my problems.

Part of the inspiration for this was Firebase functions. We used them extensively on a previous project with their Firestore triggers. There's a lot to like about them but it was a messy development experience, especially the deployment process (although this was a few years ago).

I have been using it for my new project. it's really gold, because I don't need to run another instance of NestJS for the background jobs.

I think this really hits the sweet spot. Been looking for a product just in this space for a while!

- Types + IDE > UI/WYSIWYG

- Integrations

- Long running workflows

- "Serverless"

How does it compare to windmill.dev?

Our focus is on writing jobs in your existing codebase. That means you use your existing development workflow (code editor, version control, etc) and can access your database and existing code easily.

I'd also say that Windmill, and other similar tools like Airplane, are more focused on internal tools. Building internal admin tools and related workflows.

Our users are building some internal tools but also core parts of their product that involve user interaction.

Founder of windmill here.

You can, and that's the main workflow for most users, use your code editor and version control with windmill, and you can access your database and existing code easily. It works exactly the same way as trigger where you sync and deploy from your existing code repo.

Inngest and trigger are event-driven workflow engines while windmill is a more traditional workflow engine (think modern airflow) where the flow/graph is defined statically in a low-code UI (although can be generated dynamically) while the steps are code-centric. We also include a UI builder (similar to Retool) and have an heavy focus on running on your own infrastructure (k8s with helm or docker-compose) and include complete observability for heavy jobs (streaming logs in real time) as well as the ability to use hardware acceleration since we use your raw nodes. Windmill also include workers management and is polyglot, You can run typescript, but also go, bash, and python, and write queries for bigquery, snowflake, and postgresql without having to wrap them in typescript.

So I would say we are less focused on integration to external APIs and more focused on enterprise use cases, for critical and heavy background jobs that require long and complex workflows (for instance that may require approval steps). But I think you guys are also working on background jobs and I haven't seen it so hard to say.

Good luck to you all. I think for the people that know well both frameworks, it would be easy to discern when windmill or trigger is a better fit and I agree the use-cases are different.

The marketing landing page looks very similar to Vercel's homepage.

https://i.imgur.com/o5Cdldv.png

ish yeah, only a tad bit more than the way all pages look like other pages these days

Most of these shadcn / radix / tailwind based sites look similar.

This has been a trend for at least past 3 years after Tailwind made it easy to add gradients to <span> and <button>

If anything they have a cool slider/tabs for different actions.

Trigger.dev is awesome, use it every day. A feature list is quite impressive and complete, the only thing on my wish-list is a `wait/resume` for long running jobs

Thanks! Do you want the ability to call a Job from inside another Job and wait for the result?

We have a discussion about that here, would love to get your input: https://github.com/triggerdotdev/trigger.dev/discussions/516

The hooks are great for returning multiple values/progress updates to the UI. I've been using it for chained and/or long calls to the OpenAI API.

Super interesting tool! Glad to know you folks use SDK to write Jobs to avoid any deployment blockers.

Would love to see an article or post from you guys on how this compares to AWS Step Functions.

Really excited for this!

How does it compare to inngest.com?

Inngest is also an easier to use version of Temporal, for serverless.

Currently the major differences are:

- Open source: we're fully open source and self-hostable with Apache 2 license.

- API Integrations: we're building first class support for popular APIs. That makes it really easy to subscribe to webhooks, and when you do API calls you get good retrying behaviour, automatically dealing with rate limits, and a great logging experience. You can write your own integrations and contribute them (that would be awesome), or keep them private to your own codebase.

- React hooks: often background jobs are related to an action a person has done in your app (end-user or an admin tool). We have hooks so you can very easily show the live status of a run exactly how you want.

Very soon

- Support for Background Functions – we deploy your code so you can run any length of task. You write the code like any other job in your codebase. Discussion here: https://github.com/triggerdotdev/trigger.dev/discussions/400

- Support for long-running servers (so you can use if you’re not deploying to serverless). Issue here: https://github.com/triggerdotdev/trigger.dev/issues/244

Well done for being completely open source!

I'll suggest this to my employer and we'll probably choose the managed solution, but having the freedom to choose is a great bonus!

Chiming in as a founder of Inngest.

We released our TS SDK a year ago so had quite a head start in this area. The approach in their V2 release makes them more similar to us, though there are still some large differences, including the fundamental architecture, queueing technology, scale, etc. Some differences you'll notice as a developer:

- Concurrency and parallelism. We allow you to run steps in parallel, configure concurrency (per function, or with sub-groups for custom concurrency limits), and automatically fan jobs in, eg https://www.inngest.com/docs/functions/concurrency and https://www.inngest.com/docs/guides/step-parallelism.

This is a pretty big point, as you often don't want to run functions sequentially. We're also fully event-driven, allowing you to pause workflows and automatically resume when specific events are received (https://www.inngest.com/docs/reference/functions/step-wait-f...).

We also handle a lot of complexity for you that you'd have to build yourself:

- Rate limiting

- Batching, allowing one function to run from eg. 100 events, instead of 1:1 matching of event->function

- Streaming, for long-running responses

- Auto-cancellation, based off of matching events

- Branch deploys for all workflows, regardless of platform

- Debounce

- And a bunch more such as middleware, error handlers, multi-language support (including zero-downtime live-migrations of long running workflows), fully-offline local development, etc.

In general, I think we're tackling a similar problem with fundamentally different approaches in events and architecture. Trigger definitely have more in the space of integrations, while our approach is: send us anything, no matter the event or source, and we'll work with it.

While I don't know the Trigger folks I'm assuming they've seen similar problems as us and it's fun to tackle this area, so I'm looking forward to seeing how they build out their platform in the future and this area evolves :)

Just want to say, as a somewhat new HN user (l would end up here occasionally via search or Reddit, which I jumped ship after the API changes so HN is my home now), it’s really great to see you and the founder (iirc) of windmill both here in the comments.

You need stronger support for state management and scheduling across long running tasks.

This is your competitor:

https://www.inngest.com/

In the TypeScript/JavaScript world the only thing called "Temporal" that I was aware of is the Stage 3 proposal for an excellent new date and time module:

https://tc39.es/proposal-temporal/docs/

https://temporal.io/

Same, I'm sure more people are aware of this than whatever obscure service the poster is referring to

I have this bookmarked and it looks really well done, but feels like an anti-pattern.

Reply on news.ycombinator.com