Change Streams with Socket io (questions about MongoDB developer approach in tutorial)


I’ve been building my first MERN app and I’m thinking about incorporating change streams and socket io for certain aspects of the project. My initial setup just used change streams where the user would create a request object via an http request, the change stream is created and there is a timeout after which the change stream is closed.

After researching socket io, and reading this tutorial, I’m considering switching to a more active system that uses both change streams and socket io. I can see a lot of benefits to this approach. However, I’m unsure of the way the developer in the tutorial goes about not closing his change streams. Here is the server file on the github repo for the project. Watcher function example. I don’t see him closing the change streams in his watcher functions (there are two but I can’t include more links), the server file, or anywhere else (unless I’m missing something).

I thought not explicitly closing change streams was bad practice, however, I think it might be a better solution than opening a large number of separate change streams per each http request (per user) even if those are being closed. After-all, only two change streams are being opened in the linked example in total.

Can someone with solid experience please weigh in here? And if it’s okay to not close the change stream, is there a way you would recommend improving upon what this developer did, e.g., in the event the change stream fails? I suppose resuming could be implemented. Any assistance with this is much appreciated.

I use change stream with stream pipeline, in node.js pipeline function quit on error or exhaustion.
I use health check API to make k8s in this case to restart the service and the change stream.
so the infinite run of a change stream is bit of a challenge but you can solve it anyway you think serve the need.

in your case (I don’t know so much) I would maybe identify an error or just catch the “close” event on a cursor and make the change stream part re-runnable for these cases with some retry limit.