如何使用NodeJS組織構建，服務器，客戶端和共享JavaScript代碼

Question

我一直認為在服務器上使用NodeJS的一大好處是可能在服務器端和客戶端之間共享代碼（例如輸入驗證）。 現在我實際上正在使用NodeJS進行開發，我發現的一個難點是確定執行每個代碼體的責任和上下文。 下面我將列出一些我曾經遇到過的困難，希望能夠對我可能忽略的慣例或指導有所啟發，這有助於提升這些問題。

構建時間代碼

以遵循基本文檔的方式構建使用Gulp，Grunt或vanilla NPM的項目的時間代碼通常很容易理解。 大多數較小的項目傾向於將所有代碼保存在單個文件中，並且文件往往被命名為傳統名稱，如gulpfile.js，但是對於更大的項目，我看到這些腳本開始被拆分。 我已經看到一些gulp文件被拆分成多個文件並放在一個單獨的目錄下的情況。 更糟糕的是，我發現gulpfile.js文件甚至沒有這樣命名的情況導致新開發人員尋找gulpfile所在的位置，一旦找到它，gulp命令總是必須運行特定的- -gulpfile選項。

運行時服務器端代碼

基本節點應用程序的入口點似乎只需要在運行node命令時指出特定的JavaScript文件（例如node script.js ）。 對於Web服務器應用程序，例如那些使用Express的應用程序，我注意到按照慣例，入口點文件通常稱為server.js，通常可以在應用程序的根目錄中找到。 在某些其他情況下，例如在開發人員環境中運行Web服務器時，我看到gulp任務負責啟動Node。 在這些情況下，似乎有多種方法可以包含入口點，但我發現的一個例子就是啟動webpack編譯器，然后是入口點腳本的require語句。 在這種類型的設置中，弄清楚如何結合關於如何完成典型節點調試命令的正常指導是非常重要的。 除了應用程序的入口點之外，似乎沒有關於NodeJS / Express應用程序的目錄結構的任何一般指導，這些應用程序將服務器端特定代碼保存在其中以幫助定位它並使其與構建時間和客戶端代碼。

服務器端代碼既用於提供靜態內容，服務器端生成的視圖（例如使用MVC），也用於向客戶端提供API，服務器端故事變得更加復雜。側。 我傾向於將API與應用程序項目分開，但我從其他人那里得到的感覺是，這樣做有一種過於復雜的感覺，我將其視為合理的關注點分離。

運行時客戶端代碼

由於客戶端代碼通常可以根據請求的第一頁具有各種入口點，因此這可能很棘手。 但是，由於URL的一般透明性以及它們如何映射到典型情況下的資源，以及調試工具在現代瀏覽器中的強大程度，因此遵循腳本並不會太麻煩。 對於典型的構建過程而言，難以替代客戶端代碼，這通常最終會復制文件並將它們放置在不同名稱下的生產類結構中。 一個例子是一個項目，它有一個名為src或js的文件夾，它保存客戶端和服務器端代碼混合，除了只有一部分文件碰巧包含在構建任務中，該任務轉換並經常連接文件和將它們放在分發文件夾中。 我見過的這些分發文件夾的常用名稱是dist ， public ， www和wwwroot 。 通常，如果不總是這些目錄位於項目的根目錄，這至少使得它更容易定位而無需詢問構建腳本。

我希望有一些一般指導如何將所有這些結合在一起，或許是一個權威的來源，主要是為那些像我一樣可能想要從右腳開始的人提供指導。 作為副作用或許能夠引用某種標准，即使它是一個松散的標准，也可能減少團隊在開始時發明和討論的樣板數量。 在上面列出的每個上下文中，顯然會有一些技術特定的約定，例如客戶端的AngularJS，Meteor或ReactJS遵循的約定。 我正在尋找的約定更具體地分離端到端JavaScript應用程序中的主要高級上下文，其中語言和平台不再是區分每種語言和平台的明顯方式。

Answer 1

構建時間代碼

恕我直言，如果你有這么多的構建時間代碼，它不僅僅是1000行並且需要的文件數量超過少數，那么有些東西已經脫軌了。 您不知道如何充分利用來自npm的現有包，或者您不了解如何重構通用代碼並發布為獨立的npm包。 如果你覺得你需要有關項目構建時代碼的指導，因為它是如此龐大和復雜，我的建議是模塊化並拆分成單獨的項目 - 每個項目獨立發布到npm。 還要檢查一下整體方法。 你在做什么，這是如此習慣，需要這么多機械？

運行時服務器端代碼

請參閱ExpressJS的其他答案如何構建應用程序？

一般來說，我寧願看到客戶端代碼和服務器端代碼完全分開npm包（單獨的git repos，單獨的package.json文件，獨立發布）（如果它們足夠大）或以其他方式混合在同一模塊中並分組通過耦合（所有與功能相關的代碼保持在一起，包括前端和后端代碼），特別是如果您的代碼庫有大量代碼可以在兩種環境中工作。

我有一個名為mjournal的開源全棧節點/ JS應用程序， 它將瀏覽器代碼和節點代碼保持在一起。 您可以查看一下，看看它是否符合邏輯，並且易於理解代碼所在的位置。 它絕不是一種流行的方法，所以很多人都不喜歡它，但對我個人感覺很好，因為我已經接受了“通過耦合”作為一般原則。

在這種類型的設置中，弄清楚如何結合關於如何完成典型節點調試命令的正常指導是非常重要的

是的，那是胡說八道。 您的應用應該以npm start或node server.js類npm start 。 詳細說明讓新開發人員感到困惑的gulp / grunt設置是您應該消除的不必要的復雜性。

在服務器端代碼用於提供靜態內容的情況下，服務器端故事變得更加復雜

根據我的經驗，提供靜態內容的代碼可以歸結為5行或更少，所以沒什么大不了的。 如果你有一些非微觀的代碼來處理靜態內容，那么有些東西已經不再適用了。

運行時客戶端代碼

我希望有一些關於如何將所有這些結合起來的一般性指導，或許是由一個權威的來源，主要是為那些可能想要從右腳開始的人提供指導。

節點社區中有一些人采用了Ruby on Rails，EmberJS和其他一些大型項目中使用的“約定優於配置”方法。 如果您喜歡這種方法，請查看使用它的工具，如SailsJS，EmberJS，Yeoman發電機等。

但總的來說，尋找“標准”並不是node.js / javascript / web社區如何滾動。 小npm包。 文件布局由於體積小而被迫顯而易見。 我感到很沮喪，因為前端工具鏈非常復雜，但最終還是因為瀏覽器中的JavaScript花了太多時間來創建一個合理的模塊系統。 在ES6模塊是官方規范的情況下，事情可能會在未來幾年內開始標准化，但是已經在CommonJS中編寫了如此多的代碼，而且它是可疑的前驅，如RequireJS / AMD，我們將在可預見的未來處理它們。