Node.js / Express.js-我應該將所有功能包裝在一個新的承諾中嗎？

Question

快速文檔生產最佳實踐：性能和可靠性說：

不要使用同步功能

同步函數和方法會阻塞執行過程，直到它們返回為止。 對同步功能的單個調用可能在幾微秒或幾毫秒內返回，但是在高流量的網站中，這些調用加起來並降低了應用程序的性能。 避免在生產中使用它們。

所以我的問題是，在node / express的上下文中，如果我有一個接受一些靜態值並返回計算結果的函數（我通常將其視為“同步函數”），那么最好的做法是將該函數包裝在內部一個new Promise並resolve結果，還是會造成任何不必要的重大開銷？ 例如：

當前：

//inside my index.js
var myArgument = 'some long string';
var myResult = myFunction(myArgument);

function myFunction(myArgument){
  var thisResult;
  //some calculations
  return thisResult;
}

新功能（改進）？

//inside my index.js
(async function() {
var myArgument = 'some long string';
var myResult = await myFunction(myArgument);
});

function myFunction(url) {
  return new Promise((resolve, reject) => {
    var thisResult;
    //some calculations
    if(thisResult){
      resolve (thisResult);
    } else {
      reject (null)
    }
  });
}

Answer 1

簡短的回答：不。

該文檔討論的是不使用諸如NodeJS文件系統中的readfileSync之類的功能的同步版本或例如bcrypt.compareSync。 同步調用會阻塞nodeJS中的事件循環。 因此，在等待同步調用完成時什么也不會發生。 這一方法完成時，整個程序停止。 這在像nodeJS這樣的單線程系統中是不好的。

沒有理由用回調或promise包裝只是簡單的計算或數組操作的函數。

它只是說，如果有一個庫/方法提供該方法的同步版本，請嘗試避免該方法。

檢出： https : //nodejs.org/en/docs/guides/blocking-vs-non-blocking/

Node.js中的JavaScript執行是單線程的，因此並發是指事件循環在完成其他工作之后執行JavaScript回調函數的能力。 任何期望以並發方式運行的代碼都必須允許事件循環在發生非JavaScript操作（例如I / O）時繼續運行。

例如，讓我們考慮以下情況：對Web服務器的每個請求都需要50毫秒才能完成，而50毫秒中的45毫秒是可以異步完成的數據庫I / O。 選擇非阻塞異步操作將為每個請求騰出45毫秒的時間來處理其他請求。 僅通過選擇使用非阻塞方法而不是阻塞方法，這是容量上的重大差異。

事件循環不同於許多其他語言中的模型，在這些語言中，可能會創建其他線程來處理並發工作。

關於將所有內容包裝在promise中的額外開銷。 答案是否定的。

您不會在

function sum(x,y) {
  return x+y
}

const ans = sum(1,2)
console.log(ans) // 3

和

function sum(x,y) {
 return Promise.resolve(x+y) // Shorthand for your new Promise
}

sum(1,2).then(ans => {
  console.log(ans) //3
})