@maxim so how do i share a client across multiple set of activities ? where in each set belongs to a specific workflow which is tied to a specific go pkg ?
can you help me with some pointers here pls
more info :
I have a single parent workflow running in a “parent” go package - this has a child workflow running in a “child-1” go package with some activities bound to only this workflow + pkg , now this “child-1” workflow is again triggering another “child-2” workflow which is in “child-2” pkg with few activities , and so on so forth - with nesting level of 5.
all these activities uses “github” client to talk to github to perform some ops .
The parent workflow tracks a single event - so there can be many parent workflows running in parallel. so i want to use a single github client for each parent workflow run, and then share this client across all the activites down the line in all the child workflows - activities.
PS: the reason am using different go pkgs is because of code-organization - i dont want to use a single main package where so many workflows and activities are at one place , this will result in thousands of files in the root of the repo - thats why i want to structure my code in a nice way.
the reason am using different go pkgs is because of code-organization - i dont want to use a single main package where so many workflows and activities are at one place , this will result in thousands of files in the root of the repo - thats why i want to structure my code in a nice way.
You can absolutely organize code without creating that many child workflows. Use Go primitives to structure your code appropriately.
To route activities to the same host across multiple workflows you can use a host specific task queue.
well I am using a single worker - on a single task queue - so all the actitvities are by default running on a single worker, but am having difficulty in sharing a client from one workflows activity to another workflow activity, cause each workflow is in a separate go pkg.
I don’t understand how the initialization of an activity object is related to a package the activity resides in. Workflows should never care about clients directly.
I would strongly recommend against creating a solution that relies on running only a single worker.