5 ms·

Inngest raises $3M seed to build the reliable workflow platform for every dev

54 points by francesca 3y ago

danfarrelly 3y ago
Inngest co-founder here - happy to answer any questions about Inngest or our fundraising!
- louislang 3y ago
  No questions, just wanted to say congrats!
- ravivyas 3y ago
  Congrats on the funding Typo on this line Your CI/CD process remains the same as before and Inngest
  - deleted 3y ago
    [deleted]
  - danfarrelly 3y ago
    Thanks! Fixed :)
- MrUssek 3y ago
  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/ https://temporal.io/
  - danfarrelly 3y ago
    Yeah - definitely overlapping use cases! I expanded on more detail above: https://news.ycombinator.com/item?id=36698178 https://news.ycombinator.com/item?id=36698178
- hoofhearted 3y ago
  What's the best way to go about getting Guillermo's attention?
  - danfarrelly 3y ago
    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 :) [1] https://vercel.com/integrations/inngest https://vercel.com/integrations/inngest
vikp 3y ago
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. [1] https://dramatiq.io/ https://dramatiq.io/
- tonyhb 3y ago
  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.
radiospiel 3y ago
how does inngest compare to temporal?
- jeremy_k 3y ago
  Came here to ask the same thing. The screenshot on the landing page looks very similar to Temporal.
- danfarrelly 3y ago
  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. [1] https://www.inngest.com/docs/reference/functions/step-wait-for-event https://www.inngest.com/docs/reference/functions/step-wait-f...
  - shawnb576 3y ago
    Temporal is designed for industrial strength flows and scale. For example an HTTP based push mechanism can overload workers hence the queue. And its jusr code so not sure about the DSL reference (of course thats common with other systems)? What use cases is this designed for? Easier to learn and build usually has tradeoffs
hobofan 3y ago
"every dev" = every JS/TS dev 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!
- tonyhb 3y ago
  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. https://github.com/inngest/inngestgo https://github.com/inngest/inngestgo https://github.com/darwin67/ex-inngest https://github.com/darwin67/ex-inngest
  - throwawaymaths 3y ago
    Just fyi: 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.
    - darwin67 3y ago
      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 https://github.com/h4cc/awesome-elixir
      - throwawaymaths 3y ago
        I'm just relaying stuff that is quietly joked about at elixir conferences. Take it or leave it.
- 3y ago
upmostly 3y ago
Used Inngest a few months ago and now use it, with RedwoodJS as part of every project I work on. It makes absolute sense to "event everything". Also, the dev-ex is incredible. Especially in conjunction with RedwoodJS. Well done, chaps!
- danfarrelly 3y ago
  Thanks! RedwoodJS is fantastic and we've been fortunate to collaborate with the core team to build in some great support for Inngest :) We also collaborated with their core team on a GraphQL envelop plugin that automatically sends events for every mutation called in your api: https://github.com/inngest/envelop-plugin-inngest https://github.com/inngest/envelop-plugin-inngest

54 points by francesca 3y ago

danfarrelly 3y ago

Inngest co-founder here - happy to answer any questions about Inngest or our fundraising!

louislang 3y ago
No questions, just wanted to say congrats!
ravivyas 3y ago
Congrats on the funding Typo on this line Your CI/CD process remains the same as before and Inngest
- deleted 3y ago
  [deleted]
- danfarrelly 3y ago
  Thanks! Fixed :)
MrUssek 3y ago
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/ https://temporal.io/
- danfarrelly 3y ago
  Yeah - definitely overlapping use cases! I expanded on more detail above: https://news.ycombinator.com/item?id=36698178 https://news.ycombinator.com/item?id=36698178
hoofhearted 3y ago
What's the best way to go about getting Guillermo's attention?
- danfarrelly 3y ago
  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 :) [1] https://vercel.com/integrations/inngest https://vercel.com/integrations/inngest

vikp 3y ago

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. [1] https://dramatiq.io/ https://dramatiq.io/

tonyhb 3y ago
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.

radiospiel 3y ago

how does inngest compare to temporal?

jeremy_k 3y ago
Came here to ask the same thing. The screenshot on the landing page looks very similar to Temporal.
danfarrelly 3y ago
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. [1] https://www.inngest.com/docs/reference/functions/step-wait-for-event https://www.inngest.com/docs/reference/functions/step-wait-f...
- shawnb576 3y ago
  Temporal is designed for industrial strength flows and scale. For example an HTTP based push mechanism can overload workers hence the queue. And its jusr code so not sure about the DSL reference (of course thats common with other systems)? What use cases is this designed for? Easier to learn and build usually has tradeoffs

hobofan 3y ago

"every dev" = every JS/TS dev 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!

tonyhb 3y ago
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. https://github.com/inngest/inngestgo https://github.com/inngest/inngestgo https://github.com/darwin67/ex-inngest https://github.com/darwin67/ex-inngest
- throwawaymaths 3y ago
  Just fyi: 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.
  - darwin67 3y ago
    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 https://github.com/h4cc/awesome-elixir
    - throwawaymaths 3y ago
      I'm just relaying stuff that is quietly joked about at elixir conferences. Take it or leave it.
3y ago

upmostly 3y ago

Used Inngest a few months ago and now use it, with RedwoodJS as part of every project I work on. It makes absolute sense to "event everything". Also, the dev-ex is incredible. Especially in conjunction with RedwoodJS. Well done, chaps!

danfarrelly 3y ago
Thanks! RedwoodJS is fantastic and we've been fortunate to collaborate with the core team to build in some great support for Inngest :) We also collaborated with their core team on a GraphQL envelop plugin that automatically sends events for every mutation called in your api: https://github.com/inngest/envelop-plugin-inngest https://github.com/inngest/envelop-plugin-inngest