Commit 7: Adding a Meteor Method for more secure operation

Meteor Methods run on, or can be called by, BOTH the client & the
server, so they should be placed outside of either the isClient or is
Server blocks.

Any Logic running on the client is essentially exposed, visible &
insecure. So, running that code on the server makes more sense in this
case. Meteor Methods do this.

Assuming that the code is intended to hit the DB, the server can now
validate & check data for errors & the return/sync data in MiniMongo on
the client.

In this case the update & insert operations on the History collection
will be moved out of the isClient block & placed in  Meteor.methods,
and are replaced by a call to the new Meteor.method.

However, now that the code is outside of the ‘user’ context, the
‘this._id’ attribute in the ProteinData is no longer valid. It is
replaced with a {filter} to the update call that sets the ‘userId:’ to
‘this.userId’.

Also, now that this code is being executed on the server, this type of
thing is where “latency” issues can start to arise.

Added delay, for testing/demo purposes…

Also, “insecure” (like autopublish) should be removed so that a user
can’t reach the DB on the server, via the browser console.

Finally, the ‘delay’ was added with the ‘this.isSimulation” clause…

The dom will update immediately regardless of whether the user’s input
or the outcome of the data processing is correct or not. This code
essentially predicts what will come back from the server… and if it’s
initial interpretation is wrong, the server will force a sync with
minimongo & update the dom.

This kind of technique could be used in other, more realistic ways,
such as providing the user with feedback prior to the completion of a
particular task, validation of data, etc., perhaps some UI related
effect… (!?!)