Populate Query Options with Async Waterfall

Not sure why you are looking to match "after" population when the value of _id is what is already stored in the "user" property "before" you even populate.

As such it's really just a simple "query" condition to .find() instead:

async.waterfall([  (callback) =>    User.findOne({ 'username': username }).exec(callback),  (user, callback) => {    if (!user) callback(new Error('not found'));  // throw here if not found    // find user's feed    Feed      .find({ user: user._id })      .populate('user')      .exec(callback);  }], function(err, docs) {  if (err) {    return next(err);  }  console.log(docs);});

Keeping in mind of course that the .findOne() is returning the whole document, so you just want the _id property in the new query. Also note that the "juggling" in the initial waterfall function is not necessary. If there is an error then it will "fast fail" to the end callback, or otherwise pass through the result where it is not. Delate "not found" to the next method instead.

Of course this really is not necessary since "Promises" have been around for some time and you really should be using them:

User.findOne({ "username": username }) .then( user => Feed.find({ "user": user._id }).populate('user') ) .then( feeds => /* do something */ ) .catch(err => /* do something with any error */)

Or indeed using $lookup where you MongoDB supports it:

User.aggregate([  { "$match": { "username": username } },  { "$lookup": {    "from": Feed.collection.name,    "localField": "_id",    "foreignField": "user",    "as": "feeds"  }}]).then( user => /* User with feeds in array /* )

Which is a bit different in output, and you could actually change it to look the same with a bit of manipulation, but this should give you the general idea.

Importantly is generally better to let the server do the join rather than issue multiple requests, which increases latency at the very least.