No, I haven’t, I always had to decouple bottlenecks into independent scalable services, so far.
The problem I had was that every new connection would open a new ddp socket, that somehow would impact in around 0.5MB RAM increase in the Mongo router. Going from subscriptions to only methods would only alleviate the problem.
I remember I would max out Galaxy’s resources and still, when the webapp was mentioned on a TV show, and thousands of connections would bubble up in minutes, everything would melt. I remembering using the biggest Galaxy’s VM’s and each one would handle no more than 400~500 connections at a time, having a maximum of 25 instances available. I would also hitting limits in mlab router sizes to handle the load.
I admit I’m a DevOps novice, but this wasn’t easy to fix, In fact, I couldn’t.
How would a scenario like this be handle gracefully today in Meteor?
Exactly, at the end I want every endpoint of my app to be served statically from a CDN, then hydrate from that. Not even SSR beats that.
Vendor lock-in is not an issue for both Meteor and Next.js, thankfully.
I can’t.
But using
const { data, error } = useSWR("/api/whatever", fetch);
will be called on the client AND/OR server without you worrying about it in Next, that’s sweet.
Thanks for proving me wrong. Still, I just shared my experience a few years ago, when building a marketplace in Meteor maybe was not the best idea to scale it out easily.
Hope that today is different, and I would love for anyone to drop a nice article/doc about how this can be done, in a way that follows Meteor simplistic spirit. Because if even today, to scale Meteor you need to turn off so much of that sweet magic and easy of development/deployment, then I’m back to my point, I would use Meteor for niche applications, MVP’s, or when use case allows for easy tweaks that scale easily.
Thanks, @alawi
P.S: I’m currently just trying out Next.js, not married to it, have no idea what scaling challenges I will have here, but on papers seems to be structured in a way it’s easier to do so.