Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Inngest 1.0 – Open-source durable workflows on every platform

inngest.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Show HN: Inngest 1.0 – Open-source durable workflows on every platform

#51

Post by pvcnt »

tonyhb wrote: post #13
guilhermecgs wrote: post #12

what is the difference from https://temporal.io/

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…

Temporal also provides mechanisms to persist some state and query it. Is it possible to do with Inngest?

Re: Show HN: Inngest 1.0 – Open-source durable workflows on every platform

#52

Post by qianli_cs »

giovannibonetti wrote: post #46
secondrow wrote: post #39

Earlier quoted context omitted.

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

No, they don't. They work just like Temporal and the others, which send the durable state to a separate store. I totally understand that this is good for the tool business model, since many users will end up paying for the separate store, instead of keeping it in the same DB where the application already is, without needing to pay extra for it. After all, the amount of data for keeping that state should be relativly…

Hello! DBOS co-founder here. We actually use your app’s database (Postgres) as the state store.

Re: Show HN: Inngest 1.0 – Open-source durable workflows on every platform

#53

Post by PeterZaitsev »

tonyhb wrote: post #18
mdaniel wrote: post #15

Earlier quoted context omitted.

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…

We'll roll out a change that releases source as GPL after 3-4 years next week, actually. I do appreciate these comments and points.

BSL Is also not Open Source, it is another kind of Source Available issue.

Of course you're free chose the license what is right of your business, but trying to use Open Source name in deceptive marketing is the problem.

Re: Show HN: Inngest 1.0 – Open-source durable workflows on every platform

#54

Post by giovannibonetti »

qianli_cs wrote: post #52
giovannibonetti wrote: post #46

Earlier quoted context omitted.

No, they don't. They work just like Temporal and the others, which send the durable state to a separate store. I totally understand that this is good for the tool business model, since many users will end up paying for the separate store, instead of keeping it in the same DB where the application already is, without needing to pay extra for it. After all, the amount of data for keeping that state should be relativly…

Hello! DBOS co-founder here. We actually use your app’s database (Postgres) as the state store.

My bad, I had misunderstood that. You're right, and thank you for sharing it. That is a great differentiator. I see you have Python and JS/TS libraries, but my team is working with Go right now, so I'll have to pass. However, I'll keep it on my radar. Being able to handle wrap DB commands in the same transactions as the workflow store is awesome! [2]

[2] https://docs.dbos.dev/python/tutorials/transaction-tutorial

Re: Show HN: Inngest 1.0 – Open-source durable workflows on every platform

#55

Post by darwin67 »

giovannibonetti wrote: post #38

I've been looking into this space since I learned about Temporal recently, and I wonder if it would be better to have this integrated in my application, as a library, instead of an external dependency. This way, all the state would be in the same DB.

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. :)

Post reply on HN