Meteor is great! Why is not more popular?

[trusktr]

@gusto

especially with kinda-legacy Atmosphere packages.

But you forgot to mention NPM.

[trusktr]

@XTA

MongoDB has no support for real relations and transactions

But there are libraries that implement that on top of Mongo.

[trusktr]

@gusto

But saying it’s not popular is way too much. It’s got more Github stars than any other Node-based framework, even Express.

Seriously! That’s pretty strong numbers there. Why do we see so many posts like “why did Meteor fail”, or this very thread??? Like, really?

Why is it not more popular?

Hmmmm, maybe because it is the most popular already? Just go code, and use what you like.

[trusktr]

Agreed on all of that. The DDP protocol gives lower volume sites really amazing functionality that can’t be found elsewhere. That lower volume requires more underwriting and resources per user, so it’s ideal for established businesses with external revenue sources. Lots of projects behind closed doors.

DDP can be rate limited. There’s a ddp-rate-limiter package, plus I’ve seen some techniques around here somewhere.

[XTA]

@trusktr

But there are libraries that implement that on top of Mongo.

Sure, but if “transactions” are an important requirement within your application (f.e. financial app), you can’t rely on libraries like that. The database has to take care about the relationship between all docs. You can also remove all unique indexes and check in your application if a document with the same _id already exists. This may work most of the time, but there is also a higher chance that duplicate documents will be added.

[trusktr]

All this stuff is just software. The “transactions” you speak of are just software, even if not implemented in JavaScript, but they are nonetheless as susceptible to programmer bugs as anything else written in JavaScript. And just because it’s JavaScript doesn’t mean it can’t work. Make it work with no duplicates, write good unit tests so it is unlikely to break, and benefit.

[XTA]

I’m not talking just about Javascript, it’s never a good idea to put these validation logic (only) in a application. It’s the job of the relational database too guarantee referential integrity and keep all indexes correct. I don’t think that any financial application programmer would say “Great, let’s write this logic in our application and forget about all those features in the database”.

[trusktr]

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. :}

[XTA]

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.

[awatson1978]

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.

[gusto]

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).

[methodx]

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:

1. MongoDB lock in.
2. 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.

[markoshust]

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.

[XTA]

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.

[andrewleschinsky]

To be fair, deployment is never easy. Meteor helps though, because it takes care of all building.

[andrewleschinsky]

…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.

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).

[dr.dimitru]

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

[tomsp]

reactive: false wont help with scaling because it’s a client only property, see https://docs.meteor.com/api/collections.html#Mongo-Collection-find

[morganpattens]

I’ll probably just repeat things… But for me personally:

1. No official Vue.js support. Why still ignore it? It now has more Github stars than Angular or Meteor for that matter.
2. MongoDB - no thanks, I need my relations. I guess I’ll have to wait and evaluate Apollo.
3. 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.

[morganpattens]

That’s a great solution, thanks for the suggestion!