There are similarities with "durable workflows" but, honestly, a completely different approach. Lots of respect for them.
A few critical things:
* Inngest is primarily event driven. You send an event, we run one or more functions.
* Events give you lots of benefits: batching, rate limiting, replay, archiving, fan-out, etc.
* You also get a powerful event-based API in functions: `step.waitForEvent`. This lets you do a lot of things: human in the loop flows, coordination — and you don't have to learn complex APIs, worry about state, can handle timeouts easily.
* And events also let you connect things like webhooks, CDC, external systems to functions with basically zero overhead.
* Because of this, you can pause individual functions, then redrive events through specific functions - as events are stored for you in an OLAP event store for your workspace.
Fundamentally, in terms of DX:
* You don't have to register individual activities and workflows. Steps are lambdas. It's easy to work with
* Every step (activity) has an ID, which means versioning, replay, determinism is easier to reason about and see in our model.
* We also run on servers as well as serverless. It's actually quite nice bringing state and retries to serverless functions - they're good for (some) bursty workloads
* We also embed a bunch of flow control into the system for you.
Overall, both replace queueing systems. I think that's a good thing: you shouldn't really have to think about the specifics of your underlying infra when you're writing application code.
Foremost, thank you for the detailed answer. It's always helpful to have competitive analysis from the source
While the edit window on your comment is still open, you may want to consider removing the leading whitespace from your bullet points (since they're already newline delimited) because on HN those leading spaces make it pre-formatted and that means folks on mobile have to horizontally scroll to see your whole sentence
A few critical things:
* Inngest is primarily event driven. You send an event, we run one or more functions.
* Events give you lots of benefits: batching, rate limiting, replay, archiving, fan-out, etc.
* You also get a powerful event-based API in functions: `step.waitForEvent`. This lets you do a lot of things: human in the loop flows, coordination — and you don't have to learn complex APIs, worry about state, can handle timeouts easily.
* And events also let you connect things like webhooks, CDC, external systems to functions with basically zero overhead.
* Because of this, you can pause individual functions, then redrive events through specific functions - as events are stored for you in an OLAP event store for your workspace.
Fundamentally, in terms of DX:
* You don't have to register individual activities and workflows. Steps are lambdas. It's easy to work with
* Every step (activity) has an ID, which means versioning, replay, determinism is easier to reason about and see in our model.
* We also run on servers as well as serverless. It's actually quite nice bringing state and retries to serverless functions - they're good for (some) bursty workloads
* We also embed a bunch of flow control into the system for you.
Overall, both replace queueing systems. I think that's a good thing: you shouldn't really have to think about the specifics of your underlying infra when you're writing application code.