Unix哲学はWebアプリケーションの設計から放棄されましたか？[閉まっている]

Unix Philosophyは、共有メモリ空間やリンケージとは対照的に、パイプ、fifo、ソケットなどのプロセス間通信の形式と連携する、小さくて一般的に再利用可能な協調プログラムの使用を奨励しています。多くの場合、プログラムMHおよびuzblは、Unixの哲学を設計で例示するアプリケーションの例として示されています。

これが事実なら、Unix PhilosophyがWebアプリケーションの設計から完全に放棄されているというのは本当ではないでしょうか。要求を処理するほとんどすべてのWebアプリケーションは、1つのリソースだけでなく、ドメイン全体のすべてのリソースに対して、（外部データベースプログラムの呼び出しを除いて）要求/応答サイクル全体を処理する単一の大きなモノリシックな長時間実行プロセスとして構築されています。

これは主に、Webリクエストへの動的応答を構築するために外部プログラムのコレクションにパイプアウトすることで、プロセスの起動時のオーバーヘッドが多すぎるためですか？RubyまたはPythonスクリプトにパイプアウトしたい場合、これがどのように見えるかがわかりますが、おそらくコンパイル可能なHaskellのような言語を使用している場合、Webアプリの構築におけるUnix哲学に従うための実際の障害はなくなりますか？

それは、アプリケーション間の境界をどこに描くか（つまり、アプリケーションの定義は何か）と、考慮に入れるユースケースにかなり依存すると思います。

Webブラウザーをwget/の統合として実装することもできますがcurl、各ドキュメントノードの単純なアプリケーションを呼び出すHTML / XMLパーサー、これすべてとやり取りするスタンドアロンのJavaScriptエンジン、および「ただ」動作する「単純な」表示機能上記の出力を画面に配置し（そして入力をいくつかのコア調整プロセスに戻す）、他の今日のブラウザーよりも（おそらくどれでも）厄介です。

データを外部プロセスにパイプすることに関しては-それが実際に開始された方法です。平均的なWebアプリケーションコードのサイズが気になる場合、そうです（そして、多くの場合、それらは（「単純な」アプリケーションではなく、解釈されたプログラミング言語で書かれたプラットフォームの上にある層であるためです）、しかしそれを比較してください）同等のものに。メールクライアント、オフィススイート...あなたはそれに名前を付けます。これらはすべて非常に複雑で、パイプを介して通信する2つのプロセスとして実装するには機能が多すぎます。多くの場合、これらのアプリケーションを使用するタスクも複雑です。複雑な問題に対する優れた簡単な解決策はありません。

UNIXのモットー「少しは機能するがそれが得意なアプリケーション」のモチベーションを少し超えて考える時がきたのかもしれません。「アプリケーション」を「一般的なモジュラーユニット」に置き換えると、基本的な優れたプログラミングプラクティスの1つに到達します。つまり、部品を再利用して個別に開発できるように、モジュール化することです。それが本当に重要なことです、IMHO（そしてプログラミング言語の選択はそれとほとんど関係がありません）。

ps （コメントに続く）：厳密に言えば、あなたはほとんど正しい-WebアプリケーションはUNIXの哲学（いくつかの小さなスタンドアロンプ​​ログラムに分割される）に従っていない。それでも、アプリケーションとは何かという全体的な概念は曖昧に思われます。通常はフィルタとしてのみ機能しsedますが、状況によってはアプリケーションであると考えることができます。

したがって、それはあなたが文字通りそれを取りたいかどうかに依存します。プロセスの通常の定義を使用する場合-カーネルがそれを認識するという意味で、単一のプロセスとして実行されているものは、たとえば、モジュールによってhttpdで解釈されるPHP Webアプリケーションはまったく逆です。ロードされた共有ライブラリはまだ単一のプロセスの範囲に含まれますか（同じアドレス空間を使用しているため）、またはそれらはすでに別のもの（プログラマの観点から不変であり、完全に再利用可能で明確に定義されたAPIを介して通信）ですか？

一方、今日のほとんどのWebアプリケーションはクライアントとサーバーの部分に分割されており、通常は異なるシステム（および物理的に分離されたハードウェア）で別々のプロセスとして実行されています。これら2つの部分は、明確に定義された（通常はテキスト）インターフェース（XML / HTML / JSON over HTTP）を介して相互に通信します。多くの場合（少なくともブラウザでは）、アプリケーションのクライアント側（JavaScript / DOM、入力/出力...）を処理するいくつかのスレッドがあり、時にはプラグインを実行する個別のプロセス（Java、Flashなど）さえあります。 ）。これは、特にLinuxでは、元のUNIXの哲学とまったく同じように聞こえ、スレッドは（ほぼ）すべてのアカウントによって処理されます。

それに加えて、サーバーの部分はほとんど常にいくつかの個別の部分に分割されます-構造化（または非構造化）データに対して要求された操作を実行する個別のデータベースエンジンは、標準的な例です。データベースをWebサーバーに統合することはあまり意味がありません。それでも、データベースをいくつかのプロセスに分割することはあまり意味がありません。たとえば、リクエストの解析、データストレージからのデータのフェッチ、データのフィルタリングのみに特化します。ほとんどの時間を互いに話し合うほとんど無能な労働者の群れ。

テキストインターフェース：40年前に処理されたデータのための真のあったものを必ずしも真実今日はないことに注意してください-バイナリフォーマットは、両方のデ/シリアル化のために必要なスペースと電力で安価であり、データの量が非常に大きくなっています。

もう1つの重要な質問は、UNIXの哲学の実際の対象は何でしたか。私は、数値シミュレーション、銀行システム、または公的にアクセス可能なフォトギャラリー/ソーシャルネットワークがこれまでにないように思います。ただし、これらのサービスを実行しているシステムのメンテナンスは確かに行われており、将来的にも行われる可能性があります。

Unix哲学がWebアプリケーションの設計に存在したことがあるかどうかはわかりませんが、多くのWebアプリケーションがあなたが説明したとおりに動作することは事実ですが、最近のWebアプリケーションはデータ消費者である可能性が高いと考えるかもしれません（ますますapi / webサービス駆動型のWeb利用のためのデータを生成する方法を考えると）。
これにより、相互に連携する小さな再利用可能なコンポーネント（JavaScript関数の形式）の使用が促進されるため、小さな並列処理が存在する可能性があります。