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.
1 Like
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.
1 Like
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.
6 Likes
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.
4 Likes
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.
To be fair, deployment is never easy. Meteor helps though, because it takes care of all building.
1 Like
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).
Well, I’m agree with @andrewleschinsky - deployments is never easy. And MUP isn’t a silver bullet too.
Here is something to start with: Gist deploy.sh
reactive: false wont help with scaling because it’s a client only property, see https://docs.meteor.com/api/collections.html#Mongo-Collection-find
1 Like
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.
1 Like
That’s a great solution, thanks for the suggestion!
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.
Yes, it’s slow on Windows. But saying buy a Mac is not really a good solution ;).
What’s your Windows configuration (processor, memory, SSD speed)?
Can you provide more details on the webserver in your basement.
1 Like
My business uses Meteor with MySQL thanks to vlasky:mysql, originally based on numtel:mysql.
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.
7 Likes
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?
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?
I agree with Rob. There is absolutely no guarantee that NPM packages will be better. Also, most of the time people have no need for MySQL and are fine with using MongoDB. In the end MySQL and MongoDB are just flavors that server different needs, but also a lot of common needs.
There is reasoning of MDG to go with Mongo as the default database. One of them being that a new developer will be able to use javascript and create a webserver without having to touch any database. It comes out of the box. Mongo’s document approach makes that very easy as opposed to MySQL. So there is simply less demand for a MySQL library in combination with Meteor.
2 Likes