サーバーで NodeJS を使用することで私が常に感じている大きな利点の 1 つは、サーバーとクライアント側の間でコードのビットを共有できる可能性があることです (例: 入力検証)。実際に NodeJS を使用して開発を行っている今、私が見つけた 1 つの問題は、コードの各本体が実行される責任とコンテキストを決定することです。以下に、これらの問題を高めるのに役立つ可能性のある、私が見落としている可能性のある規則やガイダンスについての啓発を得ることを期待して、私が経験した困難のいくつかをリストします.
ビルド時のコード
基本的なドキュメントに従う方法で Gulp、Grunt、またはバニラ NPM を使用するプロジェクトのビルド時のコードは、通常、非常に簡単に理解できます。小規模なプロジェクトのほとんどは、すべてのコードを 1 つのファイル内に保持する傾向があり、ファイルには gulpfile.js のような従来の名前が付けられる傾向がありますが、大規模なプロジェクトでは、これらのスクリプトが分割され始めるのを見てきました。gulp ファイルが複数のファイルに分割され、別のディレクトリに配置されているケースをいくつか見てきました。さらに悪いことに、gulpfile.js ファイルにそのような名前が付けられていないケースを見つけたので、新しい開発者が gulpfile の場所を探すために探し回り、場所が見つかったら、gulp コマンドを常に特定の-で実行する必要があります。 -gulpfileオプション。
実行時サーバー側コード
基本ノード アプリケーションのエントリ ポイントでは、ノード コマンドを実行するときに特定の JavaScript ファイルを指定する必要があるだけのようです (例: node script.js)。Expressを使用するような Web サーバー アプリケーションの場合、慣例により、エントリ ポイント ファイルは server.js と呼ばれることが多く、通常はアプリケーションのルート ディレクトリにあります。ただし、開発者環境でWebサーバーを実行する場合など、他の場合では、gulpタスクがNode.jsの起動を担当するのを見てきました。これらの場合、エントリ ポイントを含める方法は複数あるようですが、私が見つけた 1 つの例は、webpack コンパイラを起動してから require を行うことです。エントリ ポイント スクリプトのステートメント。典型的なノード デバッグコマンドを実行する方法に関する通常のガイダンスを組み込む方法を理解することは、このタイプのセットアップでは自明ではありません。アプリケーションのエントリ ポイント以外に、NodeJS/Express アプリケーションのディレクトリ構造に関する一般的なガイダンスはないようです。これは、サーバー側の特定のコードを所定の場所に保持して、その場所を特定し、ビルド時およびクライアント側のコード。
サーバー側のコードが、静的コンテンツの提供、サーバー側で生成されたビュー (MVC など)、およびクライアントへの API の提供の両方の目的で使用される場合、サーバー側の話はさらに複雑になります。側。私の好みは、アプリケーション プロジェクトから API を分離することですが、他の人からは、そうすることに複雑すぎるという感覚があると感じています。
実行時のクライアント側コード
クライアント側のコードは、要求された最初のページに基づいてさまざまなエントリ ポイントを持つことが多いため、これは注意が必要です。ただし、一般的なケースでのリソースへのマッピング方法に関する URL の一般的な透明性と、最新のブラウザーでのデバッグ ツールの強力さにより、スクリプトに従うことはそれほど難しくありません。クライアント側のコードの代わりに難しいのは、通常、ファイルをコピーして別の名前で構造のような製品に配置する典型的なビルドプロセスです。例として、srcまたはjsというフォルダーを持つプロジェクトがあります。ファイルの一部のみがたまたまビルド タスクに含まれ、ファイルが変換され、多くの場合連結され、配布フォルダーに配置されることを除いて、クライアント側とサーバー側のコードが混在しています。私が見たこれらの配布フォルダーの一般的な名前は、dist、public、www、およびwwwrootです。常にではありませんが、多くの場合、これらのディレクトリはプロジェクトのルートにあります。これにより、ビルド スクリプトを調べなくても、場所を簡単に見つけることができます。
私の希望は、これらすべてを正気の方法でまとめる方法について、おそらく権威ある情報源によって、主に私のような右足で始めたいと思うかもしれない人々にガイダンスを与えるための一般的なガイダンスがあることです. 副次的な効果として、たとえそれが緩いものであっても、ある種の標準を参照できるようになることで、チームが開始時に発明して議論しなければならないボイラープレートの量を減らすこともできます。上記の各コンテキスト内には、AngularJS、Meteor、またはクライアント側の ReactJS で従うものなど、テクノロジー固有の規則がいくつかあることは明らかです。私が探している規則は、言語とプラットフォームがそれぞれを区別する明白な方法ではなくなった、エンドツーエンドの JavaScript アプリケーションで主要な高レベルのコンテキストを分離することに特化しています。