Web アプリケーションの要求は、パイプラインと考えることができます。パイプラインはパイプで構成されており、必要に応じてパイプラインに新しいパイプを簡単に追加できます。
ここで、パイプラインに追加するすべてのパイプが、パイプラインを流れる流体に対して特別な処理を行うことができると想像してください。たとえば、パイプラインを流れる流体が水である場合、汚れや不純物をろ過するパイプを追加できます。次に、水を 80 ℃ に加熱するパイプを追加し、粉ミルクをパイプラインに追加するパイプを追加できます。水を入れてから、粉末チョコレートを追加する別のパイプを追加すると、パイプラインの終わりにチョコレートミルクが得られます.
同じことを想像してみてください。しかし、流体は http リクエストであり、パイプラインに追加するすべてのパイプ (つまりミドルウェア) で、リクエストに対してあらゆる種類のことを行うことができます。次のパイプは、変更/改善されたリクエストを取得します。作業を進めていくと、HTTP 応答を徐々に作成できます。これは、パイプラインの反対側で期待されるものです。
たとえば、リクエストの本文が暗号化されている可能性があるため、パイプラインの次のパイプが復号化されたリクエストで動作できるように、パイプラインに復号化パイプを追加できます。他のパイプはクエリ パラメータを探してハッシュに入れることができ、他のパイプはフォーム パラメータを探して同じことを行うことができ、他のパイプはヘッダー値を抽出できます。
したがって、パイプラインにパイプを簡単に追加できることがわかります。パイプラインはそれぞれ、前のパイプが実行しなかったことを実行します。そして、どんどん情報を増やしてリクエストを改善し、最終的にクライアントに送り返すレスポンスを作成するのに役立ちます。
これらのパイプの一部は、リクエストを拒否するために使用できます。たとえば、REST API では、パイプを最初に追加して、リクエストで送信された API キーをチェックし、無効な場合はすぐにリクエストを破棄し、それ以外の場合は送信します。パイプラインをリクエストします。
したがって、いくつかのパイプは、どのリクエストを処理する必要があり、どれを破棄または終了する必要があるかを決定するフィルターとして機能することがわかります。他のパイプは、リクエストにデータを追加したり、リクエスト内のデータを変更したりしてリクエストを変更し、それをパイプラインの次のパイプに渡すトランスフォーマーとして機能する場合があります。一部のパイプはルーターです。これは、単一の入口点と多数の出口点を持つパイプです。このタイプのパイプは、そのコンテンツ (つまり、パス、コンテンツ タイプ、受け入れられる言語など) に応じて、異なるパイプラインを介してリクエストを送信できます。最後に、一部のパイプはターミナルです。つまり、パイプラインに到達すると、パイプラインの最後に到達し、成功するかどうかにかかわらず、そこで応答を提供する必要があります。
Koa だけでなく、多くの Web フレームワークがこのように動作します。Koa は Express と同じ作成者によって開発されており、後者は同様の方法で動作するため、Expeess の最高のアイデアを Koa で再利用したのは当然のことです。ただし、Java サーブレットなどの初期のフレームワークは、フィルターと呼ばれる概念を使用して同様に機能します。したがって、これは新しいものではなく、おそらく用語です。