After 1 year of tremendous investment, my research over Meteor Framework shall be over now as I have just reached its bottleneck.
a. Meteor has no reactive aggregation support and is not going to happen this year. It does not support MongoDB 3.2 well enough to create a Relational Database. A Relational Database is almost mandatory when our projects just start to get larger in scope, and we start to look for data joins. We are not able to sort / search relational data in Aldeed:Tabular. That renders it being a plain Datatables plugin which really does nothing significant. I would not be dumb enough to roll out our own Join Indexes by using collection-hooks plugins. It is a very big disappointment and a time consumer.
In addition to (a): even the author of Aldeed:Tabular has given up supporting collection sorting / searching and has omitted the sorting button from their column headers (and then closed all relevant issues).
b. ACL management is a mess. We have Roles and Security and Allow/Deny , that is good. But as long as we rely too much on pub-sub mechanisms, we could not do anything more dynamic. Every sin relates to the relational database requirements when we used Publish-composite as the last resort for it.
c. Most importantly, Problem (1) is literally unsolvable. I tried so many plugins and even rolled out my own autoform fields, plugins, branching my own copy of Aldeed:Tabular and trying to fix…, nope. I see no hope.
I announce you today Meteor is my dead framework, considering it already running out its 2nd round investments. I’ve had enough.
Well you can’t cry for something that Meteor does not support from the get go. They do not support relational database as of now and that is a well known fact. I am not sure why did you choose Meteor in the first place if relational database is what your requirement needs.
Agree that mongo blows but there are usually ways around most of the deficiencies. And then there’s apollo in the works that some people are using already. This place is usually pretty helpful so my advice would be to post earlier and more frequently with questions and stumbling blocks in the forum of whatever framework you adopt next. Can’t help you even in this thread since there’s no real detail and it sounds like you’ve made your mind up. I get it that you are venting but it’s pretty useless to you and the rest of us.
Have you been following Apollo’s progress? This is MDG Inc.'s solution to your problems, and a big part of their future focus. Definitely check it out!
This is likely a case of “Maslow’s Hammer”: If all you have is a hammer, everything looks like a nail.
I used to be a big fan of relational databases. Sure they have a lot of pros over something like Mongo. And in some cases I’d still use them.
But I would like to get sneak peek at your schemas. If you try to create a relational database-like schema in Mongo you’re really going at it the wrong way. Mongo was never designed to support that. Mongo is all about embedding and replication. Joins have no place in Mongo. Nor should they. But 90% of all usecases that supposedly “require” relational databases can easily be redesigned to properly work with Mongo.
If you want some pointers on how to redesign something for Mongo, feel free to message me, or reply here.
And as @hwillson mentions: Apollo will add support for relational DBs.
It is abundantly clear that you did not do enough research before investing way to much in a framework that is apparently useless to you.
Don’t diss a perfectly good framework just because you misunderstood the basic requirements of it…
I feel like these stupid threads are more and more irrational sided with less and less fun or constructive discussion they brought once in a past. StackOverflow accounts are paid now?
I dare say that your basic premise is right but you got it backwards.
Let’s face it: The stuff you’re doing on a normal webserver is highly relational. You have users. You have documents which belong to said users. You have goods. You have baskets. You have items in those baskets which in turn belong to customers.
And so on.
This “Throw everything into one document!” motion is one of the most harebrained ideas out there. Because you now have to keep track of all the places where, say, a good might pop up and update all those references in case something changes (like the price, for example). And god forbid you miss one.
Relational DB? Update the single table and you’re done.
Why on earth are we throwing away DECADES of research in relational DBs only to re-invent the wheel in non-relational DBs … very badly?
There’s a reason why MongoDB decided to implement aggregations.
I think you are being overly dramatic; we’ve been building in Meteor for 1.5 years with more than a dozen engineers and it is going very well (here is a talk at Meteor Night I gave a couple months ago).
(a) You can do reactive aggregations with this package, although it won’t be super performant. More generally, if you can think of a minimal Mongo query you can call observeChanges on to determine when the result set of your aggregation may have changed and retrigger running the aggregation (using the low-level publications API, this.added, this.changed, etc.), you could actually have a reasonably efficient reactive aggregation.
If you want to do collection sorting and searching I recommend EasySearch.
(b) I’m not sure what you mean by this. But just as a side-note, keep in mind that allow/deny rules do not restrict publications OR vice-versa. I also don’t understand what the issue with Publish Composite is; it has been working extremely well for us.
There are certainly issues with Meteor, but we haven’t found a single one that is insurmountable (or even all that bad). The productivity gains we’ve had with Meteor are huge and have allowed us to build a HUGE product really quickly.
Because… document-oriented databases were actually invented before relational DBs and have just as much research? Because moving the JOIN from a read operation to a write operation optimizes for lookup speeds? Which enables streaming apps and reactive updates? Because documents are a vastly better format for hierarchical, fuzzy data than tables?
Meteor was originally implemented as a data visualization stack for big data. Don’t trash it because people are trying to use it for purposes outside what its architecture is designed for.
Locking this thread. Let’s keep posts focused on help/constructive discussion around particular issues. There are more helpful ways to frame even negative opinions about Meteor that keep this community a pleasant place to be.