Node.jsアプリを構築するための7つの鍵

Rahul Mhatreは、Built.ioのテクニカルアーキテクトです。

Node.jsは、新しいWebアプリケーションを開発するための優先言語として、Java、Ruby、Python、および.Netに急速に追いついています。Node.jsチームは、JavaScriptランタイムをより良く、より速く、そしてより堅実なものにしています。そして、ユーザーコミュニティは急速に成長しています。

採用が増え続けるにつれて、ますます多くの開発者がNode.jsの学習曲線を上って、同様の問題に直面し、同様の機能をコーディングするようになります。ありがたいことに、Node.jsコミュニティは、一般的な問題を解決するだけでなく、アプリケーションの構造化にも役立つフレームワークとデザインパターンで救いの手を差し伸べています。

フレームワークは通常、MVC(model-view-controller)、MVVM(model-view-viewmodel)、MVP(model-view-presenter)、またはMVなどのMVパターンを実装します。また、モデル、ビュー、およびコントローラーのコードをどこに配置するか、ルートをどこに配置するか、構成をどこに追加するかについても説明します。多くの若い開発者やNode.js愛好家は、デザインパターンやOOP(オブジェクト指向プログラミング)図がアプリケーションのコードの行や構造にどのようにマッピングされるかを実際には理解していません。

そこで、Express.jsやSails.jsなどのNode.jsフレームワークが登場します。これらや他の多くのフレームワークは、Webアプリケーションの開発を開始するのに役立ちます。使用するフレームワークに関係なく、アプリを構築する際には特定の考慮事項に留意する必要があります。

Node.jsアプリケーションをマッピングする前に私が考える7つの重要なポイントは次のとおりです。

1.アプリの適切なディレクトリ構造

アプリのディレクトリ構造を決定するときは、選択したデザインパターンを考慮する必要があります。これは、オンボーディング、コードの検索、および問題の迅速な切り分けに役立ちます。私は個人的に、Node.jsアプリを設計する際にMVCパターンを使用することを好みます。これは、開発を高速化し、同じデータに対して複数のビューを作成する柔軟性を提供し、MVCコンポーネント間の非同期通信と分離を可能にします。

上記のディレクトリ構造に従うのが好きです。これは、Ruby onRailsとExpress.jsの組み合わせに基づいています。

関連ビデオ:Node.jsのヒントとコツ

この解説動画では、ノード開発エクスペリエンスを向上させることができるいくつかのテクニックを学びます。

2.ER図をモデルにマッピングする

Techopediaで定義されているように、「実体関連図(ERD)は、情報システムのエンティティとそれらのエンティティ間の関係をグラフィカルに示すデータモデリング手法です。」ERダイアグラムは、システムに参加するさまざまなエンティティの概要を示し、次のようにそれらの間のすべての相互作用を定義します。

  • 抽象的または物理的な「もの」であるものはすべて、モデル内のエンティティになります
  • モデルはデータベース内のテーブルにマップされます
  • エンティティの属性またはプロパティはモデルの属性に変換され、モデルはテーブル内の列になります。

たとえば、エンティティがユーザーの場合、対応するモデルは、データベース内のfirst_name、last_name、addressなどの属性、および対応するテーブルと列を持つ「User」になります。

単純なデータアーキテクチャを使用すると、新しいスキーマが作成されるたびにデータベースとファイルの増加を追跡するのが非常に簡単になります。

3.MVPパターンを使用する

MVCの実装は、コントローラー、ビュー、およびモデル用のフォルダーを作成することだけを意味するのではありません。また、MVCに従ってコードとロジックを分割する必要があります。モデル内のコードは、データベーススキーマ定義に厳密に制限する必要があります。開発者は通常、モデルにCRUD操作を実行するコードも含まれることを忘れています。また、そのモデルに固有の関数または操作は、このファイル内に存在する必要があります。モデルに関連するビジネスロジックのほとんどは、このファイルに含まれている必要があります。

よくある間違いは、すべてのビジネスロジックをコントローラーにダンプすることです。コントローラーは、モデルまたは他のコンポーネントから関数を呼び出し、コンポーネント間でデータを転送し、要求のフローを制御する必要がありますが、ビューフォルダーには、オブジェクトを人間が読める形式に変換するコードのみを含める必要があります。ビュー内でデータのフォーマットや並べ替えやフィルタリングなどのロジックを実行しないでください。ビューをクリーンに保つと、ユーザーエクスペリエンスが向上するだけでなく、他のコンポーネントを変更せずにビューを変更するのにも役立ちます。

4.ロジックをモジュールに分割する

開発者として、私たちは常にコードをファイルとモジュールに編成する必要があると言われています。これは、アプリ全体を1つのファイルに収めようとする必要があるという意味ではありません。ロジックと機能に基づいてコードを分割することが最善のアプローチです。単一のエンティティまたはオブジェクトに関連する関数を単一のファイルにグループ化し、ロジックに基づいてディレクトリ構造を編成することには、多くの利点があります。まず、バグを修正する必要があるときにどの関数に触れるかを決定する時間を大幅に節約できます。次に、アーキテクチャ内のすべてのコンポーネントを分離するのに役立ち、他のコード行を変更することなく、個別の機能の置き換えを容易にします。第三に、テストケースの作成にも役立ちます。

5.テストケースの重要性

テストケースを作成するときは、決して手抜きをしないことが非常に重要です。テストはコードベースの保護者です。アプリケーションが大きくなるにつれて、コーディング中にカバーしなければならないすべてのシナリオを覚えるのが難しくなります。テストケースは、コードベースを安定させるのに役立ちます。テストはリグレッションを防ぎ、貴重な開発時間と労力を節約します。これは、新機能がエラーなしでプッシュされることを保証するのに役立ちます。また、本番環境に移行する前にバグを検出することで、コードの品質を向上させるのにも役立ちます。そして最も重要なことは、テストはコードがクラッシュしないという自信を植え付けるのに役立ちます。

6.ログの重要性

ログは、アプリケーションの状態をデバッグおよび理解するのに役立ちます。これらは、アプリの動作に関する貴重な洞察を提供します。ログを活用する際に留意すべき事項の簡単なリストを次に示します。

  • ロギングに関しては、適切なバランスを見つけてください。「情報が多すぎる」ことは決して悪いことではありませんが、過剰なログ記録はあなたの仕事を難しくするだけです。針は小さな干し草の山で見つけやすいです。反対に、ログが不足すると、デバッグや診断に利用できる情報が少なすぎます。
  • オフラインログとオンラインログを分割します。最新のログはすばやく取得して処理できるように保持されますが、古いログはアーカイブまたはファイルにダンプされます。
  • ログの頻度と期間は、必要なストレージの量に影響するため、考慮してください。ほとんどの場合、必要なストレージの量とログの数は正比例します。

また、メールID、パスワード、クレジットカード情報、電話番号などの機密データをログに記録しないでください。これは大きなセキュリティリスクであるだけでなく、多くの場合違法です。

7.アプリケーションは拡張できますか?

アプリケーション開発への最悪のアプローチは、トラフィックを獲得したにスケーリングする方法を考えることです。代わりに、時間を節約して生産性を高めるために、最初から成長する機能を備えたアーキテクチャを構築する必要があります。

サーバーのスピンアップはスケーリングではありません。リソース間で負荷を分散することです。これは、負荷が増加したときに新しいサーバーを生成するべきではないという意味ではありません。まず、増加した負荷を処理するために、現在のリソース内で負荷分散を設定する必要があります。負荷分散でワークロードを効率的に管理できない場合は、水平スケーリングを開始して新しいサーバーを生成します。これは、独立したステートレスプロセスまたはモジュールを介して実現できます。各プロセスまたはモジュールは、独立した独立した方法で機能します。これにより、アプリケーションを効率的に拡張できるだけでなく、システムのフォールトトレラント性と回復が容易になります。

Webアプリケーションをどのように構成するかは、適切なテクノロジーを選択することと同じくらい重要です。基盤に欠陥があると、アプリケーションは最終的にクラッシュするか、スケーリングを拒否するか、場合によってはまったく起動しません。適切な計画とアーキテクチャなしに、新しい機能や新しいアイデアの開発に突入しないでください。悪い構造やアーキテクチャは、爆発するのを待っている時限爆弾のようなものです。

New Tech Forumは、前例のない深さと幅で新しいエンタープライズテクノロジーを探索して議論する場を提供します。選択は主観的であり、読者にとって重要で最も興味深いと思われるテクノロジーの選択に基づいています。出版用のマーケティング資料を受け入れず、寄稿されたすべてのコンテンツを編集する権利を留保します。すべてのお問い合わせは[email protected]までお送りください。