Show HN: Trigger.dev V2 – a Temporal alternative for TypeScript devs (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…
43 comments
[ 3.8 ms ] story [ 55.4 ms ] threadWe'll be updating it as we make progress and open it up for early testers.
This project could go so many different ways and solve a bunch of my problems.
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.
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.
Quite a lot of our customers are using us instead of Temporal. Not for linking stuff together use cases.
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
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!
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 :)
We have a discussion about that here, would love to get your input: https://github.com/triggerdotdev/trigger.dev/discussions/516
This is your competitor:
https://www.inngest.com/
- Types + IDE > UI/WYSIWYG
- Integrations
- Long running workflows
- "Serverless"
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.
https://tc39.es/proposal-temporal/docs/
https://i.imgur.com/o5Cdldv.png
If anything they have a cool slider/tabs for different actions.