How does Trigger compare to tools like Temporal or Restate? If we put aside the AI use case, it seems like the fundamental feature is durable execution, where there are a few other options in the space.
Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
21–30 of 70 posts
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#22How are you folks handling the "uploading your source" to trigger for the workflows to work on your cloud offering? One thing that I find Temporal always wins over is that the workers live on your cloud/server so you aren't required to upload anything to them. Any plans to tackle this in the future?
Currently we have two deployment models: self-host the entire platform or use our cloud offering, where we host the platform and your workloads. We've had a lot of feedback from users and potential users that they'd like to be able to run workloads themself and have us host the platform side. We definitely plan on offering this deployment model (and allowing payloads and outputs to stay on-prem as well) eventually, b…
Nice glad to hear it!
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#23I really like Trigger but I would have loved some way to trigger it from the FE, it was a small part of our use case but it sucked having to implement a proxy for it.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#24I really like Trigger but I would have loved some way to trigger it from the FE, it was a small part of our use case but it sucked having to implement a proxy for it.
If it were possible, how would you have prevented your Trigger account from being abused once a bad actor got its connection details by inspecting your FE app with DevTools?
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#25I really like Trigger but I would have loved some way to trigger it from the FE, it was a small part of our use case but it sucked having to implement a proxy for it.
We support this but you do need to pass a public access token to your frontend so it's secure: https://trigger.dev/docs/realtime/react-hooks/triggering
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#26This looks great, I wish I had discovered it 4 months ago. I had to build entire coordination of Prefect with Django app in https://listingheroai.com
Listing hero allows ecom brands to generate consistent templated infographics so I reinvented all these things via data share between Django, Celery processes, Prefect, and webhooks. Users can start multiple generations at the same time and all run in parallel in Prefect and realtime progress visible in frontend via webhooks.
I will try playing with Trigger next weekend and probably integrate with a static stack like cloudflare worker. Excited to try it out!
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#27How 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.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#28How does Trigger compare to tools like Temporal or Restate? If we put aside the AI use case, it seems like the fundamental feature is durable execution, where there are a few other options in the space.
I have used Temporal in the past in my previous job and currently using Prefect. All are similar in terms of durable and traced executions but this one seems to be tailored towards AI use cases where as others are more general.
I haven't tried Trigger, planning to give it a spin this weekend!
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#29How does Trigger compare to tools like Temporal or Restate? If we put aside the AI use case, it seems like the fundamental feature is durable execution, where there are a few other options in the space.
The core is a durable execution engine, but there's a lot more needed to build good applications. Like being able to get realtime progress to users, or being able to use system packages you need to actually do the work (like ffmpeg, browsers etc).
Both of them are focused more on being workflow engines.
Temporal is a workflow engine – if you use their cloud product you still have to manage, scale, and deploy the compute.
With Temporal you need to write your code in a very specific way for it work, including working with the current time, randomness, process.env, setTimeout… This means you have to be careful using popular packages because they often using these common functions internally. Or you need to wrap all of these calls in side effects or activities.
Restate is definitely simpler than Temporal, in a good way. You wrap any code that's non-deterministic in their helpers so it won't get executed twice. I don't think you can install system packages that you need, which has been surprisingly important for a lot of our users.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#30This looks really interesting, congrats! One thing I did notice though from looking through the examples is this: Uncaught errors automatically cause retries of tasks using your settings. Plus there are helpers for granular retrying inside your tasks. This feels like one of those gotchas that is absolutely prone to benign refactoring causing huge screwups, or at least someone will find they pinged a pay for service 5…
Yep you do need to be careful with uncaught errors.
When you setup your project you choose the default number of retries and back-off settings. Generally people don't go as high as 50 and setup alerts when runs fail. Then you can use the bulk replaying feature when things do wrong, or if services you rely on have long outages.
I think on balance it is the correct behaviour.