Anyways I’m going to try to stick to the actual topic, which is not whether one should stick to or leave meteor (I believe there have been a lot of threads like that), but rather: if you are interested in how one could do it at least in part with a pure node stack, here is an example. I really do believe that without ooth a significant aspect (user accounts) was missing. If you have questions about that I’m here.
Actually, I think the push to chase NPM & React hurt Meteor, pushing people really pumped about it off into a larger more loosely coupled ecosystem.
The huge benefit of Meteor was being tightly coupled, straight-forward, fast. It lost a lot of that, I think the approach could have been more well-engineered to increase retention rather than decrease.
The big magic of Meteor is the Socks<->Mongo<->AutoTracker stuff, everything else is pretty easy to accomplish using any pile of stuff that is simply nice to have but not integral to Meteor-magic. It’s the glue that makes the magic.
Of course, now that Serverless has added the Event Gateway and pub/sub… Meteor should go back to being used what it was made for: RAD.
Make your prototypes in Meteor, FAST. Then, instead of fighting for a year to make it production-capable and turning it into a huge mess… just drop the back end and go pro in like a week.
3 Likes
what do you mean by drop the backend and go pro in like a week? I think a lot of this discussion is about how do you replace that backend and still get that awesome reactivity. You know it with Socks -mongo - autoTracker but until a few weeks ago I had never dug in far enough to know Meteor used Socks.
Is all your server logic simple or is your destination easy to refactor to?
Pro as in production scale.
You have to sacrifice on the reactivity a bit…mostly giving up the mini-Mongo guessing abilities… that can probably be solved if one really needed to.
Essentially though, pub/sub/tracker/reactivity can all be simulated good enough for all but the most important cases by dropping API calls in place of Meteor.methods and using something custom…or like React or Angular for data-binding.
Might take more than a week… but my real point is… once you have a Meteor hit, or sale, or whatever… if you are really going to commit to it… it might be wise to decouple as much as possible and remove as many points of maintenance as possible.
Not that I’m saying Meteor can’t scale… but I might be saying Meteor doesn’t scale as fast, as well and as cleanly as using native cloud services.
Of course, most people start writing Meteor and have so much ridiculous fun doing it that they don’t want to then change anything. And a year later they’re like… F. This is a messsssss. lol
Whatever, that’s what they get for not being perfect Meteor architects from the start, right? /sarcasm
lol that’s the proof of how dumb an argument can be given when you don’t have a point!
homey any stack has it’s 30 days of honey moon, then chabam! you get to see the reality!
meteor isn’t perfect but it’s waaay better than any other shit out there!
Don’t trust me just go waste another 2 years there then come back and read this ok?
Yeah GraphQL and Apollo are like the opposite of intuitive and user friendly, tbh
3 Likes