Hacker Newsnew | past | comments | ask | show | jobs | submit | matt-aitken's commentslogin

You can be remote as long as your timezone is between UTC -2 and UTC +8. That covers most of Europe, Africa, and all of North and South America.


Minor point, but I think you've got your signs backwards. Eastern Europe is UTC+2, and PST is UTC-8.


Ah ok, appreciate it.


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.


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.


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.


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


Yep, thanks Mintlify!


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


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.


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!


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).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: