Unix哲学はWebアプリケーションの設計で放棄されましたか？
Unix哲学は、共有メモリスペースやリンケージではなく、パイプ、FIFO、ソケットなどのプロセス間通信の形式と連携する、一般的に再利用可能な小さな協調プログラムの使用を推奨しています。プログラムMHとuzblは、Unix哲学を設計で例示するアプリケーションの例としてよく挙げられます。
もしそうなら、Unix哲学がWebアプリケーションの設計で完全に放棄されたというのは本当ではありませんか？現在、リクエストを処理するほとんどすべてのWebアプリケーションは、1つのリソースだけでなく、ドメイン全体のすべてのリソースに対して、リクエスト/レスポンスサイクル全体（外部データベースプログラムの呼び出しを除く）を処理する単一の大規模なモノリシック長時間実行プロセスとして構築されています。
これは主に、外部プログラムのコレクションにパイプしてWeb要求への動的応答を構築するために、プロセスの起動時のオーバーヘッドが大きすぎるためですか？ RubyまたはPythonスクリプトにパイプアウトしたい場合は、これがどのように当てはまるかがわかりますが、Haskellのような言語を使用している場合は可能です。コンパイルすると、Webアプリを構築する際にUnix哲学に従うことへの本当の障害はなくなりますか？
それは、アプリケーション間の境界をどこに描くか（つまり、アプリケーションの定義は何か）、およびどのユースケースを考慮するかに大きく依存すると思います。
wget/curlの融合としてWebブラウザーを実装することもできますが、各ドキュメントノードの単純なアプリケーションを呼び出すHTML/XMLパーサー、すべてと対話するスタンドアロンのJavaScriptエンジンこれと、上記の出力を画面に「ただ」配置する（そして入力をコア調整プロセスに戻す）「単純な」表示装置は、（おそらく他の）他の今日のブラウザーよりもさらに厄介です。
データを外部プロセスにパイプすることに関しては-それが実際の方法です 開始 。平均的なWebアプリケーションコードのサイズが心配な場合は、そうです（多くの場合、「単純な」アプリケーションではなく、インタープリター型プログラミング言語で記述されたプラットフォームの上にあるレイヤーであるため）が、比較してください。それらの同等物に。電子メールクライアント、オフィススイート...あなたはそれに名前を付けます。これらはすべて非常に複雑であり、パイプを介して通信する2つのプロセスとして実装するには機能が多すぎます。これらのアプリケーションを使用しているタスクの場合も、多くの場合複雑です。複雑な問題に対する良い簡単な解決策はありません。
たぶん、UNIXのモットーである「少しはやるがそれが得意なアプリケーション」の背後にある動機を少し超えて見る時が来たのかもしれません。 「アプリケーション」を「一般的なモジュラーユニット」に置き換えると、基本的な優れたプログラミング手法の1つに到達します。モジュール化して、パーツを個別に再利用および開発できるようにします。それが本当に重要なことです、私見（そしてプログラミング言語の選択はそれとはほとんど関係がありません）。
ps（コメントに続く）：厳密な意味では、あなたはほとんど正しいです-WebアプリケーションはそうではありませんUNIX哲学（いくつかの小さなスタンドアロンプログラムに分割される）に従います。それでも、アプリケーションが何であるかという概念全体はかなり曖昧に見えます-sedは、通常はフィルターとして機能しますが、一部のアプリケーションと見なされる可能性があります 状況 。
したがって、それは文字通りあなたがそれをどのように取りたいかによります。プロセスの通常の定義を使用する場合-単一のプロセスとして実行されているもの（カーネルがそれを見るという意味で）、たとえば、モジュールによってhttpdで解釈されるPHP Webアプリケーションは正確ですロードされた共有ライブラリは、（同じアドレススペースを使用するため）単一のプロセスの範囲に含まれますか、それともすでに分離されていますか（プログラマーの観点からは不変であり、完全に再利用可能で、明確に定義されたAPIを介して通信します） ）？
一方、今日のほとんどのWebアプリケーションは、クライアントとサーバーの部分に分割されており、通常は異なるシステム（および物理的に分離されたハードウェア）で別々のプロセスとして実行されます。これらの2つの部分は、明確に定義された（通常はテキストの）インターフェイス（XML/HTML/JSON over HTTP）を介して相互に通信します。多くの場合（少なくともブラウザでは）、アプリケーションのクライアント側（JavaScript/DOM、入力/出力...）を処理しているいくつかのスレッドがあり、場合によっては個別のスレッドもありますプラグイン（Java、Flashなど）を実行するプロセス。これは、特にLinuxでは元のUNIX哲学とまったく同じように聞こえます。ここでは、スレッドはプロセスによって（ほぼ） ）任意のアカウント。
それに加えて、サーバーの部分はほとんどの場合、いくつかの別個の部分に分割されます。構造化（または非構造化）データに対して要求された操作を実行する個別のデータベースエンジンは、標準的な例です。データベースをWebサーバーに統合することはあまり意味がありません。それでも、データベースをいくつかのプロセスに分割することはあまり意味がありません。たとえば、リクエストの解析、データストレージからのデータのフェッチ、データのフィルタリングのみを専門とするプロセスです。全能の巨大なものを作成することと、ほとんどの時間を互いに話し合うことに費やすほとんど無能な労働者の群れ。
textualインターフェイスについて：40年前に処理されたデータに当てはまることが、今日では必ずしも当てはまらないことに注意してください。バイナリ形式は、スペースとデ/シリアル化に必要な電力の両方で安価です。そして、データの量は非常に多くなります。
もう1つの重要な質問は、UNIX哲学の実際のターゲットは何だったのかということです。数値シミュレーション、銀行システム、または公的にアクセス可能なフォトギャラリー/ソーシャルネットワークはこれまでになかったと思います。 これらのサービスを実行しているシステムのメンテナンスは、確かにこれまでも、そして将来もそうなるでしょう。
Unix哲学がWebアプリケーションの設計に存在したかどうかはわかりませんが、多くのWebアプリケーションが説明したとおりに動作することは事実かもしれませんが、最近のWebアプリはデータ消費者である可能性が高いと考える人もいるかもしれません。 （Web消費用のデータを生成するAPI/Webサービス主導の方法が増えていることを考えると）。
これは、相互に連携する小さな再利用可能なコンポーネント（JavaScript関数の形式）の使用を促進するように見える可能性があるため、小さな並列が存在する可能性があります。