Replies: 1 comment
-
For the state machine, Virtual object is generally the right abstraction, and the API you propose here is not too far from the virtual object API. For the cron functionality, i suggest checking the cron job example: https://github.com/restatedev/examples/blob/main/typescript/patterns-use-cases/README.md#cron-jobs |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I started off thinking about how I would have a handler that I could call and it would quickly return the sync status of the Virtual Object against an external resource. The simple way to do this would be to just invoke the handler every time I wanted to check the sync status, and then implement caching on the caller's side.
But that then begs the question, how can I proactively monitor the sync status of the resource? I don't want to have to call the handler and wait for it to go out and do whatever it needs to do to check the sync status. That could be a while. So, how could I implement some sort of background process to periodically call the sync handler?
I came up with 3 possible ways:
There could be two handlers that invoke each other with a delay and each calling a 3rd handler to do the actual processing, but that gets super messy with not only ensuring you don't cause a cascade but starting and stopping the process.
You could make a workflow that waits for a promise to shutdown while the two workflow handlers go back and forth, and then you have a handler that completes the shutdown promise.
You could have a Virtual Object handler that reads a cached value, and if it's too old, call another handler to get an updated value. That could be blocking or not.
All these approaches have issues and could run into issues.
My first idea on how to solve these issues would be to have a type of handler that acts like a cron job. You define the handler, decorate it with something like
#[cron(schedule = "15 14/2 1 * *", allow_manual = true)]
, and then it will run according to the schedule.You can retrieve the cron's return value by calling the handler method? Not sure what/how it would get started. There are a few options on how to start the cron, but I don't think it really fits into Restate's design.
At this point, I think the idea I'm dancing around is a combination of a Virtual Object and Workflow to make a higher level State Machine type object.
The object is created by a PUT API call, which puts it into a starting state (defined by an enum?). The handler runs in the background and can return an enum that controls what state to progress to. There would be an option to put that transition on a delay- so the Ready state can transition back to Ready state, therefor invoking the Ready state handler again.
My rough idea on how this would look:
I'm not sure how exactly this idea would work or get implemented, but I think it would be a very useful feature to have. I use Virtual Objects to control the mapping between an API resource and an external one. Right now I need to have some sort of external agent constantly poll the Virtual Object to monitor the health of the external object and if it is in sync or not.
I dunno. It's still a rough idea
Beta Was this translation helpful? Give feedback.
All reactions