Thanks for joining our Discord and asking the question there as well! I'll reply here as well for the HN community.
People have often tried to use Temporal to solve similar problems. We think Dispatch is a very different solution because we don’t require you to architect your system in terms of a rigid framework of activities and workflows... You just write regular code with simple functions, enabling incremental adoption into existing applications and making the code easy to test.
A friend of mine once described Dispatch as "Temporal without the galaxy brain", it's a pretty good way of phrasing it in my opinion :)
Dispatch takes a different approach with different trade-offs, but you're right that capturing the local program scope brings interesting challenges.
Serializing file handles doesn't work, but in our experience, programs rarely run into constructs where this becomes a problem, and when it happens, there are mitigation measures that are usually easy to implement (small restructure of the program, capturing resource metadata to reconstruct them later, etc...).
We have a few features on the roadmap to help mitigate the security implications as well, including allowing users to store their program state in a S3 bucket that they own. Our scheduler can operate with only metadata about the program, so splitting the two can be an effective model to mitigate those risks.
Storing the data in the customer's S3 bucket is a really good idea IMO. Means they just have to trust you to run the coordination reliably, but not necessarily to keep their data secure which is a much easier bar to clear.
I so wish AI could create systems that deal with the complexity of problems that Dispatch solves for. Until then, we’ll still have to write a few lines of code.
We can run it forever but it’s rarely useful. Usually, all operations have an associated expiration time so if it’s impossible to succeed it will eventually abort.
To summarize, our scheduler maintains state to allow retries to happen even if the application moves between compute instances, which is quite common when running in the cloud (e.g., deploying on autoscaling containers, or serverless functions).
Thanks a lot for reading the post and reaching our with questions!
> That's great. Is it persisted to retry even after a reboot?
Absolutely! Our scheduler service manages the state on behalf of the application, even if the program restarts, the operation persists until completion.
> What informs the end user, in interactive situations, and what does it tell them?
Since the Dispatch SDK integrates directly in the code of the application, it's compatible with typical system observability tools. Say you're using metrics or traces to track operations, you can emit this telemetry on your dispatch functions. That being said, we know how important it is to have a built-in solution for this!
> What if the operation is delayed so much that it no longer makes sense; can we cancel it?
Different ways to solve this, one is to simply raise a permanent error so the operation stops, but in some cases it makes more sense for the system to expose controls so the operator can act on group of similar operations for example. Those are features on our roadmap at this time, but definitely agree on the importance!
> How do we identify a particular one, out of thousands going through the same function: by some of the arguments, like in memoization?
Searching through the state or history of the systems is also a key feature that a platform like Dispatch needs to provide to be "complete". We're still in early development so we haven't gotten to add this feature yet, but definitely excited to delivering it!
Today marks an important milestone for us with the launch of the developer preview of Dispatch.
Along with a serverless scheduler, we released an open-source Python SDK, providing developers with a simple programming model to integrate with Dispatch.
This is the first of many steps on our mission to make distributed application development radically simpler.
To all developers tired of wrestling with infrastructure and eager to experience better tools to develop distributed applications, check out our blog post and take Dispatch for a ride!
Great post! I suggest adding a link to Dispatch earlier in the body. Right now the reader has to get all the way to "You can sign up to the developer preview for free today at https://console.dispatch.run !" before they know where to click (or maybe I need to get new eyeglasses!)
People have told us many times that they tried to use Temporal to solve the problems that we designed Dispatch to solve for, so it's a fair comparison!
What we hope to deliver with Dispatch is a model that is a lot more incremental in its adoption and much simpler than what existing solutions have been able to achieve so far, both in terms of development UX and operational complexity.
Give it a try, and let us know what you think of it!
Today marks an important milestone for us with the launch of the developer preview of Dispatch.
Along with a serverless scheduler, we released an open-source Python SDK, providing developers with a simple programming model to integrate with Dispatch.
This is the first of many steps on our mission to make distributed application development radically simpler.
To all developers tired of wrestling with infrastructure and eager to experience better tools to develop distributed applications, check out our blog post and take Dispatch for a ride!
We tried that actually, and it can work well but you make a different set of trade offs. For example, you can’t get the granularity that durable coroutines give you, you’re bound to snapshot and restore the entire state of the application.
WASM is also not as mature of a tech for server side systems, a lot is left to figure out so the type of applications that you can build with it remains limited.
I’d be excited to see support for something like this get built tho!
People have often tried to use Temporal to solve similar problems. We think Dispatch is a very different solution because we don’t require you to architect your system in terms of a rigid framework of activities and workflows... You just write regular code with simple functions, enabling incremental adoption into existing applications and making the code easy to test.
A friend of mine once described Dispatch as "Temporal without the galaxy brain", it's a pretty good way of phrasing it in my opinion :)