News for hackers. Stuff that matters.
Re:Why Meteor by woah on Saturday October 25, 2014 @03:03AM (#8507465)
I tried some stuff with Meteor a while back. I was very excited about the concept and really felt on board with the 'new way to write apps' stuff. It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page.

This requires joins. Mongo doesn't have joins, and Meteor doesn't even have fake joins, like Mongoose's 'populate'. There has been a lot written in the Meteor community about faking joins, as it is a persistent problem. First, I tried template helpers, but these are impossible to put into a nested template.

I looked at 5 different open source packages for serverside fake joins, but ended up doing a clientside solution (to get a feel for the 'basic' way to do things). This solution involved several functions on the clientside router, that would be called several times, with different data available each time. It is a convoluted thing to do, no matter the method.

Another thing I tried to do was purely clientside databinding, to populate the author badge in real time as the user fills a form. It's trivial to bind data to the database and have that update in realtime, but I wanted to hold off saving anything until the user hit the save button. Again, a simple task got weird. I ended up using an un-synced database collection, then saving to an identical, but synced collection.

I'm not writing off Meteor completely, but I ended up moving away from it. Node.js and a solid frontend framework have slightly more boilerplate, but are generally very flexible for whatever it is you want to do. In retrospect, one of the best things about Meteor is the one-line auth setup. This is usually a big pain, and it was nice to have it be so easy.

Re:Why Meteor by swartkrans on Saturday October 25, 2014 @04:07AM (#8507567)
> It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page.

Meteorpedia, the site in the OP accomplishes this without joins. It has authors for pages. You just have to set up your schema in a way that's different from normalized SQL.

Re:Why Meteor by primigenus on Saturday October 25, 2014 @07:28AM (#8507884)
Could you make the source code of your app available so we (people who use Meteor) could take a look? Nothing that you're doing sounds hard or impossible with Meteor and I'd be glad to look through the code and help you figure out what to do to get it to work right.
Re:Why Meteor by thawkins on Saturday October 25, 2014 @07:47AM (#8507916)
Airsoc.com Only uses mongodb, people can post stories, or articles, we show author and feed source information on the page, but there are no joins. I have never found the need to use joins anywhere. Carefull schema design makes them unnessecary.
Re:Why Meteor by matthewmacleod on Saturday October 25, 2014 @10:31AM (#8508307)
The irony of course is that you end up implementing careful schema design so that you can use a schemaless database.
Re:Why Meteor by findjashua on Saturday October 25, 2014 @11:35AM (#8508469)
You're confusing schema not being enforced for schema not being present. Any non-trivial app would require you to define a schema for your models, irrespective of whether you're using a relational database like Postgres or a document store like Mongo.
Re:Why Meteor by purpletoned on Saturday October 25, 2014 @09:32AM (#8508153)
Did you try denormalizing the author's badge's url field? IIRC, that's what the docs recommended.
Re:Why Meteor by notastartup on Saturday October 25, 2014 @06:11AM (#8507752)
Along with my team, we built an enterprise app with meteor.js. Huge waste of resources.

I almost find that the single biggest barrier to fully investing in is Mongodb. The queries are hideous. But Meteor is heavily invested in Mongodb and I'm afraid this is what will kill it.

Re:Why Meteor by Tarang on Saturday October 25, 2014 @07:08AM (#8507843)
Meteor recently acquired FathomDB. Additionally SQL is on the cards too (http://roadmap.meteor.com) they're not exactly heavily invested in MongoDB. If anything it looks like they're giving users the choice of what to use.
Re:Why Meteor by spyder on Saturday October 25, 2014 @07:18AM (#8507862)
SQL is on the to-do cards since "Nov 2, 2012" ... and lot of the comments are requesting it as critical feature
Re:Why Meteor by notastartup on Saturday October 25, 2014 @04:52PM (#8509360)
If you've used other db like OrientDB, you can use SQL to query documents. Even if MongoDB added this I wouldn't rely on it, as there have been many deployments that couldn't scale properly due to MongoDB and ended up switching to another vendor. It already has the reputation of being snake oil salesman of the DB world.
Re:Why Meteor by victorhooi on Saturday October 25, 2014 @07:25AM (#8507878)
I'm curious what you meant by MongoDB being a barrier to entry?

My understanding was that, for better or worse, Meteor abstracts a lot of that from the developer.

Were you unhappy with the queries that Meteor generated?

Or did you find your application did not perform well, or in the way that you expected, and you believe this to be the result of the queries?

Or were there issues on the deployment/operations side of things?

Re:Why Meteor by woah on Saturday October 25, 2014 @03:03PM (#8509017)
Meteor in no way abstracts MongoDB away from the developer. Meteor is very tightly bound to Mongo, and Mongo permeates every aspect of coding in Meteor.
Re:Why Meteor by greggdourg on Saturday October 25, 2014 @03:08PM (#8509030)
I tried some stuff with exercise a while back.

I was excited and did 4 push-ups but it is a convoluted thing to do.

I'm not writing off exercise completely, but I ended up moving away from it.

Re:Why Meteor by woah on Tuesday October 28, 2014 @02:12PM (#8522480)
Wow you are like, a new Shakespeare