I currently have an FastAPI setup on ECS, am using managed Temporal Cloud, and have some workers deployed on EC2 instances.
I have 2 main concerns:
Is there a better way to manage my workers to allow for more seamless integration with the API?
My API requires a number of clients to be used (Mongo, Twilio, OpenAI, etc…) and some of these clients are dependent on the workflow (within a class of workflows, the twilio client for 1 workflow may be different from the twilio client for another).
In my current setup I would need to either make an HTTP request from the worker to the API, or dynamically instantiate all the required clients per activity for my API code to operate from within the worker. Both of these feel incorrect, are there some best practices or more recommended setups in either the architecture or method for managing clients that I am missing?
Appreciate any guidance.
When you say “from the worker to the API” do you mean activities invoking your API? Activities can basically execute any Python code you want. And it is normal to make a client and pass to an activity for use in multiple activities, see this sample.
It is not incorrect to use some DB/API client from an activity.
Yes, by from the worker to the API I mean I am thinking to invoke the API from the activity rather than executing the code from within the activity because of the dependency management.
Yeah I think what I am grappling with is that some of my clients are dependent on the workflow. So Workflow A and Workflow B of the same workflow “type” may have different initializations of the client based on the workflow parameters.
You can use activity parameters to pass in whatever you need from the workflow for use by your client-calling code. Think of an activity as any other API/RPC you’d implement. How would you have that API/RPC implementation call the clients? Activity is the same way, it accepts input, returns output, etc.
So the best practice would just be to initialize the clients based on the workflow parameters at the workflow level and then pass them into any activities that require them?
You can’t initialize a client at a workflow level. Workflows must be deterministic and cannot pass in-memory state to an activity (only serializable parameters, it may run on a different machine). But you can pass parameters to an activity and the activity can do whatever is needed such as initialize a client (or look one up from cache).
This is the same as, say, a REST API handler implementation where the client was different for every API input data. How you choose to initialize/reuse clients is up to you based on the information given.