ウェブサイトのためのプログラミング言語の相互運用
LAMPスタックで作成されたWebサイトと、MEANスタックで作成されたWebサイトがあるとします。パスワードのエントロピーを推定するプログラムを作成して、両方のサイトのサインアップページにパスワード強度メーターを追加できるようにしたい。 PHPとJavasriptの両方で同じプログラムを書きたくありません。
エントロピープログラムとLAMP/MEANサーバー間の相互運用を容易にする最良の（または少なくとも標準的な）方法は何ですか？
PHPのexecまたはNodeのchild_process.execを使用してエントロピープログラムを呼び出すのが最も簡単な方法のようですが、直接のシステムコールに対する警告を常に読んでいます。それとも、それは正しく行われなければならないというのですか？
UNIXソケットを使用する必要がありますか？
同じサーバーからのみアクセス可能なエントロピープログラム用にREST（またはWS *）APIを作成する必要がありますか？
別の方法はありますか？
この場合、私はエントロピープログラムにCを使用することを計画していますが、準拠または解釈された任意の言語で機能するソリューションを探しています。
あなたが達成しようとしていることは、 SOA（Service Oriented Architecture） として記述されます。これは、アプリケーションを、軽量のテクノロジーに依存しない、非常に疎結合で、きめ細かく、独立してデプロイ可能なサービスのセットとして定義します。プロトコル。この種のアーキテクチャは、モジュール性、テスト、個々のモジュール（マイクロサービスとも呼ばれる）の継続的なリファクタリングに重点を置いています。これは非常に若い概念であり、ベストプラクティスに関する全体的なコンセンサスはまだ得られていないため、質問に直接答えることは困難です。人々が通常同意するのは：
- 各サービスは、「1つのことを実行してそれをうまく実行する」という哲学を表す必要があります
- 各サービスは、特定のタスクに最適な言語を使用する必要があります
- 選択したプロトコルは言語に依存してはいけません
- すべてがサービスであるべきではありません
この最後の箇条書きは、SOAの概念に対する通常の批判の例であり、「ナノサービス」（つまり、サービス間の呼び出しのオーバーヘッドを正当化するには細かすぎるサービス）を作成する傾向に焦点を当てているようです。 。
このようなサービスに関しては、実際の「標準」または一般的に合意されている「グッドプラクティス」がないため、文字通り各サービスが異なるスタックを使用するアプリケーションを何年にもわたって見てきました。彼らはかなり簡単かつ効率的に相互に通信しましたが、新しい開発者のエントリーしきい値が高いため、個人的には反対することをお勧めします。
上記のように、私が見た中で最も一般的な解決策は、UnixソケットでリッスンしているC/C++デーモンでした。これらはローカルまたはネットワークを介して通信できるため、かなりスケーラブルです。また、C/C++言語が広く使用されており、プロジェクトに不慣れな人がそれを知っているか、インターネットですぐに助けを見つけることができる可能性が高いです。少し人気が低かったのは、シェルスクリプトとUnixソケットの使用でした。残りのSOAサービスは、共有メモリに保持し、必要な場所に含めるだけのJavaScriptに置き換えることがよくありました（通常のPHPスタイルとJavaScriptSPAスタイルの両方で簡単です。アプリケーション）。
Webサービスのアプローチを提案します。
任意の言語（c、nodejsなど）でjson形式のRESTサービスを作成します。
サービスはパスワードの引数を受け取り、分析結果とともにjson構造を返します。
このサービスは、既存のWebサイトから、たとえば単純なcurl呼び出しを介して簡単に使用できるモジュールです。
このサービスのセキュリティはさまざまな方法で実現できますが、簡単な例の1つは、プライベートlocalhostポートでのみリッスンするようにサービスを構成できるため、サブルーチン呼び出しと同じように既存のWebサーバーに対して安全です。
これは本質的に、概説したexecアプローチと非常に似ていますが、サービスは常に実行されているため、このアプローチの方が効率的です。同じプロセス間通信ですが、プロセスを開始してリクエストごとにデータを初期化する必要はありません。
パスワード強度メーターは、セキュリティに非常に敏感なソフトウェアです。理想的には、パスワードがサーバーに送信されないようにする必要があります。
これにより、ジレンマも解決されます。パスワード強度メーターを純粋なJavaScriptのクライアント側ウィジェットとして実装します。その後、このウィジェットを両方のWebサイトで簡単に再利用できます。
子プロセスの実行は避けるべきだと聞いたとき、それはほとんど正しいことです。プロセスの起動には、比較的長い時間がかかります。これにより、処理できる1秒あたりのリクエスト数が著しく制限されます。子プロセスがインタプリタである場合はさらにそうです。子プロセスのエラー処理は重要です。
いくつかの潜在的なセキュリティ問題もあります：コマンドラインパラメータはプライベートではありません。代わりに、秘密はパイプを介して伝達されるべきです。 PATH変数やファイルシステムのシンボリックリンクなどの機能のために、意図したプロセスを実行していることを保証するのは難しい場合があります。誤って間違ったプロセスを実行した場合、パスワードが危険にさらされる可能性があります。プライベートサーバーで実行している場合、これらのセキュリティ上の懸念はいずれも当てはまりませんが、それらを考慮することが重要です。
Cの使用に関する注意：Cは完全に優れた言語ですが、経験豊富なCプログラマーでない限り、Cを使用して安全なソフトウェアを作成するのは難しい場合があります。誤ってバッファオーバーフローが発生しやすく、正しいエラー処理を忘れがちです。 「大きな力には大きな責任が伴う」というスパイダーマンの原則が適用されます。
永続的なパスワード強度メータープログラムを実行し、ソケットまたはAPIを介してそれと通信することは、一種のマイクロサービスとして解釈される可能性があります。これにより、マイクロサービスのプログラミング言語がWebサイトの他の部分から独立しているため、複数のWebサイトで同じサービスを再利用できます。ただし、前述のように、ここではクライアント側の実装が非常に望ましいです。