最新のエンタープライズNode.jsアプリケーションのアーキテクチャ

ああ、その名前が不滅のファウラーを暗示しているのは何の意味もありません。そして、フロントエンドアプリケーションが非常に複雑になり、重要な問題について話し始めたのはいつですか。 Node.js ...フロントエンド...待ってください、しかしノードはサーバー上にあり、これはバックエンドであり、みんなはすでにすべてを知っています！







順番に行きましょう。そしてすぐに小さな免責事項：この記事は、フロントエンド開発者向けのYa SubbotnikProでの私のスピーチに基づいて書かれました。バックエンドに関与している場合は、おそらく、自分にとって新しいことは何も見つかりません。ここでは、大企業でのフロントエンドの経験を要約し、Node.jsを使用する理由と方法を説明します。



この記事でフロントエンドと見なすものを定義しましょう。タスクに関する論争を脇に置き、本質に焦点を当てましょう。



フロントエンドは、表示を担当するアプリケーションの一部です。ブラウザー、デスクトップ、モバイルなど、異なる場合があります。ただし、常に重要な機能があります。フロントエンドにはデータが必要です。このデータを提供するバックエンドがなければ、それは役に立ちません。これはかなり明確な境界線です。バックエンドは、データベースにアクセスし、受信したデータにビジネスルールを適用し、結果をフロントエンドに提供する方法を知っています。フロントエンドは、データを受信し、テンプレート化して、ユーザーに美しさを与えます。



概念的には、フロントエンドがデータを受信および保存するためにバックエンドが必要であると言えます。例：クライアントサーバーアーキテクチャを備えた典型的な最新のサイト。ブラウザのクライアント（シンと呼ぶと、言語は回転しなくなります）は、バックエンドが実行されているサーバーをノックします。そしてもちろん、どこにでも例外があります。サーバーを必要としない複雑なブラウザーアプリケーションがあり（この場合は考慮しません）、サーバー上でフロントエンドを実行する必要があります。これはサーバーサイドレンダリングまたはSSRと呼ばれます。これが最も単純で最も理解しやすいケースなので、それから始めましょう。

SSR

バックエンドの理想的な世界は次のようになります。データを含むHTTP要求はアプリケーションの入力に到着し、出力には便利な形式の新しいデータを含む応答があります。たとえば、JSON。 HTTP APIは、テストと開発方法の理解が簡単です。ただし、人生は調整を行います。APIだけでは不十分な場合があります。



サーバーは既製のHTMLで応答して、検索エンジンクローラーにフィードしたり、ソーシャルネットワークに挿入するためのメタタグを使用してプレビューをレンダリングしたり、さらに重要なことに、弱いデバイスでの応答を高速化したりする必要があります。昔のように、PHPでWeb2.0を開発しました。



すべてがよく知られており、長い間説明されてきましたが、クライアントは変化しました-必須のクライアント側テンプレートエンジンがそれにやって来ました。現代のWebでは、JSXがボールを支配しており、その長所と短所については長い間議論できますが、1つ否定することはできません。サーバーレンダリングでは、JavaScriptコードなしでは実行できません。



バックエンド開発によってSSRを実装する必要がある場合がわかります。

1. 責任範囲はまちまちです。バックエンドプログラマーがレンダリングを担当し始めています。
2. 言語が混在しています。バックエンドプログラマーはJavaScriptを使い始めます。

解決策は、SSRをバックエンドから分離することです。最も単純なケースでは、JavaScriptランタイムを使用し、必要なJavaScriptテンプレートエンジンで動作する自作のソリューションまたはフレームワーク（Next、Nuxtなど）をそのランタイムに配置し、トラフィックを通過させます。現代の世界でおなじみのパターン。



そのため、サーバー上のフロントエンド開発者に少しだけ許可しました。もっと重要な問題に移りましょう。

データ受信中

一般的な解決策は、汎用APIを作成することです。この役割は、ほとんどの場合、複数のマイクロサービスをポーリングできるAPIGatewayによって引き受けられます。ただし、ここでも問題が発生します。



まず、チームと責任範囲の問題。大規模な最新のアプリケーションは、多くのチームによって開発されています。各チームはビジネスドメインに重点を置いており、バックエンドに独自のマイクロサービス（または複数）を持ち、クライアントに独自のディスプレイを備えています。マイクロフロントとモジュール性の問題については触れません。これは別の複雑なトピックです。クライアントビューが完全に分離されており、1つの大きなサイト内のミニSPA（シングルページアプリケーション）であるとします。



各チームには、フロントエンドとバックエンドの開発者がいます。誰もが自分のアプリケーションに取り組んでいます。 APIGatewayが問題になる可能性があります。誰が責任を負いますか？誰が新しいエンドポイントを追加しますか？プロジェクトの他のすべての人の問題を解決するのに常に忙しい専用のAPIスーパーチーム？間違いの代償は何ですか？このゲートウェイが崩壊すると、システム全体がダウンします。



第二に、冗長/不十分なデータの問題。 2つの異なるフロントエンドが同じ汎用APIを使用するとどうなるかを見てみましょう。







これらの2つのフロントエンドは大きく異なります。必要なデータセットは異なり、リリースサイクルも異なります。モバイルフロントエンドのバージョンの変動性は最大であるため、後方互換性が最大になるAPIを設計する必要があります。 Webクライアントの変動性は低く、実際、リリース時のバグの数を減らすために、以前のバージョンを1つサポートするだけで済みます。ただし、「汎用」APIがWebクライアントのみにサービスを提供している場合でも、データが冗長または不十分であるという問題に直面しています。







各マッピングには個別のデータセットが必要であり、1つの最適なクエリで取得できます。



この場合、ユニバーサルAPIは機能しないため、インターフェイスを分離する必要があります。これは、それぞれに独自のAPIゲートウェイが必要であることを意味しますフロントエンド。ここでの「それぞれ」という言葉は、独自のデータセットで動作する一意のマッピングを示します。







このようなAPIの作成は、フロントエンドと連携して希望を実装する必要があるバックエンド開発者に任せることができます。または、はるかに興味深く、多くの点でより効率的に、フロントエンドチームにAPIの実装を提供することができます。これにより、SSRの実装による問題が解消されます。APIをノックするレイヤーをインストールする必要がなくなり、すべてが1つのサーバーアプリケーションに統合されます。さらに、SSRを制御することにより、サーバーに追加の要求を行うことなく、レンダリング時に必要なすべてのプライマリデータをページに配置できます。



このアーキテクチャは、フロントエンドのバックエンドまたはBFFと呼ばれます。考え方は単純です。クライアント要求をリッスンし、バックエンドをポーリングして、最適な応答を返す新しいアプリケーションがサーバーに表示されます。そしてもちろん、このアプリケーションはフロントエンド開発者によって制御されます。







バックエンドに複数のサーバーがありますか？問題ない！







バックエンド開発がどの通信プロトコルを好むかに関係なく、Webクライアントと通信するために任意の便利な方法を使用できます。 REST、RPC、GraphQL-私たちは自分で選択します。



しかし、GraphQL自体は、単一のクエリでデータを取得する問題の解決策ではありませんか？たぶん、中間サービスをフェンスする必要はありませんか？



残念ながら、GraphQLを効果的に使用するには、効率的なデータベースクエリの開発を担当するバックエンド開発者との緊密な協力が必要です。このようなソリューションを選択することで、データを再び制御できなくなり、最初の場所に戻ります。





^{_{もちろん可能ですが、面白くありません（フロントエンドの場合）}}



では、BFFを実装しましょう。もちろん、Node.jsでは。どうして？フロントエンド開発者の経験とJavaScriptを再利用してテンプレートを操作するには、クライアントとサーバーに単一の言語が必要です。他のランタイム環境はどうですか？







GraalVMおよびその他のエキゾチックなソリューションは、パフォーマンスがV8より劣り、具体的すぎます。 Denoはまだ実験段階であり、本番環境では使用されていません。



そして一瞬。 Node.jsは、APIGatewayを実装するための驚くほど優れたソリューションです。ノードアーキテクチャでは、シングルスレッドのJavaScriptインタープリターをlibuvと組み合わせて使用​​できます。libuvは非同期のI / Oライブラリであり、スレッドプールを使用します。







JavaScript側での長い計算は、システムパフォーマンスに影響を与えます。これを回避できます。別々のワーカーで実行するか、ネイティブバイナリモジュールのレベルにします。



ただし、基本的なケースでは、Node.jsはCPUを集中的に使用する操作には適していません。同時に、非同期I / Oでうまく機能し、高いパフォーマンスを提供します。つまり、ユーザーに関係なく、常に迅速に応答できるシステムが得られます。バックエンドがどれだけ忙しいかについて。操作の終了を待つようにユーザーに即座に通知することで、この状況に対処できます。

ビジネスロジックを保存する場所

現在、システムには、バックエンド、フロントエンド、BFFの3つの大きな部分があります。合理的な（アーキテクトにとって）質問が発生します：ビジネスロジックをどこに保持するか？







もちろん、アーキテクトはシステムのすべてのレイヤーにビジネスルールを塗りつぶしたくはありません。真実の源は1つでなければなりません。そして、そのソースはバックエンドです。データに最も近いシステムの部分でない場合、高レベルのポリシーを保存する他の場所はありますか？







しかし実際には、これは常に機能するとは限りません。たとえば、BFFレベルで効率的かつ迅速に実装できるビジネス上の問題が発生します。完璧なシステム設計は素晴らしいですが、時は金なりです。アーキテクチャのクリーンさを犠牲にしなければならない場合があり、レイヤーがリークし始めます。







「完全な」Node.jsバックエンドを優先してBFFを捨てることで、完璧なアーキテクチャを実現できますか？この場合、漏れはないようです。





事実ではありません。サーバーに転送された場合、インターフェースの応答性に影響を与えるビジネスルールがあります。これに最後まで抵抗することはできますが、完全に回避することはできないでしょう。アプリケーションレベルのロジックもクライアントに浸透します。最新のSPAでは、BFFがある場合でも、クライアントとサーバーの間にスミアが発生します。





どんなに頑張っても、ビジネスロジックはNode.jsのAPIゲートウェイに浸透します。この結論を修正して、最もおいしい実装に移りましょう！

泥の大きなボール

近年のNode.jsアプリケーションで最も人気のあるソリューションはExpressです。実証済みですが、レベルが低すぎて、優れたアーキテクチャアプローチを提供していません。主なパターンはミドルウェアです。泥の大きな塊のようなExpressの典型的なアプリケーション（名前を呼ぶことやアンチパターンではありません）。

const express = require('express');
const app = express();
const {createReadStream} = require('fs');
const path = require('path');
const Joi = require('joi');
app.use(express.json());
const schema = {id: Joi.number().required() };

app.get('/example/:id', (req, res) => {
    const result = Joi.validate(req.params, schema);
    if (result.error) {
        res.status(400).send(result.error.toString()).end();
        return;
    }
    const stream = createReadStream( path.join('..', path.sep, `example${req.params.id}.js`));
    stream
        .on('open', () => {stream.pipe(res)})
        .on('error', (error) => {res.end(error.toString())})
});

すべてのレイヤーが混在しており、1つのファイルにコントローラーがあり、インフラストラクチャロジック、検証、ビジネスロジックなどすべてが含まれています。これを扱うのは苦痛です、あなたはそのようなコードを維持したくありません。Node.jsでエンタープライズレベルのコードを記述できますか？







これには、保守と開発が容易なコードベースが必要です。言い換えれば、アーキテクチャが必要です。

Node.jsアプリケーションアーキテクチャ（最終的に）

「ソフトウェアアーキテクチャの目標は、システムの構築と保守に伴う人的労力を削減することです。」



ロバート「ボブおじさん」マーティン

アーキテクチャは、レイヤーとそれらの間の接続という2つの重要な要素で構成されています。アプリケーションをレイヤーに分割し、相互のリークを防ぎ、レイヤーの階層とレイヤー間の接続を適切に整理する必要があります。

レイヤー

アプリケーションをレイヤーに分割するにはどうすればよいですか？データ、ロジック、プレゼンテーションという古典的な3層のアプローチがあります。







このアプローチは現在、廃止されたと見なされています。問題は、データが基本であるということです。つまり、アプリケーションは、参加するビジネスプロセスではなく、データベースでのデータの表示方法に応じて設計されます。



より現代的なアプローチでは、アプリケーションにビジネスロジックと連携し、コードで実際のビジネスプロセスを表現する専用のドメインレイヤーがあることを前提としています。ただし、Eric Evansの従来のドメイン駆動型設計に目を向けると、次のアプリケーション層スキームが見つかります。







ここで何が問題になっていますか？DDDを使用して設計されたアプリケーションの基礎は、ドメイン、つまり最も重要で価値のあるロジックである高レベルのポリシーである必要があるように思われます。ただし、この層の下には、データアクセス層（DAL）、ロギング、監視などのインフラストラクチャ全体があります。つまり、はるかに低いレベルで重要性の低いポリシーです。



インフラストラクチャはアプリケーションの中心であり、ロガーの平凡な交換は、すべてのビジネスロジックのシェイクアップにつながる可能性があります。







もう一度RobertMartinに目を向けると、「Clean Architecture」という本の中で、彼はアプリケーション内の異なるレイヤー階層を仮定しており、ドメインが中央にあることがわかります。







したがって、4つのレイヤーすべてを異なる方法で配置する必要があり







ます。レイヤーを選択し、それらの階層を定義しました。それでは、接続に移りましょう。

接続

ユーザーロジック呼び出しの例に戻りましょう。インフラストラクチャへの直接の依存を取り除き、正しいレイヤー階層を確保するにはどうすればよいですか？依存関係を元に戻す簡単でよく知られた方法、つまりインターフェイスがあります。







現在、高レベルのUserEntityは低レベルのロガーに依存していません。それどころか、それはロガーをシステムに含めるために実行されなければならない契約を指示します。この場合のロガーの交換は、同じ契約を遵守する新しい実装を接続することになります。重要な質問はそれをどのように接続するかです。

import {Logger} from ‘../core/logger’;
class UserEntity { 
	private _logger: Logger;
	constructor() {
		this._logger = new Logger();
	}
	...
}
...
const UserEntity = new UserEntity();

レイヤーはしっかりと接続されています。ファイルの構造と実装には結びつきがあります。依存関係の反転が必要です。これは、依存関係の挿入を使用して行います。

export class UserEntity {
	constructor(private _logger: ILogger) { }
	...
}
...
const logger = new Logger();
const UserEntity = new UserEntity(logger);

これで、「ドメイン」UserEntityはロガーの実装について何も知りません。契約を提供し、実装がその契約に準拠することを期待します。



もちろん、インフラストラクチャエンティティのインスタンスを手動で生成することは最も楽しいことではありません。すべてを準備するルートファイルが必要です。作成したロガーのインスタンスをアプリケーション全体にドラッグする必要があります（多くを作成するのではなく、1つ持つ方が有利です）。疲れます。そして、ここでIoCコンテナが活躍し、このボラープレートの作業を引き継ぐことができます。



コンテナの使用はどのように見えるでしょうか？たとえば、次のようになります。

export class UserEntity {
	constructor(@Inject(LOGGER) private readonly _logger: ILogger){ }
}

何が起きてる？デコレータの魔法を使用して、次のように説明しました。「UserEntityのインスタンスを作成するときは、そのプライベートフィールド_loggerに、LOGGERトークンの下のIoCコンテナにあるエンティティのインスタンスを挿入します。ILoggerインターフェースに準拠することが期待されています。」そして、IoCコンテナはそれ自体ですべてを実行します。



レイヤーを選択し、それらをどのように解くかを決定しました。フレームワークを選択する時が来ました。

フレームワークとアーキテクチャ

質問は単純です。Expressを最新のフレームワークに任せることで、優れたアーキテクチャを実現できるでしょうか。Nestを見てみましょう：

• TypeScriptで書かれ、
• Express / Fastifyの上に構築されており、ミドルウェアレベルでの互換性があります。
• ロジックのモジュール性を宣言し、
• IoCコンテナを提供します。

ここに必要なものはすべて揃っているようです。彼らはまた、アプリケーションの概念をミドルウェアチェーンとして残しました。しかし、良いアーキテクチャはどうですか？

巣への依存性注入

指示 に従ってみましょう。Nestでは、エンティティという用語は通常ORMに適用されるため、UserEntityの名前をUserServiceに変更します。ロガーはフレームワークによって提供されるため、代わりに抽象FooServiceを挿入します。

import {FooService} from ‘../services/foo.service’;
@Injectable()
export class UserService {
	constructor(
            private readonly _fooService: FooService
   ){ }
}

そして...私たちは一歩後退したようです！インジェクションはありますが、反転はあり

ません。依存関係は、抽象化ではなく実装を目的としています。



それを修正してみましょう。オプション番号1：

@Injectable()
export class UserService {
	constructor(
            private _fooService: AbstractFooService
   ){ } }

この抽象的なサービスについて説明し、近くのどこかにエクスポートします。

export {AbstractFooService};

FooServiceはAbstractFooServiceを使用するようになりました。そのため、IoCに手動で登録します。

{ provide: AbstractFooService, useClass: FooService }

2番目のオプション。前述のインターフェイスを使用したアプローチを試してみましょう。JavaScriptにはインターフェースがないため、リフレクションを使用して実行時に必要なエンティティをIoCから引き出すことはできません。必要なものを明示的に述べる必要があります。これには@Injectデコレータを使用します。

@Injectable()
export class UserService {
	constructor(
            @Inject(FOO_SERVICE) private readonly _fooService: IFooService
   ){ } }

そしてトークンで登録します：

{ provide: FOO_SERVICE, useClass: FooService }

フレームワークを獲得しました！しかし、どのくらいの費用がかかりますか？かなりの砂糖を止めました。これは疑わしいことであり、アプリケーション全体をフレームワークにバンドルするべきではないことを示唆しています。私がまだあなたを納得させていないのなら、他の問題があります。

例外

ネストは例外を除いて点滅します。さらに、彼は、アプリケーションの動作のロジックを説明するために例外スローを使用することを提案しています。







アーキテクチャの観点から、ここではすべて問題ありませんか？再び著名人に目を向けましょう：

「エラーが予想される動作である場合は、例外を使用しないでください。」

マーティンファウラー

例外は、例外的な状況を示唆しています。ビジネスロジックを作成するときは、例外をスローしないようにする必要があります。JavaScriptもTypeScriptも例外が処理されることを保証しないという理由だけの場合。さらに、実行の流れがわかりにくくなり、GOTOスタイルでプログラミングを開始します。つまり、コードの動作を調べている間、読者はプログラム全体をジャンプする必要があります。







例外の使用が合法であるかどうかを理解するのに役立つ簡単なルールがあります。

「すべての例外ハンドラーを削除すると、コードは機能しますか？」答えが「いいえ」の場合、例外ではない状況で例外が使用される可能性があります。」

実用的なプログラマー

ビジネスロジックでこれを回避することは可能ですか？はい！スローする例外を最小限に抑え、複雑な操作の結果を便利に返すには、成功またはエラーの状態（Promiseに非常に近い概念）のコンテナーを提供するEitherモナドを使用する必要があります。

const successResult = Result.ok(false);
const failResult = Result.fail(new ConnectionError())

残念ながら、Nestが提供するエンティティ内では、他の方法で行動できないことがよくあります。例外をスローする必要があります。これがフレームワークの仕組みであり、これは非常に不快な機能です。そして再び疑問が生じます：多分あなたはフレームワークでアプリケーションをフラッシュするべきではありませんか？フレームワークとビジネスロジックを異なるアーキテクチャレイヤーに分離することは可能でしょうか？



確認しよう。

ネストエンティティとアーキテクチャレイヤー

人生の厳しい真実：Nestで書くものはすべて1つのレイヤーに積み重ねることができます。これはアプリケーションレイヤーです。







フレームワークをビジネスロジックに深く入り込ませたくないので、例外、デコレータ、およびIoCコンテナを除いてフレームワークが成長することはありません。フレームワークの作成者は、その砂糖を使用してビジネスロジックを作成することがどれほど素晴らしいかを明らかにしますが、彼らの仕事はあなたを永遠に自分自身に結び付けることです。フレームワークは、アプリケーションレベルのロジックを便利に整理し、インフラストラクチャとUIをそれに接続するための単なる方法であることを忘れないでください。

「フレームワークは詳細です。」

ロバート「ボブおじさん」マーティン

コンポーネントを簡単に置き換えることができるコンストラクターとしてアプリケーションを設計することをお勧めします。このような実装の一例は、六角形のアーキテクチャ（ポートおよびアダプタアーキテクチャ）です。このアイデアは興味深いものです。すべてのビジネスロジックを備えたドメインコアは、外界と通信するためのポートを提供します。必要なものはすべて、アダプターを介して外部に接続されています。







Nestをフレームワークとして使用してNode.jsにそのようなアーキテクチャを実装することは現実的ですか？かなり。興味があれば、例を挙げてレッスンを行いました。ここで見つけることができます。

まとめましょう

• Node.jsはBFFに適しています。あなたは彼女と一緒に暮らすことができます。
• 既製のソリューションはありません。
• フレームワークは重要ではありません。
• アーキテクチャが複雑になりすぎたり、入力に遭遇したりすると、間違ったツールを選択した可能性があります。

私はこれらの本をお勧めします：

• ロバート・マーティン、「クリーンアーキテクチャ」、
• Vaughn Vernon, Domain-Driven Design Distilled,
• Khalil Stemmler, khalilstemmler.com,
• Martin Fowler, martinfowler.com/architecture.