gatewayd
gatewayd copied to clipboard
Add queueing for async actions
Currently the asynchronous actions run as a goroutine. This should be changed to using a worker that queues the outputs for async actions and run them separately. This can be done as a separate command, like gatewayd worker, that run a set of workers that consume from a message queue that gatewayd run produces messages to.
flowchart LR
Queue -- publishes outputs --> GatewayD
Queue -- consumes outputs --> Workers
Workers -- runs --> Action
Workers -- publishes results --> Queue
GatewayD -- consumes results --> Queue
The idea is that if an action is async, it can be defined in a worker and registered in a registry with a pointer to the worker. The worker contains a Run function, which executes the action. Data needed for the Run function is dispatched (published) to the worker via a queue, enabling the Run function's execution. Results or errors are returned through an alternate queue set back to the Act system. For this, we don't need to change the implementation of the action, rather we can have a generic queue message publisher that implements the ActionFunc, which can be reused in async actions for publishing the exported Action fields to the queue. The message will be picked up by the worker to execute the Run function.
I have implemented a minimal example in the act-poc repository for queueing using this channel, which is used in action like this and then the results are logged into the terminal. It uses the awesome golang-queue project, which I recommend to be used as high-level wrapper for our use case.
This is what I have on my mind:
sequenceDiagram
participant GatewayD
participant Registry
participant Queue
participant Worker
GatewayD->>Registry: Registry async action
Registry->>Registry: Register action with pointer to generic ActionFunc
Registry->>GatewayD: Success or error
GatewayD->>Registry: Run async action
Registry->>Queue: Publish message
Queue->>Worker: Consume message
Worker->>Worker: Run action with the given data in the message
Worker->>Queue: Return result or error
Queue->>Registry: Return result or error
Registry->>GatewayD: Here's the result or the error
Resources
- https://github.com/golang-queue/queue
- https://github.com/gatewayd-io/act-poc
I'd like to work on this. But I'm a little confused about how the action Run function should be passed through a messaging queue.
A broader question about actions: how can one create a custom-made action without using the built-in ones? How should one provide the Run function? do we have an example for that?
Hey @Hamsajj,
@likecodingloveproblems asked me earlier on LinkedIn to work on this same exact ticket, but we decided that it'd be best for him to start with another ticket to get to know the codebase, which he did in #503. I'd be very happy to give this to either or both of you. On the other hand, I know that you worked on more tickets, especially those related to the Act system, and you have a good grasp of what it entails. Alternatively, @likecodingloveproblems might want to choose another ticket of the same epic if he wants. I'd really like to know what both of you think about what I mentioned, so we can proceed.
@Hamsajj I'll update the ticket description to answer your technical questions about this ticket.
I can happily work on another ticket if @likecodingloveproblems wants to work on this one. As you mentioned, there are a lot of tickets on the same act system epic. (btw, kudos to you @mostafa for setting up these issues and tickets, making this repo welcoming and relatively easy to contribute)
Also, thanks @mostafa for adding the detailed explanation of how the Run function should work. The diagram is much appreciated. I'll go over them and try to understand how it should work. It will help with other tickets even if I don't work on this one.
Hey @Hamsajj,
I know @likecodingloveproblems is busy these days, so I suggest picking this up if you like.
Hey @Hamsajj,
Is this still in progress? Do you need more context?
Hi @mostafa Yes, it is still in progress. But I am a little pressed for time. I did some work on this last weekend and will continue this weekend. I will probably create a PR to discuss it and continue from there.
No rush! I was mostly interested in seeing progress, not pushing. 🙏