Skip to content

Conversation

@swyxio
Copy link
Collaborator

@swyxio swyxio commented Jan 13, 2022

there are some type considerations i havent figured out yet but this is the kind of developer experience i am looking for.

Comment on lines +177 to +178
await client.Signal(entity.Signal, { increment: 1 })
console.log(await client.Query(entity.Query))
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we want to be fancy we can even collapse this to entity.signal() and entity.query() by absorbing the client calls into Entity, but not sure if there would be significant impact on workflow bundle size.

this.workflow = this.workflow.bind(this);
}

async workflow(input: Input, isContinued = false) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How's the worker going to know the name of this workflow?
You need to export a workflow function per entity.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the biggest question. perhaps i can attach a name on that workflow

Comment on lines +160 to +167
interface Input { /* define your workflow input type here */ }
interface Update { /* define your workflow update type here */ }
const entity = new Entity<Input, Update>({
activity: 'MyActivityName'
activityOptions: {
startToCloseTimeout: '1 minute',
}
})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a workflow code

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah good point

Copy link
Collaborator Author

@swyxio swyxio Jan 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually.. if i dont make it workflow code, then i dont have to register it separately. it could be very interesting.

@bergundy
Copy link

Some other general comments.

This type of workflow is good for when you want to ensure only a single update is applied concurrently.
The implementation is a bit limited at the moment because if the update function takes longer to process than the rate of incoming update requests the workflow history will reach the limit.
The nice side effect of this workflow structure is that we can carry the pending work on after we continue as new, we should consider adding that.

Lastly, you could really use some tests for this code.
It doesn't work at the moment and if we add more complex features without tests it probably will be buggy.

@swyxio
Copy link
Collaborator Author

swyxio commented Jan 13, 2022

The implementation is a bit limited at the moment because if the update function takes longer to process than the rate of incoming update requests the workflow history will reach the limit.

i am planning to switch to startChild once the type bug is fixed, which wouldnt solve it but would make it non blocking at least

The nice side effect of this workflow structure is that we can carry the pending work on after we continue as new, we should consider adding that.

not sure how to achieve that, i thought we have to drain before continuing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants