I'm not sure when it started, but I feel like there has been an recent increase of "for every dev" or "for everyone" in marketing copy of tools like these. Though, if you look into it for just a minute it's not a polyglot tool that at the core exposes e.g. a REST API that could be talked to in any language, but a "library + SaaS" for a very specific subset of developers (though not a small one).
------
To the founders/team: Sorry for the rant - you are not the only ones doing it. Congrats on the funding!
Hah, I get it. We actually have an alpha Go SDK out, and an Elixir SDK in progress. The cool thing is you can switch languages and clouds, deploy a new endpoint, and function state carries over for zero downtime migrations.
Neither are critical but I recommend your repo have underscore instead of hyphen for an elixir project, and using "ex" in the name of your project is generally (informally) considered to be a signal for low code quality in the community.
Thanks for the note, it's changed to underscore now.
Regarding the "ex" prefix, it's a common pattern for Elixir libraries.
https://github.com/h4cc/awesome-elixir
We started with the TypeScript SDK to help us stay focused while we iterated and learned. As Tony said, we'll gradually expand to other languages (likely Python in the near future too!).
As for your "REST API instead of an SDK" concern, we invoke your functions so we need some code in your app. We need to handle things like memoizing steps within a function, so there needs to be some orchestration within the app
Yeah, this has been pretty universal, lately. As a primarily Go/Rust/Python developer, it continues to baffles me how these languages continue to be the "default."
Isn’t life with aspnet easy enough because it actually can do multithreaded work right? So not really a problem for dotnet folks.
Unless you really want the one-click experience. We use aws sdk, spin up sqs, add some env vars to aspnet, connect the client, enqueue and dequeue all from the same app without a 3rd party (short of the queue infra).
Half of us are Go devs, so we definitely don't think TypeScript should be the default language everyone uses. We only chose to start with a TypeScript SDK!
I think a lot of these early companies have high ambitions in terms of serving various languages, then they find out how hard writing SDKs and tooling for each of them is.
> ... they find out how hard writing SDKs and tooling for each of them is.
Absolutely. Each additional SDK adds a lot of maintenance effort. It isn't just a write-it-once thing:
- More time spent writing/updating docs
- More context switching in support channels
- More time spent updating SDKs as new features are developed
Staying focused on one SDK helps to keep velocity high in the early stages. But our product has matured enough that we feel comfortable gradually rolling out more language support, starting with Go soon
I think this is an interesting service, and could be a nice way to write a SvelteKit or Next.js app with background workers.
The press release is unnecessarily hyperbolic, which turned me off, though:
> Deploying new jobs to production also requires tedious configuration of cloud infrastructure which often requires a handoff to another team or individual. Often weeks of developer time is spent on basic workflows, before anything complex like idempotency is handled.Using Inngest, developers can write, test, and deploy complex workflows to production in hours, not weeks — all without touching infrastructure or queues.
Using something like Dramatiq [1] with Redis, writing a background job takes minutes, and can be deployed alongside an existing Python web app. There are probably JS equivalents.
I think Inngest could be a useful service (I might have used it if I'd seen it a few weeks ago), but the comparison felt off for me - it made me feel like this wasn't solving a real problem.
The simple case is simple, but anything beyond that can get challenging. Some examples:
Multi-step functions. This requires chained jobs, and your dependencies get messy. Operating this kind of sucks. Change management here is hard. It's much easier and faster to write a single function using Inngest; basically any engineer can do it without learning infrastructure.
Absence of events/activity (eg. when a user adds a product to the cart, send an email if they don't check out). You need to start writing crons and depending on implicit state that occurs within your DB. I've done this; it becomes really buggy. Much nicer to do `step.waitForEvent` in procedural code.
Fan-out (eg. when a user signs up, add them to Stripe, intercom, etc, or mass ecommerce imports). You can definitely handle this with individual jobs, though this starts to stack up and then monitoring is overblown.
Retries and dead-letter queues. It's much easier to replay functions en-mass, or replay events that have failed, without worrying about dead-letter-queues and redrives.
Config generally sucks. You can manage concurrency, backpressure, etc. yourself, alongside managing the infra, but that's no fun. Or, you can use some existing queues and then manage cloudformation, terraform, infrastructure code, DLQ config, etc. yourself too.
Batching is annoying to build. I'm not sure how you'd batch high-volume events or jobs in Dramatiq. Maybe you can add your own observability, deploy new workers, and try to avoid batching — deal with that yourself?
There's more, too. Rate limiting, concurrency controls (eg. per user, not per job), branch deploys/preview environments/staging envs, are all pretty frustrating and require infra investment.
As with anything, handling the initial case is pretty easy but quickly gets hard.
I actually agree, which is why I wrote the comment. It is easy to create background tasks. Dramatiq can even handle some of the cases you mentioned - multi-step, fan-out, and retries.
It is hard to scale background tasks when you hit a high level of concurrency, as you've mentioned.
Your press releases makes it sound like the initial setup of background tasks is hard, and doesn't mention the harder stuff.
It's also annoying to build this stuff on serverless platforms. Love it or hate it, they're here to stay and one of our principles is that we should meet you where you're at — setting this stuff up has always been infra and platform specific; we don't want that to be the case. Developers should be able to write code and have it work everywhere, ideally.
Hey thanks for the comparison - Temporal is a powerful tool. There are definitely similarities with what Inngest is capable of. Here are a few differences to highlight:
- We’ve taken a different approach that removes the queue and worker abstraction from the end developer and instead uses an HTTP-based invocation. This enables Inngest functions to be run on any platform, including serverless.
- Inngest is powered by events which gives developers the ability to fan out work and build event-driven flows easily.
- Inngest also allows you to coordinate across events, enabling workflows to pause and wait for additional input (step.waitForEvent [1]). This is powerful for human-in-the-middle workflows (e.g. AI confirmation flows) or workflows that pause for days or weeks and conditionally run steps depending on what a user might do in your system (e.g. dynamic email drip campaigns)
- Lastly, events also provide a nice way to easy replay of your workflows across any time window.
- One last thing is that we’ve heard many times that while devs are often quite excited about Temporal, they’ve found Inngest to be much easier to learn and build with. We’ve intentionally worked to make our first SDK with the simplest primitives so their workflows just look like normal code, with minimal DSL.
Inngest has built in concurrency controls and rate limiting to prevent systems from being overloaded, allowing the user to have the same controls of a traditional worker, but just a simple config option.
Inngest was designed to be a solution that can replace traditional queuing systems and event driven systems. Originally, it was built with the idea to handle complex flows that need to be durable, e.g. healthcare workflows that have time-based follow ups and legal compliance tasks that need to be executed in a specific order depending on patient confirmation or other actions.
We've seen users build all sorts of things: automate infrastructure based on events, building AI Agents around LLMs, perform vulnerability scans across thousands of packages, building scheduling products, and e-commerce data pipelines. We're seeing new use cases each week.
Just to confirm my understanding; would you consider at least part of your product offering to be similar to temporal.io [1]? Your examples are reminiscent of theirs.
[1] https://temporal.io/
Funny enough, we were fortunate to meet Guillermo through our lead, GGV as part of due diligence. GGV had recently led Vercel's recent round so he was part of the process of vetting our product. Our timing was also great as we had recently shipped our Vercel integration [1] and were the only integration supporting background jobs and workflows in their integration marketplace. He quickly recognized the value in what we were building and was interested to invest. It was an ideal combination of timing of having built something of value to the Vercel ecosystem and being intro'd!
Guillermo has been a fantastic supporter overall :)
I'm not sure when it started, but I feel like there has been an recent increase of "for every dev" or "for everyone" in marketing copy of tools like these. Though, if you look into it for just a minute it's not a polyglot tool that at the core exposes e.g. a REST API that could be talked to in any language, but a "library + SaaS" for a very specific subset of developers (though not a small one).
------
To the founders/team: Sorry for the rant - you are not the only ones doing it. Congrats on the funding!