That sounds like a reasonable approach @vigorwebsolutions, offloading the heavy parts to a microservice hosted elsewhere. But it’s sounds like @orbyt simple node.js server for handling the chat socket traffic.
On that note @vigorwebsolutions, do you’ve suggestions/insights (perhaps point us somewhere) on how does your DO microservices servers communicate with the Meteor backend? are your mailgun servers completely independent or do they share info/ DB docs? if so how?
I’m still curious as to why several have mentioned that if I combine the current functionality in the bare node.js app with the meteor.js app (and thus be able to remove the node.js app entirely) that I may run into scaling issues.
Meteor.js is just a node.js app under the hood, is it not? Given the context of this thread, what differences would there be in scaling the barebones node.js app vs the meteor app?
I think it has to do with Meteor real-time pub/sub system which tails on the Mongo Oplog, and I’m not clear on when a fine tuned app that uses Meteor’s pub/sub start showing performance issues and how severe are those. I assume if you don’t use pub/sub then it’ll have the same scaling behavior as your typical node.js app.
You can follow the Redis-oplog thread for more info on how to solve scaling the pub/sub system.
I hope someone with firsthand experience on scaling Meteor pub/subs system can provide more insight, these are just my assumptions.
So we just dump the mailgun data into a collection that gets cleaned up and then aggregate that data to show an overall view on open rates, bounces, etc. The DO servers are very simple. We use MongoClient to connect to the DB, then listen for our webhook. run the signature to make sure it’s valid, then do an insert into the collection.
Got it, so you’re integrating at the DB level between the DO servers and the Meteor backend, thanks for the input @vigorwebsolutions.