Hi all,
Previously, methods of Meteor should be defined like this
Meteor.methods({ ‘method1’: function () { // code} });
and it was recommended to put the method definition on the sever side (/server) in order to hide the business logic of the system (this makes sense for me). The only problem of this way you don’t know the method name on the client side and you have to hardcode the name as a string in order to call it.
Meteor.call(‘method1’, params, (err, res) => {})
Therefore, in our current production, I make the string as the convention of “class_name.method_name” so it is easy to remember. However, the current documentation suggest using VallidateMethods
var method1 = new ValidateMethod({….},{…})
And this variable will be put into a file called module/methods.js
in order to be loaded both on the client and server. Then on the client, you can import the file and call it as
method1.call({param}, (err, res) {})
According to the documentation https://guide.meteor.com/methods.html
Note that Methods should always be defined in common code loaded on the client and the server to enable Optimistic UI. If you have some secret code in your Method, consult the Security article for how to hide it from the client.
This is the worst practice ever, since the business logic of the system or the company will be exposed to the client, even there is nothing to hide in term of security, you should not ever show the core functions of the system to the outsider. That is just not the thing for everybody to look at !!!
Also, Security is something a framework should enable by default, not asking the dev: you need to put this one on server or client in order to maintain it.
Please help me understand why we are going with this approach ? I don’t see any problem with the ValidateMethod, but the loading mechanism is weird to me