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

Question

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

構建時碼

建造時間對於使用咕嘟咕嘟，咕嚕，或香草NPM在隨後的基本文件的方式的項目代碼一般都非常容易。大多數小型項目傾向於將所有代碼保存在單個文件中，並且該文件傾向於命名爲常規名稱，例如gulpfile.js，但是我看到這些腳本開始被拆分出更大的項目。我已經看到了一些情況，其中吞噬文件被拆分成多個文件並放置在單獨的目錄下。更糟糕的是，我發現gulpfile.js文件甚至沒有被命名爲這樣的情況，導致新開發人員四處尋找以查找gulp文件的位置，並且一旦找到gulp命令，就必須始終使用特定的--gulpfile選項。

運行時服務器端代碼

的入口點基本節點應用程序似乎僅僅需要運行的節點命令時指出特定的JavaScript文件（例如：node script.js）。對於Web服務器應用程序（例如使用Express的應用程序），我注意到按照慣例，入口點文件通常稱爲server.js，通常可以在應用程序的根目錄中找到。然而，在其他一些情況下，例如在開發人員環境中運行Web服務器時，我看到吞噬任務承擔了啓動Node的責任。在這些情況下，似乎有多種方法可以包含入口點，但我發現的一個示例是啓動webpack編譯器，然後針對入口點腳本使用要求聲明。弄清楚如何在如何完成典型的命令中加入正常的指導在這種類型的設置中是不平凡的。除了應用程序的入口點之外，NodeJS/Express應用程序的目錄結構似乎沒有任何通用的指導，它們將服務器端特定的代碼保留在它的位置以幫助查找它並將它與構建時間和客戶端代碼。

服務器端故事在服務器端代碼既用於提供靜態內容，服務器端生成的視圖（如使用MVC）的情況下也變得更加複雜，並且用於提供API到客戶端。我的偏好是將API從應用程序項目中分離出來，但我從其他人那裏得到的感覺是，如果我認爲這是合理的關注點分離，那麼就會有一種過度複雜的感覺。

運行時客戶端代碼

由於基於該請求這可能會非常棘手的第一頁上的客戶端代碼往往有不同的切入點。然而，由於URL的普遍透明性以及它們在典型情況下如何映射資源以及現代瀏覽器中調試工具的功能有多強大，所以在腳本的後續操作之後不會太麻煩。對於客戶端代碼來說，困難在於典型的構建過程，這些過程通常最終將文件複製並以不同的名稱放入類似結構的生產中。一個例子是一個名爲src或js的文件夾，該文件夾保存着客戶端和服務器端代碼，除了只有一部分文件恰好包含在構建任務中並且經常變換連接文件並將它們放在分發文件夾中。我見過的這些分發文件夾的通用名稱是dist,public,www和wwwroot。通常情況下，如果不是這些目錄總是在項目的根目錄下，那麼至少可以在不必詢問構建腳本的情況下輕鬆定位。

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

Answer 1

構建時碼

恕我直言，如果你有這麼多的集結時間的代碼，它比說1000線，需要比文件的屈指可數，一些已經脫軌。要麼你不知道如何充分利用現有的npm包，或者你不知道如何重構通用代碼併發布爲獨立的npm包。如果您覺得您需要有關項目構建時代碼的指導，因爲它非常龐大且複雜，我的建議是將其模塊化並拆分爲單獨的項目 - 每個項目都獨立發佈到npm。也只是檢查你的整體方法。你在做什麼，這是如此的習慣，需要這麼多機器？

運行時服務器端代碼

請看到我的其他答案ExpressJS How to structure an application?

一般來說，我寧願看到客戶端代碼和服務器端代碼，通過完全獨立的NPM包（單獨的git回購協議，單獨發佈的package.json文件）（如果它們足夠大）或以其他方式混合在同一個模塊中，並通過耦合進行分組（所有代碼都與包含前後端代碼的功能有關），特別是如果您的代碼庫有大量的代碼可以在兩種環境中使用。

我有一個名爲mjournal的開放源代碼的完整堆棧節點/ JS應用程序，它使瀏覽器代碼和節點代碼彼此保持一致。你可以看一看，看看它是否合乎邏輯，容易理解代碼的存在。這絕不是一種流行的方法，所以很多人會不喜歡它，但我個人感覺很好，因爲我已經接受了「通過耦合組合」作爲一般原則。

弄清楚如何將如何完成一個典型的節點調試命令正常指導在這種類型的設置

是啊，這是胡說八道不平凡。你的應用程序應該從npm start或類似node server.js之類的東西開始。精心設計混淆新開發人員的吞嚥/咕嚕聲是不必要的複雜性，您應該消除這種複雜性。

在服務器端代碼同時用於爲宗旨，爲提供靜態內容

以我的經驗服務器端的故事變得均勻的情況更復雜，代碼以提供靜態內容歸結爲5行或更少，所以沒什麼大不了的。如果你的代碼處理服務靜態內容的代碼量非常微小，那麼還有一些事情沒有辦法解決。

運行時客戶端代碼

我的希望是，有有關於如何把所有這一切都一起在一個健全的方式可能是通過權威人士一些一般性的指導主要是爲了給指導像我這樣的人，他們可能想從右腳開始。

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

但是一般來說，尋找「標準」並不是node.js/javascript/web社區的滾動方式。小npm包。因文件較小而被迫變爲顯而易見的文件格式。由於前端工具鏈非常複雜，我感到很沮喪，但最終是因爲瀏覽器中的JavaScript需要花費數十年時間來創建合理的模塊系統。在未來幾年內，事情可能會開始標準化，因爲ES6模塊是官方的規範，但由於CommonJS已經編寫了很多代碼，並且它是像RequireJS/AMD這樣的可怕前兆，我們將在可預見的將來處理它們。