NodeJS應用架構最佳實踐

Question

我們有 Nodejs 項目，其中一個是主項目。 我們在其他項目中使用這個（主項目）功能。 我們將我們的主項目安裝為 package 和 NPM 到其他項目，然后使用我們需要的功能。

但是這種方式在主項目和其他項目之間產生了許多緊密的依賴關系。 每次我們更改主項目時，我們都需要在其他項目中更新它的版本，並在其他項目中安裝 NPM。

請告訴我您在這種情況下的最佳做法的想法。 我們如何處理主項目和其他項目之間的這種依賴關系？

謝謝

Answer 1

讓我們從全局模式和措辭開始。 如果一盒函數被用作其他項目的工具箱，你不應該把它當做主項目。 它只是一個需要的庫。 如果您願意，可以將其稱為基本庫。

一個主要項目將是唯一的頂級 package，它需要所有其他包。 由於您有多個項目，因此主要項目一詞不合適。

框架是一個更復雜的案例。 好像不是，你在說什么。 如果它是一個通用框架，我仍然會稱它為框架而不是主項目。

現在已經將部分設置到適當的位置，讓我們談談依賴關系。 所有項目都依賴於這一工具箱。 如果此工具箱編碼良好，它將適用於所有項目。

如果它不適用於所有項目，則其中有代碼，這不是通用的，而是專門針對單個項目的。 這部分代碼是罪魁禍首。 單個項目專用的代碼，應作為回調 function 注入。 然后工具箱會執行它，但是特殊代碼仍然在特殊項目的代碼庫中，因為那里定義了回調。 這種回調注入是javascript最強大的部分之一。

然后為您的代碼編寫測試。 編寫測試是干凈注入和良好架構的最佳顧問。 我還暗示了“依賴注入”這個術語。

所有這些聽起來都很棒，但是如果您調整公共庫，作為副作用，其他項目仍然會中斷，對嗎？

這不是架構問題，而是庫的維護和發布周期問題。 API 在次要版本中進行了擴展。 重大更改應該只發生在主要版本中。 如果升級到主版本，所有項目都需要調整為更改后的 API。 因此，中斷版本應該很少見。

同樣，完整的測試覆蓋有助於快速將代碼調整為主要版本。 測試揭示了每一個破壞 function 的測試。

您仍然需要從當前情況到令人滿意的情況的遷移路徑。 這里的答案是 git 存儲庫。 為每個項目創建一個基本庫的分支，以保持您的業務正常運行。 然后隨着時間的推移將不同的分支合並為一個抽象的穩定分支。

所以我的回答有五個部分：

1. 在您的思維方式中將術語“主項目”替換為“基礎庫”。

2. 使用 git 中的不同分支作為遷移路徑。

3. 然后了解注入，回調形式的注入和依賴項的注入。

4. 盡可能測試你的代碼。 還有更多的理由這樣做。

5. 最后遵循基本庫的標准發布周期。

當您要求最佳實踐時，第五點的答案是“語義版本控制”。 https://semver.org

在semver之后，您的 package 將干凈地工作npm的基於版本的依賴項管理器。