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:
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 :)
Just want to say, as a somewhat new HN user (l would end up here occasionally via search or Reddit, which I jumped ship after the API changes so HN is my home now), itβs really great to see you and the founder (iirc) of windmill both here in the comments.
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 :)