Changes Worker Pattern

Pattern: Changes Worker

If you connect to a changes feed of some channels, you'll get lines of JSON for each matching change.

Now you can write a script to consume these channels and take action based on them. For instance if you have a channel called "needs-email" you could have a bot that sends an email and then saves the document back with a flag to keep it out of the needs-email channel.

There are existing libraries to handle a changes feed with a worker process.

Your workers should be idempotent or you should track the last_seq somewhere durable.

State Machine Document Pattern

The way to think of your documents when you are using them in a changes-driven worker process, is as a state machine. So maybe you have complex business logic to run when adding someone to a project. So not only does the new project member have to be invited to the project, the accepted invitation has to be approved by two layers of management. Yay management.

To implement this you'd treat the document as a state machine. You can put a state field on it, and then the steps to get to the next state can alternate between human and robot powered.

So in this case, the project owner would create the invitation, and according to their level of access, they aren't able to send the invitation without management approval. So they save it with state="needs-approval" and the sync function automatically routes it to a channel of approvals needed by managers. The invitation is sitting in a needs-approval queue on some management iPhones, and when one of the managers clicks OK, then it enters state="approved" which cases the sync function to put it in a channel where it can be seen by the invitee.

Now when the invite clicks "accept" they can put it into state="accepted" which may or may not need more management approval before the a robot changes the state="active" which actually grants access the invitee access to the project.