And it seems their misnomer is practically everywhere, not just in the Show HN: their website also mislabels their links as "Open Source" - I guess trying to capitalize on SEO

SSPLv1 for anyone similarly interested https://github.com/inngest/inngest/blob/v1.0.0/LICENSE.md

Seems they had a change of heart around 2022: https://github.com/inngest/inngest/pull/81 but they actually only started lying about the license in this go-around because their previous Show HN <https://news.ycombinator.com/item?id=36403014> not only didn't mislabel things but they even said "we're gonna open source in the future" but I guess the future isn't here yet

Agree. This is absolutely deceptive. It's too bad how the OSS moniker is being misused these days...

I opened the comments before the website as I was sure this would be another of those sources available clickbait. Why is this kind of disingenuous move not enforced in the title guidelines of HN is beyond me.

> My only issue was that the execution of an inngest function wasn't completely intuitive, at least in TS, and you have to think in terms of inngest or, more precisely, the abstraction it is providing. Is it an actor, a step function, an event consumer, a saga? or a combination of some?

I'm personally curious about this. I'm not saying you don't, but why would you need to understand what kind of abstraction it is beyond it just being Inngest"? I like to think I've been able to use it effectively without this having ever crossed my mind. But I also just might be dumb. Hence the curiosity!

Thanks! There are a few things at play. High level, it's important to note we provide infra for you — so our multi-tenancy supports many tenants for every user.

In general, fairness means distributing work evenly amongst all accounts. This largely means partitioned queues. Firstly, every functions have their own queues. We have queues of queues: queues of functions available. And then we have queues of accounts. And so on. It's like nesting dolls all the way down.

There are lots of really fine details to get right: continuations, step parallelism, `connect()` with long running workers all mess with fairness, as do batching, debounce, throttling.

We wrote about it in some detail here: https://www.inngest.com/blog/building-the-inngest-queue-pt-i.... We'll probably do some deeper dives on this next year, too!

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.

Their syntax does look strikingly similar to the API we launched with a couple of years ago: `ctx.run("id", () => {})` vs `step.run("id", () => {})`.

It's good to see the ecosystem form around the APIs we've developed. From feedback we've received, they're easy to use.

Answered this in depth here: https://news.ycombinator.com/item?id=41605220

The TL;DR is both us and Temporal help with durable execution. We layer on events and a differing DX to make things easier, faster, and to also work on serverless if people need.

I can't speak to Trigger, as they've changed a lot since I last looked. It doesn't look like they do durable execution, workflows, steps, or events — it looks like they're an alternative to Lambda + SQS for TS only, so very different — more for your simple "run one thing in the background", from what I can gather. Take this with a grain of salt, though!

it depends on your load really. there are background job frameworks in other languages like Oban in Elixir that utilizes postgres.

if scale is low, it's not an issue. but once you have high usage, what typically people do is they move it to a separate database, otherwise you're saturating the resources and it starts impacting the application itself.

at that point, that's not much different from external state stored else where.

also another thing about databases is their ACID transactions can only handle up to certain amount of load. again, if you don't hit that limit, it's totally fine. once you do, which usually means outages, severe delays, etc, and it'll be a shit show.

disclaimer: I do work at Inngest, but also this is speaking from experience. :)

If your application is Python or TS based, you can check out the DBOS libraries, which do that.

Also compare to kestra.io which actually is open source afaik

Our launch week starts on Monday. There's something coming, with a full roadmap for differing DBs, multi-node setups, and metrics :)