Really the only difference between relational stuff in an SQL database and a relational library on top of Mongo is that SQL has years and years behind it. It’s only a matter of time before these newer DB’s have solid built in relational stuff or community libraries built on top of these DBs that are just as solid.
It’s just code, you don’t have to stick it in your app, you can stick it in an NPM repo and encourage contribution from the community, and make it a re-usable library.
The requirement of having transactions in an app doesn’t determine if meteor is good or not. Meteor is quite great at what it does, but it may not have absolutely everything that you need.
That’s what tools are about: picking the right one for your requirements. :}
Yeah, but I only said that the missing relational thing could be a reason why some people don’t choose Meteor (because the thread is about such reasons), I didn’t say that you should not use it because it lacks of this feature. We are working great with Mongo + Meteor and compared to our old LAMP stack we can even provide more features and also have a better scaling.
Agreed with Joe. Before SQL databases became the norm, teams had to implement transaction logic on their own in the application layer. The healthcare industry has been implementing application level transaction logging in our HIPAA audit logs for decades. It’s perfectly manageable.
It’s like complaining about driving a manual transmission instead of an automatic. Seems incomprehensible and unnecessary until you learn a few basic skills, then it’s trivial and it’s like ‘why was it ever a big deal?’… until you drive 500,000 miles, and literally get fatigued doing the shifting. Rolling your own transaction checks is just a matter of a lookup and a callback.
I didn’t forget about NPM. When I talk with other Vue developers about Meteor, they don’t get satisfied with “Meteor has also NPM”. They want to hear “I can do everything with just NPM without using Atmosphere”, which will take a long time for a full transition to take (especially that currently there’s no agreement yet on how to make this transition).
As people have already mentioned, there were issues in the past that have since been addressed. Things were moving very fast in the JavaScript / Node world and you can’t really fault MDG for not being able to perfectly predict how all that would play out. Everything considered, right now Meteor is in a pretty great place, and I mean that objectively. It fully supports NPM, React works extremely well with it and code splitting is on the way. Those are just the highlights.
Most people still have an issue with two things:
MongoDB lock in.
Realtime everything is very resource intensive at scale.
Apollo addresses both of those issues so we’ll just have to wait and see where things are this time next year. Personally, I’m very happy with my decision to go with Meteor. I’ll be moving from pub/sub over to Apollo / GraphQL in the coming months to get away from everything being real time. After that, I don’t think I’ll have anything to complain about.
I’m one of those guys that doesn’t understand the “scaling issues” of Meteor. AFAIK, the reactive: false property within publications was added years ago, and if you still have issues with large publications, it’s very easy to throw the db call into a Meteor method that doesn’t have to deal with the pub/sub scaling issues. Essentially, this transforms the db call to the backend so it works just like any server-side language, but pipes the response over DDP instead of REST. This has much faster responses than the request->response flow of any other server side language.
One thing we do is to transform sub documents, which don’t need to be reactive, straight into the published doc. So we don’t need any method calls or an additional publish to connect relational data. I’m also wondering about scaring scaling issues. We’re running a Meteor app with ~1.5k concurrent users on a single VPS (+ one for the database) and also using individual subscriptions for each visitor. So only performance issues we had so far were missing/wrong indexes in the database.
This is exactly how we are doing it in our team - we decided from the start to not use pub/sub at all, and it works great, and scaling should be trivial (we haven’t tried yet).
I’ll probably just repeat things… But for me personally:
No official Vue.js support. Why still ignore it? It now has more Github stars than Angular or Meteor for that matter.
MongoDB - no thanks, I need my relations. I guess I’ll have to wait and evaluate Apollo.
DPP is for me the USP, but few apps will need reactivity as a core feature. Most reactivity use cases for my projects are limited to notifications.
Alternatives haven’t been standing still. I’ve always used Rails, and now with 5.1 it finally officially supports npms, Webpack and Vue.js and reactivity through ActionCable. Which means 3 less reasons to use Meteor (or actually 2, since Meteor doesn’t officially support Vue unlike Rails).
Meteor development seems slow, because of all the focus on Apollo. I hope when Meteor 2.0 arrives, it kicks some serious arse! Thing I love about Meteor: Javascript everywhere, a cohesive stack instead of cobbled together NPM modules and a full test suite is finally getting attention.
Were your slow build times happening on windows or mac?
I started developing Meteor on windows and got stuck with bugs and very very slow builds,
cloning the project to my mac as a last effort before ditching…
got very fast builds and no bugs.
So we enjoy Meteor’s reactivity and pub/sub based on DDP together with the benefits of a relational database combined with the atomicity, consistency, isolation, and durability (ACID) provided by transactions.
The claim that using Meteor results in MongoDB lock-in is a myth.
Sure, but it seems to be a third party package which isn’t used by many. I guess the most (business) people take a look what is officially supported and maintained to be “on the safe side”.
Do you think npm packages have more credibility than atmosphere packages? I’ve seen great and dire in both ecosystems, yet npm seems to be more acceptable. Why is that?
