-
Meteor apps, by default, have an insecure package. It's best to keep this in at the start to make development easier but ulltimately this will need to be removed and secure operation need to be added manually.
-
Same with a package called autopublish. This publishs all data up to the clients automatically. Ultimately this needs to be removed and publish/subscribe needs to be managed manually.
-
Meteor Methods can be used to make things more secure. Meteor methods use RPC calls to methods defined on the server. The nice thing is, you also define them on the client. So, when you call a meteor method it executes on the client and the server - the client returns instantly then, once the server returns, if there's a difference, it will patch up the client. (This is latency compensation).
-
As mentioned before, some things are defined on the client, some are defined on the server, and some are defined on the server and the client. It's a bit hard to get you're head around this at the start but it becomes clear after a while.
-
Meteor has a few conventions in file/folder structure that it follows. First off, you can have things very loose and just have a JS file with the relevant events and helpers for Templates - client code and server code is defined like so:-
if (Meteor.isClient) {
// client code here
}
if (Meteor.isServer) {
// server code here
}
// Everything outside of these blocks executes on the server **and** the clientHowever, as things get more complex you need to break things out into folders. There are some special folders:-
server- everything in here executes on the serverclient- everything in here executes on the clientlib- everything in here is loaded first
Other folders are just executed on both the client and the server. These can really be called anything but there are some conventions here:-
-
collections- Add your collections here -
For routing iron-router is pretty much the standard. Note routes are defined both in the client and the server.