Live data from Hacker News

Meteor hits 1.0

meteor.com

161–170 of 250 posts

Re: Meteor hits 1.0

#162

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

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.

Well to be fair, even smart people can make mistakes and miss things. But Meteor is open source, so if the person you responded to is going to question the security model, they can look at the actual code and see if there is an issue. That's the best way to prevent security issues, looking at the code for bugs, mistakes, and assumptions.

Re: Meteor hits 1.0

#163

Earlier quoted context omitted.

The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers . Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the…

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 tell there is no way to do this with Meteor. Another way to phrase it is there is no authenticated server-side state modeling the client.

Re: Meteor hits 1.0

#165

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

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.

Re: Meteor hits 1.0

#166
post #44

Earlier quoted context omitted.

Meteor just hit 1.0 and is not the type of framework you can just start including in your stack. You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack. As new startups who use Meteor grow you will see those large-scale projects come about.

So, to put it glibly, the only people who will use Meteor for large-scale projects are those who have no choice?

No, the people who use meteor for big projects are those that started using it when they started it as a small project.

Because if you started a small project in something else, it is not easy to change it to Metero later.

What he said was quite clear.

Re: Meteor hits 1.0

#168

Earlier quoted context omitted.

By “goads” do you mean “gods” (in, like, the Battlestar Galactica sense) or is that supposed to be “gonads”, as in junk? Just askin.

"Apparently, "to kick against the goads" was a common expression found in both Greek and Latin literature—a rural image, which rose from the practice of farmers goading their oxen in the fields. Though unfamiliar to us, everyone in that day understood its meaning. Goads were typically made from slender pieces of timber, blunt on one end and pointed on the other. Farmers used the pointed end to urge a stubborn ox into…

the phrase was translated by King James as "kick against the pricks" [1] src: http://www.gotquestions.org/kick-against-the-pricks.html

Re: Meteor hits 1.0

#169
post #90
post #44

Earlier quoted context omitted.

Meteor just hit 1.0 and is not the type of framework you can just start including in your stack. You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack. As new startups who use Meteor grow you will see those large-scale projects come about.

So is it a PaaS like Google App Engine? Is it just an MVC like angular or ember?

No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits the actual server response. Client changes to the data are immediately effected in the browser DB, while the change is authorized on the server, synced to other server instances with MongoDB oplog, and then pushed down to all clients subscribed to that data. The templating engine is then reactively informed of the data change, and the DOM is updated at the lowest level possible such as modifying an individual text node.
Post reply on HN