Live data from Hacker News

Meteor hits 1.0

meteor.com

181–190 of 250 posts

Re: Meteor hits 1.0

#181
post #163

Earlier quoted context omitted.

Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.

This is something that I've wrestled with when working with meteor, how do you execute privileged queries from the client? You can do a 'Meteor.call' to execute code on the server, but there is no way to shield the user from accessing the parameters used in the query. Traditionally, you would use a cookie on the client to authenticate and trigger the 'privileged' query during the http request cycle. As far as I can t…

In the same vein, there's no way to shield the user from accessing the parameters of a REST request. Which incidentally is easier to replay outside the browser than a Meteor.call().

Re: Meteor hits 1.0

#182
post #165

Earlier quoted context omitted.

If you read the docs you will see it's not implemented in an insecure way. The core meteor devs are pretty brilliant people, creator of etherpad, svn core contributer, early asana employee, these people aren't dummies they wouldn't do something that silly. Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.

> Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment. To be fair, I'm pretty sure the previous versions did have this issue -- it was just supposed to be ultimately fixed. I could be recalling incorrectly though.

It was fixed about two years ago in October of 2012, when they added the accounts system and allow/deny rules. Since then they've added additional security features such as the browser policy package.

Re: Meteor hits 1.0

#183
post #135

UI & API in one go? I just went through the tutorial on meteor.com, and I'm impressed with the speed of getting results. When I were to build another online app, I'd split that in building the frontend and the API composed from microservices, so that I'd be able to offer access through the UI and the web API. Is Meteor a good choice for this approach?

You can create REST points from Meteor collection very easily - http://www.meteorpedia.com/read/REST_API

Re: Meteor hits 1.0

#184

I absolutely love Meteor. I've been evangelizing it a lot this year. I wish someone at Meteor would reply to my emails. wink ;) me@danielfischer.com

I applied too, they were in a hiring freeze before 1.0 :-)

Re: Meteor hits 1.0

#185

I used my meteor developer account to get the free discover meteor book (via the limited time 1.0 promotion I guess), but I thought I did something wrong, tried again and ended up with two copies/purchases. It was free, but seems like a bug. Maybe detect if someone already got a book?

We fixed that. Thanks for pointing it out!

Re: Meteor hits 1.0

#187

Earlier quoted context omitted.

You can ask it either way. seems like their selling point is data binding + client syncing. Considering I can do that with Meteor, what's the advantage of using Ractive/React + Firebase?

For starters: 1. You can reuse your existing API, or choose the stack you're comfortable with (I prefer Python to Javascript and Postgres to Mongo) 2. They are being used in production by high traffic websites (Guardian and Instagram respectively), so they're more battle tested 3. Their press releases aren't loaded with buzzwords and hyperbole

You still need JavaScript on the client, so you have to switch context between Python and JS if you're a single dev, or have different team members work on the client vs. the server. Meteor is JavaScript everywhere.

Anyway, Meteor offers much more than data binding and client syncing. See http://www.meteorpedia.com/read/Why_Meteor

Re: Meteor hits 1.0

#188
post #35

Trying to figure out how it works. And saw this in one of the paragraphs: > No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database So you don't manage a database, but what happens to the data. Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?

By default, Meteor spawns a Mongo instance, with its own DB stored in the app directory, and your data is stored there. No database configuration necessary. Of course, if you have an existing Mongo DB, you can point your Meteor app to it.

Re: Meteor hits 1.0

#189

At this point, what percentage of web development can't/shouldn't be done with Meteor? It seems like everything else is obsolete in comparison. The only non-Meteor cases I can think of involve especially large scale.

See the section on "When not to use Meteor" at http://www.meteorpedia.com/read/Why_Meteor

Basically, if you need native MySQL support (some support already exists, but it's not in core), or if you need a web-site (SEO), not web-app.

Regarding scalability, by the time your app becomes so popular to exceed thousands of concurrent users, Meteor will have improved scalability again. They've done it a few times already with Mongo oplog tailing support and whatnot. If you already have a highly popular app, it will take you time to port it to Meteor too. So scalability may seem like a problem right now, but likely won't be one in, say, half a year.

Re: Meteor hits 1.0

#190
post #103

Earlier quoted context omitted.

Looks great but the site doesn't feel very snappy.

I haven't found a Meteor site that does yet, I would love to see an example of one where I don't have to sit at a loading wheel. Anyone?

http://meteor.com is very snappy. So are sites using fast-render, see https://meteorhacks.com/fast-render/
Post reply on HN