But you forgot to mention NPM.
But there are libraries that implement that on top of Mongo.
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.
DDP can be rate limited. There’s a ddp-rate-limiter package, plus I’ve seen some techniques around here somewhere.
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.
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).
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.
:satellite: TRANSMISSION #20: Help pick topics
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.
:satellite: TRANSMISSION #20: Help pick topics
To be fair, deployment is never easy. Meteor helps though, because it takes care of all building.
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).
reactive: false wont help with scaling because it’s a client only property, see https://docs.meteor.com/api/collections.html#Mongo-Collection-find
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).
That’s a great solution, thanks for the suggestion!