Hi,
I’m trying to integrate Temporal in a micro-architecture in a multi-node cloud environment.
Is it better, on a single node, to run multiple workers with a unique workflow or one worker with many workflows listeners
If a have a workflow named ‘createUser’ which provision the user in many third party, a new third party managed by another entity want’s to subscribe to the user, by declaring an activity, is there any system to dynamically load their activity by a JAR on Temporal and register it in the workflow without the need to my team to modify the existing workflow? (a real example can be Keycloak with a SPI to integrate new behaviours at runtime)
Is it better, on a single node, to run multiple workers with a unique workflow or one worker with many workflows listeners
We recommend one worker with many workflow types. It is more efficient and allows configuring limits (like a number of parallel executions) for all of them together. In some rare situations, some workflows might require separate limits which might require a separate worker. But it shouldn’t be a default.
No need to load activity types into workflows. Just invoke activities by their string names for those use cases. Here is how to invoke an activity by its name:
Thanks for your answer,
Ok for the first part,
for the second … I only have to set in the workflow the method newUntypedActivityStub instead of registerActivitiesImplementations?
but where is activityName defined ? and can activities be added without restart the worker ?
Worker. registerActivitiesImplementations should be done by the process that hosts activities. Are you looking into dynamic loading of activity implementations into their worker?
The worker that executes the workflow code only doesn’t need to register any activities and it can invoke them through the untyped stub by name without any registration.
We don’t have direct support for loading activities into the workers. It should be a pretty reasonable change to expose some sort of a factory that would take activity name and private the implementation. Then you would be able to implement the dynamic loading as an implementation of that factory.
Hello friends!
Is this feature available for Go SDK as well? if not, do you have a plan and ETA for this? It will be very helpful for our use cases :))
Btw, how do you deal with changes in functionality between the various SDK’s? Are they eventually all synchronised to work exactly the same?
Our goal is to eventually have full feature parity among all the SDKs. There is feature parity for the main features already. But some features, mostly around extensions (like interceptors or dynamic activities and workflows) are not available for all SDKs.