Hello everyone,
Like a lot of us, I’ve started working with serverless: https://serverless.com/
I’m thinking, are there bits and pieces of meteor that could be “outsourced” to a serverless script, for better scalability?
For example, is the computing power required for oplog-tailing possible to shift to a serverless architecture?
Perhaps the whole topic is moot, I don’t know, but I’m curious 
I have the same question too. I just picked up meteor last night.
Oplog tailing is not possible to be made serverless, and it does not make much sense, I believe. And it’s not the use case for a severless function, I think it would be very expensive also (even though in general severless is cheaper).
CRON jobs, email sending, webhooks, and server side routes are all the things you could go serverless. All kind of microservices could be serverless while your meteor app serves only the client and app related operations.
Maybe even methods, but I’m not sure of the benefits if it’s not a heavy workload method (like PDF generation).
The oplog tailing can be replaced by the great redis-oplog.
By the way, we use serverless (AWS Lambda, S3 and API Gateway) but to go full serveless may not be the best option too (as everything, it depends).
What if you had a Meteor method that wasn’t processor intenstive, but needs to be called thousands of times very quickly… like a real-time voting app? Something that would overload a normal Meteor server.
Is there some way to carve out a Meteor method easily without adding all the other Meteor parts in? Almost like a stripped down microservice made to be a lamdba function?
Sure, just get that lambda to update the db that Meteor listens to and it will read it from the oplog.
Though processing the oplog could become overwhelming, so you might want to use redis or batch the votes together for fewer total updates?