Live data from Hacker News

Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

news.ycombinator.com

31–40 of 70 posts

Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#31

How does this compare to Inngest? That seems to be the closest comparison AFAIK so I'd be curious to what extent Trigger might be better than Inngest.

Inngest is very similar to Trigger.dev version 2: it’s an API for queuing and orchestrating workflows. You need to divide your work into steps, where each step needs to have serializable inputs and outputs, and takes less than the timeout of your serverless function (if you're hosted on serverless).

Trigger.dev is a queue and workflow engine but we also run compute. This makes some things possible which aren’t when you only control one side:

1. No timeouts, you can run code for as long as you need. 2. You don’t need to divide your work into steps. If you want you can use multiple tasks. 3. You can install any system packages you need, like ffmpeg, Puppeteer etc. Depending on where you’re deploying this can be a problem with other tools. There are maximum bundle sizes on a lot of platforms which are surprisingly easy to hit. 4. Atomic versioning. Each deploy of your tasks is separate and any runs that have started will continue until finished, locked to that version of the code. This means you don’t need to think about versioning inside your code which can becomes messy and error prone.

One other note is that we’re Apache 2.0.

Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#33
We're very satisfied customers since January of this year.

We use it as an extension of our node app, for all things asynchronous (long or short). The fact that it's the same codebase on our server and trigger cloud is a huge plus.

For me, it's the most accessible incarnation of serverless. You can add it to your stack for one task and gradually use it for more and more tasks (long or short). Testing and local development is easy as can be. The tooling is just right. No complex configurations. You can incrementally use the queuing, wait points, batch triggers for more power.

We've had some issues with migrating from v3 to v4. The transition felt rushed (some of the docs / examples are still showing v3 code, that is deprecated in v4). I understand that it might take some time to update the docs and examples, because there is a lot of content.

Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#35

I like Trigger but it's a lot of complexity... > use cases like compute-heavy tasks such as generating videos using AI (Icon.com), real-time computer use (Scrapybara), AI enrichment pipelines (Pallet, Centralize), and vibe coding tools (Hero UI, Magic Patterns, Capy.ai) Okay, but aren't these websites using Trigger to schedule remarketing slop? Like adding you to Slack, sending you an email on day 1, sending you an e…

co-founder of Magic Patterns here, saw were were mentioned, figured I'd chime in:

We don't use Trigger for marketing at all and I actually never thought of it for that use case.

We're an AI design tool - prompt to create an interactive mockup - and we use Trigger to take screenshots of designs to provide a preview image. Taking a screenshot sounds easy, but it's not because Puppeteer constantly hits OOM errors. So you need a high-end machine, and so it can get expensive. We originally were using a homegrown solution, a microservice, but it would constantly crash (even though were paying $$$$$ for it).

Trigger spinning up jobs was perfect and we migrated in a day and now I never think about it.

Post reply on HN