11–20 of 44 posts
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.
How does it compare to inngest.com?
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
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 marketi…
Quite a lot of our customers are using us instead of Temporal. Not for linking stuff together use cases.
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
We have a discussion about that here, would love to get your input: https://github.com/triggerdotdev/trigger.dev/discussions/516
How does it compare to inngest.com?
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 :)
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…
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.