Express生产环境中Async Await与Callback的最佳实践及差异

Hey there! Let's break this down clearly since you're digging into Express production best practices (great call focusing on avoiding sync functions, by the way).

Which approach fits production best practices? #

The third option—using async/await without callbacks—is the one that aligns perfectly with modern Express production standards. It's clean, maintainable, and avoids the pitfalls of the other two approaches.

Let's break down the differences between each method: #

1. Callback-only, no async/await

exports.getSubjectById = (req, res) => { 
  const subjectId = req.query.subjectId; 
  Subject.findOne({ subjectId: subjectId }, function (err, subjects) { 
    if (err) { 
      return res.status(400).json(err); 
    } 
    return res.status(200).json(subjects); 
  }); 
}

This is the "old-school" Node.js callback pattern. While it's asynchronous (so it doesn't violate the "no sync functions" rule), it suffers from poor scalability for complex logic. If you need to chain multiple database calls or add more steps, you'll quickly end up in "callback hell"—nested callbacks that are hard to read, debug, and maintain. Error handling also becomes fragmented, as each callback needs its own err check.

2. async marked function, but still using callbacks

exports.getSubjectById = async (req, res) => { 
  const subjectId = req.query.subjectId; 
  Subject.findOne({ subjectId: subjectId }, function (err, subjects) { 
    if (err) { 
      return res.status(400).json(err); 
    } 
    return res.status(200).json(subjects); 
  }); 
}

This is essentially a redundant, useless pattern. Marking the function as async makes it return a Promise, but you're not leveraging any of the benefits of async/await here. The callback logic runs exactly like it would in the first approach, but now you've added unnecessary overhead by wrapping the function in a Promise. It doesn't fix any of the readability issues of callbacks and serves no practical purpose—avoid this entirely.

3. async/await without callbacks

exports.getSubjectById = async (req, res) => { 
  const subjectId = req.query.subjectId; 
  const subject = await Subject.findOne({ subjectId: subjectId }); 
  if (!subject) { 
    return res.status(404).json({ error: "no subject found for this id" }) 
  } else { 
    return res.status(200).json(subject); 
  } 
}

This is the gold standard for modern Express controllers. Here's why:

• Readability: Asynchronous code reads like synchronous code, making it easy to follow the flow of logic even for complex operations.
• Maintainability: No nested callbacks mean you can easily add new steps or modify existing ones without rewriting entire blocks.
• Error handling: While your current code doesn't have it, you can wrap the logic in a try/catch block to handle all errors in one place (critical for production to avoid unhandled Promise rejections):

  exports.getSubjectById = async (req, res) => {
    try {
      const subjectId = req.query.subjectId;
      const subject = await Subject.findOne({ subjectId: subjectId });
      if (!subject) {
        return res.status(404).json({ error: "no subject found for this id" })
      }
      return res.status(200).json(subject);
    } catch (err) {
      return res.status(400).json({ error: err.message });
    }
  }
  

• Compliance with best practices: It's fully asynchronous (so it doesn't block the event loop, which is what the "no sync functions" rule is all about) and uses modern Node.js syntax that's widely adopted in production environments.

内容的提问来源于stack exchange，提问作者Mayur Aitavadekar