Meteor methods loading mechanism


#1

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


#2

Did you consult the security article for how to hide secret code? Also I don’t agree that it’s a good idea to hide as much code as possible, as long as your app’s data is secure.

In today’s apps you get a lot of speed benefits by moving as much code as possible to the client, and it’s only up to the server to handle security and persistence.


#3

Yes, I read the Security article. My point here is: There should be the balance between the logic between the client and the server and it is good to put more “weight” on the server than on the client, since you don’t really know what will happen really in the client side most of the time.
If I work as an indie developer, just making my mobile app connect with a server, then it is fine (which I am doing it at this moment)
However, if my company want to develop a system for all the sale people working and input the transactions, even connecting with the bank, then just a small wrong step could lead to the disaster. Besides, exposing every business flow of the company to the client but having a good speed as the compensation is not a good reason for people to come and play with the framework (and i know that you can always put the code under /server in order to hide it again, but the recommendation from the documentation will mislead the new users)


#4

I think if you want an entirely server side API that’s just not using Meteor to its full potential. Perhaps we can make it easier to make server only methods with validated method though, I’m open to ideas!