-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: refactor orchestrator and add more tests. #90
Conversation
return assertNever(command, `unknown command type`); | ||
} | ||
|
||
async function scheduleActivity(command: ScheduleActivityCommand) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it help the runtime performance to move these nested functions - scheduleActivity
, scheduleChildWorkflow
, etc out of the nesting, into the root of the class? So they're not reconstructed every executeCommand
, which might happen multiple times over the lifetime of an orchestrator instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number of invocations is fairly constrained and each invocation represents one or more network call that would dwarf any additional function bindings.
My thought is that the code cleanliness provided by re-use of the scoped variables trumps the cost of the creating the function on the 1-20 times this function is called per workflow execution run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sure. I personally put nested functions in the negative-code-cleanliness category, but thats just subjective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the executor cleaner than the orchestrator? Looks mostly the same
Closes #31
A start at refactoring the orchestrator.