Automating server-side actions based on cursor changes

I have a workflow in which one type of user calls another to offer assistance, for which they are paid. I’m trying to keep models separate such that data from a web RTC call is separate from data on the task attempted, and an Attempt document is created when a call between two users connects. Initially this was implemented by calling a method client-side when the call connects, but it recently occurred to me that I could move this logic entirely server-side. There are very specific instances in which an Attempt is created. By creating an observe cursor on my Calls collection, I can dynamically create and complete task attempts on the server with no client-side intervention.

Unfortunately, I don’t know how to scale this model beyond a single process. If I have a query like:

Calls.find({state: "connected"})

And then want to create/complete task attempts based on whether results are added/removed, then run 2 server processes, these cursors will step on each other very quickly.

First, is this a bad idea in general? I’d like to keep the web RTC call logic separate so I can reuse it in other apps, and querying the collection in the app-specific code that handles tasks seems like a great way to do this.

If it’s a good idea, is there a way to ensure that the code only runs in one place regardless of how many Meteor processes I have? Maybe there’s a package that helps with this? If not, I suppose I can spin up a stripped-down Meteor process without the webapp components. Are there any guides on how to create headless Meteor processes? I see a differential:workers package, but I don’t know that I want a full job system for this. I just want to monitor the results of a query in near real-time, then act promptly on results as they come in.

Thanks.

Can you share a GitHub gist outlining your current solution? Thinking this is one of those things that requires a sample first to better understand what you’re looking to accomplish.

1 Like

My current solution was pretty hacky and didn’t work, but I think I’ve figured it out. I’m experimenting with liberally using upserts, and since the newly-created documents will always contain the same data, it doesn’t matter much if they get written by each process. If it ever does become an issue, I likely have the financial resources to spring for a dedicated worker and can refactor to that. :slight_smile:

Basically, what I was doing was calling methods from the client at strategic points, so when a call was answered, the answering client made a method call to insert the related documents. Now I’m monitoring a query against the calls collection on the server, and when a new document with the desired characteristics gets added (I.e. a newly-connected call) the added/removed callbacks handle the related document workflow server-side.

Cool! If you bump into any rough spots, let us know :slight_smile: