Best way to expose server methods to client in a package


#1

I’m creating a package that’s basically wrapping a public API’s methods. My question is that since these API calls need to be made from the server, what’s the best way to create this package that exposes these methods to the app?
Right now as I was the only one using this, I’m putting them all in Meteor.methods, which is probably a horrible thing to do for a public package I’m guessing?
Should I just expose the object and functions on the server and let the user consume it whichever way they need to?


#2

A link to a public repo would help


#3

I too am wondering an elegant solution to this. If I understood you correctly, here’s your situation:

/client.js

Meteor.startup(function(){
  if (Meteor.isClient) {
    Meteor.call('testMethod'); // This causes a log message on the server console
  }
})

/packages/localpackage/method.js (no exports on package.js)

if (Meteor.isServer) {
  Meteor.methods({
    testMethod: function() {
      console.log('I am called from the app.');
    }
  })
}

So the problem here is, although I have not exported anything, testMethod is still available to the app.

What would be real nice though to have some means to hide the methods, better yet, export them selectively within the package’s exports.

So, does anyone follow any best practice to export (or hide) methods defined in the package code?


#4

Better yet, Meteor Methods really need a more modern pipeline. At the very least namespacing.


#5

I currently work around namespacing by naming the methods using dot notation, as in 'namespace.methodName': function(args){} but that’s not elegant at all, definitely not flexible, and does not help me in hiding them from the client :frowning: