fetch the snapshots of the state from the API and push to the browser. We might explore some sort of long-term KV or state store in the future, but in the near term, I think this API would help - what do you think?

This makes sense - it's a cool approach. Our AgentKit library is doing something similar with state as well leveraging the output of steps to build up state. Ideally if state was persisted in the output of `step.run` and we added an API to query the output of each step you would be able to...

The Redis and pg URI options are documented here in our docs. We’d like to add a full docker compose example soon, but this should get you going.

www.inngest.com/docs/self-ho...

Yeah. That’s accurate. If you’re putting prod workloads on the self-host, I would run Redis and Postgres to back it instead of sqlite. You can also sign up for cloud for free to try things out pretty easily then move over to self -hosted later if you want.

Anything in particular that you’re curious about?

We should create a comparison table for reference, but our newest features like realtime and “connect” are also in self-hosted setup although may require some configuration. Self-hosting continues to get new benefits every week as that’s where our team commits our core code

It can be used in prod and devs are doing that today. It does not have feature parity with cloud though. It doesn’t have the o11y metrics dashboard, auth and bulk actions like replay or cancellation. All flow control and queueing are core to the self-hosted setup so execution is exactly the same!

Awesome - ping me here or on our Discord with any feedback - we'd love thoughts on how to smooth out the API and things that might help you reduce boilerplate, etc.

Funny you should ask about hooks and realtime... www.inngest.com/docs/feature... (this developer preview just went live 2 days ago; haven't promoted it)

What do you think? We do need more examples, but we're iterating on APIs and hooks to make it as ergonomic as possible. Would love your feedback!

I would love to layer on more ways to use Inngest’s primitives over time, like how we’re doing with AgentKit. I think as we’ve seen several other companies adopt the step/context.run model after Inngest tools could also be interoperable.

Yeah, that’s interesting. Maybe workflow kit needs to be more composable and kinda of like a portable format like it can be an output and an input whereas Inngest function outputs and trace visualizations now cannot be inputs.

Maybe this is a bad path the more I look at things. 🙈

I know this is asking a lot, but is there an example in the docs that matches your workflow most closely?

Not sure if this is a good approach, but I was looking for a way to hook into the xstate execution loop and inject Inngest's step.run into there.

That's helpful. I have to admit that I'm not very well accustom to xstate and just took a look at it for a few minutes to explore how we might map it to Inngest and there are so many ways to create state machines in xstate it's hard to find a clean path to map to

Ah ok - that's the main main value for you w/ xstate? the visual side of seeing it ahead of time?

Is that what you're thinking more or less? How would you wanna write this, with a state machine, a DAG or just in code with a kind of "router" function? Also, are you looking for functions that kind of run forever or something that is mostly executing to completion?

This is interesting, we have modeled ideas like this, especially for AI use case where each step.run within an Inngest function returns the current state of the entire workflow (like a DO) then the loop takes that current state and decides what to run next, returning the state.

At the end of the day, it's all highly dependent on your use case though, what are you building?