Thanks! Regarding the security aspect, the basic principle of data security with Meteor is to only give the client what it needs.

So while it's possible to send the whole database and let the client filter it, what you really want to do is only send the subset of data that a particular user should have access to.

As long as you do this, I don't see why Meteor would be any less secure than any other environment.

Put another way, Meteor does give you the means to shoot yourself in the foot, but that doesn't mean you should use them.

Yes, basically meteor is just an RPC. You make it secure. Out of the box it scaffolds for you, which isn't secure.

I'm not sure that's entirely fair on meteor. They do provide a security layer: http://meteor.com/blog/2012/10/18/meteor-050-authentication-...

Although new apps come with the autopublish package turned on (which violates a lot of the security), any real application will have this package turned off.

Yes, I'm aware of the packages, `insecure` and `autopublish`. Once you remove these, you end up writing RPC methods (for the most part). This is a good thing.

From meteor's docs @ http://docs.meteor.com/#dataandsecurity:

Data and security

Meteor makes writing distributed client code as simple as talking to a local database. It's a clean, simple, and secure approach that obviates the need to implement individual RPC endpoints, manually cache data on the client to avoid slow roundtrips to the server, and carefully orchestrate invalidation messages to every client as data changes.

So, meteor helps you write RPCs, imo. Just like most frameworks do.

Also: http://docs.meteor.com/#meteor_call

I guess it depends on what you mean. If you mean data sent from the server -> client, then no, subscriptions[1] are a lot more powerful than simple RPC calls for data.

If you are referring to data sent from the client -> server, then yes, everything is an RPC call. But it's a bit disingenuous to say "basically meteor is just an RPC", when meteor does a lot of work to set up (and secure) the RPC calls you'll do most commonly: CRUD operations on the database.[2]

That is to say, calling `posts.insert({title: 'A new post'})` in your client side JS _does_ end up calling a method called `posts/insert`; but that method is wired up for you, including checking the allow/deny rules you've specified and tracking the user who is doing the inserting for you with no plumbing work required on your part.

I wouldn't say that's something most frameworks do.

[1] http://docs.meteor.com/#publishandsubscribe [2] http://docs.meteor.com/#collections

[meteor dev] I explained a bit more of the philosophy behind the Meteor security model in a Stack Overflow answer: http://stackoverflow.com/questions/13331836/meteor-userid-is...

And of course, http://meteor.com/authcast if you haven't seen the 0.5.0 screencast.

A suggestion: avoid screencasts for communicating information related to software as much as possible.

Text please.

I will never watch a screencast about programming unless it's Rich Hickey.

Thanks for the Stack Overflow link, I'll take a look!

I always prefer text as well. I can get the information quicker and if I'm looking for a particular piece of information I don't have to scrub through a whole screencast.

We need both. Many devs love the screencasts.