36
points
tonyhb
Joined 1,708 karma
founder/ceo @ Inngest (https://www.inngest.com)
tony@inngest.com
- tonyhbCloudbleed. It’s been a fun time.
- I really, really want this updated too and saw it in my bookmarks. Figured the historic data was interesting, and that someone might want to give this another go.
- 88 points
- 3 points
- Actually, both Vercel and Cloudflare are based off of the API that we built at https://inngest.com (disclaimer, I'm a founder).
I strongly believe that being obvious about steps with `step.run` is important: it improves o11y, makes things explicit, and you can see transactional boundaries.
- 7 points
- Yeah, just... like, don't use ctx from WithContext after the errgroup. WithContext is an API that specifically and explicitly cancels the context on error. It's absolutely optional. It's not a bug at all. It's using the wrong APIs and using a variable out of intended scope.
- You can totally leverage postgres transactions to give someone... postgres transactions!
I just figured that the exactly once semantics were so worth discussing that any external side effects (which is what orchestration is for) aren't included in that, which is a big caveat.
- Anything that guarantees exactly once is selling snake oil. Side effects happen inside any transaction, and only when it commits (checkpoints) are the side effects safe.
Want to send an email, but the app crashes before committing? Now you're at-least-once.
You can compress the window that causes at-least-once semantics, but it's always there. For this reason, this blog post oversells the capabilities of these types of systems as a whole. DBOS (and Inngest, see the disclaimer below) try to get as close to exactly once as possible, but the risk always exists, which is why you should always try to use idempotency in external API requests if they support it. Defense in layers.
Disclaimer: I built the original `step.run` APIs at https://www.inngest.com, which offers similar things on any platform... without being tied to DB transactions.
- if they’re not funded by adverts then you don’t need an ad blocker, right?
- Inngest (https://www.inngest.com) | Engineers, Marketing+GTM | Remote (US, San Francisco) | Full-time | $130-245k + equity Inngest is a developer platform that enables developers to build amazing, complex, and reliable products without the hassle of building and maintaining infrastructure. It combines modern orchestration, advanced multi-tenant aware queueing, and built-in observability packaged in an easy to learn and use product that any developer can learn. We're backed by top tier investors including a16z, Notable Capital, Afore capital and angels including Guillermo Rauch (Vercel) and Tom Preston-Werner (Github co-founder). We serve customers from startups and large co's like Resend, SoundCloud, Gumroad, TripAdvisor, Browser Use.
You: Want to be part of a fast growing startup that is changing how developers build software.
- Distributed Systems, Execution Engineer - San Francisco
- Product Engineer - Full Stack - San Francisco, Remote US
- Content Engineer, Docs - Remote US
- Product Marketer - San Francisco
- Dev Rel - San Francisco
Roles: https://innge.st/hn-july-25-hiring
About working @ Inngest: https://innge.st/hn-july-25-info
- It’s not just the credit score - the APR offered is also chosen by the retailer.
0% financing costs the retailer 8%(ish) of the total amount, which is how the lender makes their money.
So in your case, the retailer didn’t want to lose that much of their margin.
- In the partnership model Waymo charges uber for the ride and Uber charges the customer.
The interesting thing is that uber loses money on every ride. Waymo charges Uber more than Uber charges the customer.
On Uber’s side, though, this is preferable to losing the entire ride. Uber loses much more slowly by controlling the distribution and losing a few dollars per ride than by losing the entire customer base with no revenue from these customers.
- Was going to post about your company compliance space (which we use and love). That naming conflict is rough and it's the first thing I had in mind.
- AFAIK, it's due to things like single frame construction and expensive + backlogged parts which you order directly from Tesla (as opposed to, eg, a drivetrain that may be made for 3 separate manufacturers).
Or, when you do have an accident it's typically more expensive to repair.
- https://inngest.com and agentkit. disclaimer is I work on it.
Does all of the event stuff and state stuff for you. Plus the orchestration.
- There are only a few popular, promoted alternatives to NextJS right now (that I know of): Remix and TanStack. That is, if you're fully React focused, ofc. I dont see promoting Remix as a red flag.
- The framework itself is super low overhead. You can deploy this anywhere, and if you deploy to inngest.com the P99 latency of starting agents is sub-50ms (and you can also realtime stream steps, tools, or model responses to the browser).
One of the main differences is the DX — _how_ you define the agentic worklflows is far cleaner, so it's both faster to build and fast in production.
- The main one is deterministic routing (https://agentkit.inngest.com/advanced-patterns/routing). Here's what that means:
Each agent builds up state via tool use. On each loop of the network, you inspect this state to figure out which agent to run next. You don't build DAGs or create odd graphs — you write regular code in a router.
Or, more generally:
* Each agent has a specific goal within a larger network. Several agents each working on smaller goals means easier prompt generation, testing, iteration, and a higher success rate.
* The network combines agents to achieve an overall objective, with shared state modified by each agent
* The network’s router inspects state and determines which agent should run next
* The network runs in a loop, calling the router on each iteration until all goals are met
* Agents run with updated conversation history and state on each loop iteration
Realistically the challenge with agents has classically been: how can I build something reliable, and how can this run in production reliably? These patterns are largely what we've seen work.