https://prefect.io logo
Join Slack
Powered by
if `@task` s can be `.delay` -ed , then why should...
# ask-community
c
if 
@task
s can be 
.delay
-ed , then why shouldn't 
@flow
?
The question's purpose is to help me get a clearer idea on how to design the backend integration of prefect
Here's an abstract representation of what I'm trying to implement:
Copy code
class FleetController(ABC):

    @task
    async def reserve(self):
        """Client-invoked"""
        ...

    @task
    async def provision(self):
        """Worker-managed"""

    @classmethod
    @flow
    async def on_reservation(cls, request) -> Reservation:
        self = cls()
        handle = self.provision()

        request.callback(handle)
There could be different types of "fleets", which result in changes in logic and configurations; I assume this is the case for "deployments", but I'm trying to get a rough idea on how clients are expected to interact with deployments, which is the worker-side of the flow
n
hmm could you expand on what you're reserving / provisioning? im not sure if you mean worker as in "prefect worker" or something else ill mention the simple way I often start using prefect is mostly just with functions (i.e. task, flows or both, run them like normal python), and you can elevate flows to deployments as needed you might want to check out events, i.e. define triggers that deployments (which I sometimes think of as handlers) should run on, where you or clients elsewhere emit events that you can react to and template those events as parameters of your handler. > if 
@task
s can be 
.delay
-ed , then why shouldn't 
@flow
? tl;dr 
some_task.delay(...)
results in a websocket client pushing a new 
TaskRun
to the server so a 
TaskWorker
elsewhere can execute it like these examples - whereas flows can be deployed or served so that scheduled runs of that deployment can be executed by a long-lived process polling for scheduled runs (e.g.) (
.serve
is just an easy-mode "process" worker) ie to tell a deployed flow to run elsewhere, you can: • use 
run_deployment
to trigger it (via 
POST /create_flow_run_from_deployment
under the hood) • use 
emit_event
to create the pre-requisite events for one of a deployment's 
triggers
🎯 1
c
Very well explained, I appreciate you!
catjam 1
3 Views
Open in Slack
PreviousNext
Powered by