Best practice for versioning Methods?

help
1

What are the best practices for versioning Meteor.methods?
How do you do it?

EDIT:
I could think of a couple of ways:

  • sending a version parameter to the Method
  • making multiple Methods (sharing similiar code), naming them like myMethod_v1
  • a combination of the above, making a public Method that takes a version parameter, and inside that Method calling the appropriate function named myFunction_v1 inside a switch statement.
2

Namespacing with a slash has some benefits with converting to HTTP routes, I think. So, something like myMethod/v1.

I’ve seen a lot of code implemented with variations of foo/myMethod and then the next version gets iterated as newFoo/myMethod.

2 Likes
3

Thanks a lot for sharing your thoughts on this.
That’s something I didn’t think of and haven’t yet tested. Looks promising!

4

I recommend you read this post about REST versioning and the pros/cons of using versioning in the URI.

Make sure to have a default version, that is if the API is called without a version specified, it would use the stable release.

If you do it by including as a param (the Google Maps way), then you would have:

Meteor.call('/api/service/method') -> App.UserService.v2.getSomething()
Meteor.call('/api/service/method', {v: 1}) -> App.UserService.v1.getSomething()

And if you do it via the URI you would do:
/api/user/getSomething -> /api/v2/user/getSomething
/api/v2/user/getSomething
/api/v2/user/getSomething

As for organizing your code, I would putting all your services into a Services namespace, something like:

App = {
  Services : {}
}

You could also deploy a separate micro-service for each version if you want to get fancy!

Finally, be mindful of all the extra maintenance you have to do.

2 Likes
5

Thanks Sam, that’s a great example. Going the param way seems like the way to do it.