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.
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.
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.
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.
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.