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:
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.