Skip to content
tmeasday edited this page Sep 25, 2014 · 2 revisions

Excerpt cut from a DM post that I think we should formalize

Writing Client/Server libraries with common interfaces

So why did we bother with all those details about the environment if you don't need to know about them? Do we just love to info dump here at Discover Meteor? Well we do, but it turns out there's an important use for it. Writing asynchronous server libraries!

Why on earth would we want to do that?

Consider Meteor’s builtin HTTP library. On the client, it's asynchronous and takes a callback, because it has to be (no fibers on the client, after all).

On the server, it can be asynchronous OR sync depending on whether a callback is provided or not. The reason for this is because there are times when you want to share http-calling code between client and server and it's much easier to do so with asynchronous code in both cases.

Here’s the code we’d need to write if it couldn’t take a callback on the server:

var dealWithResult = function(result) {
  // do whatever we do
}

if (Meteor.isServer) {
  var result = Http.get(url);
  dealWithResult(result);
} else {
  Http.get(url, function(err, result) {
    dealWithResult(result);
  });
}

Even more of a mess, especially when dealing with errors!

So for that reason it makes sense to make your fancy lib similarly flexible. Perhaps Meteor._wrapAsync should do this for you (hint hint) but for now you'll need to wire it up yourself. See google API for an example of this.