(TL;DR ... 申し訳ありません!)
G-WAN と非常によく似たプロジェクトに取り組んでいます。最初に、私は API サーブレットを作成しましたが、これは非常にうまく機能しましたが、G-WAN の機能を十分に活用していませんでした。G-WAN サポートからのヒントを参考にして、ハンドラーの使用を検討し始めました。API サーブレットをハンドラーの URL 書き換えルーチンに移植しました (API クエリに対して返されるコンテンツの大部分は、静的または事前にレンダリングされたコンテンツです)。私は現在、404 ハンドラー ルーチンに取り組んでおり、(まだ) コンテンツが事前にレンダリングされていないケースをキャッチし、それらをオンデマンド レンダリング リクエストに変換し、応答を動的に構築しています。
クライアント側から見ると、すべてが完全に動的に見えます。しかし、静的パスへの URL 書き換えを行い、G-WAN がオンデマンド ケースをディスパッチできるようにすることで、記述しなければならないコードの量を削減し、G-WAN の高度に最適化された機能を利用できます。これらの詳細は、Gil が「型を破る」と呼んだことの例として言及しています。当初、私たちのアプローチは、nginx で実装を行う方法によく似ていました (ただし、fcgi のようなゲートウェイは必要ありません)。要件を取り除き、Web サービスの構築方法に関する多くの仮定を捨てたところ、かなり改善されました。
C++ での開発を計画している場合は、注意が必要です。G-WAN から外部ライブラリへのリンケージは「C」であり、「C++」ではありません。彼らはこのパフォーマンスとメモリ フットプリントの理由 (良い選択) を行いましたが、G-WAN サーブレットとハンドラー内から参照することを意図して C++ でいくつかのライブラリ ルーチンを書き始めたとき、私はそれを完全には考えていませんでした。さまざまな C++ アプリケーションから参照されます。それはショーストッパーではありません.C++アプリで問題なく動作する多くの「C」ライブラリがあります。しかし、サーブレットから G-WAN を介して「C」リンケージを介して動的 C++ クラス ライブラリ (.so) を参照するのは面倒です。(私の簡単な修正は、「共有」C++ コードを .h ファイルに移動し、それらを G-WAN ハンドラーとサーブレット、および C++ アプリに含めることでした。
G-WANの観点から、5つの特定のポイントに：
"analyse" と "unusual" の定義に応じて、これはプロトコル ハンドラ内で C/C++ で簡単に実行できます。また、外部ライブラリを利用することもできます。ブロックが問題になる場合は、個別のプロセスとして、または単に非ブロック I/O として、非同期にする方法が複数あります。
また、ハンドラーから簡単に管理できます。
同上。
はい。:) 必要なサポートのレベルによって異なります。SO およびその他のコミュニティ サポートのみに依存している場合は無料です。安価なサポート サブスクリプションを選択したところ、予想をはるかに超える反応がありました。
そうそう！最初の数日でそれを確認しました。
最後にもう 1 つ: G-WAN サーブレットの作成に 1 時間か 2 時間費やした後は、他の Web/アプリ/サービス メカニズムに戻るのに苦労するかもしれません。サーブレットでは、エディターから変更を保存し、ブラウザー ウィンドウで更新を押して新しい結果を確認するだけです (fcgi 実装で試してみてください!)。サーバー上で実行されている G-WAN の複数のインスタンス (さまざまな IP アドレスとポート番号用に構成されている) があるため、1 台のマシンで複数の段階の開発コード ベースと運用サーバーを使用しています。開発のために、G-WAN を (デーモンとしてではなく) ターミナル セッションで実行し、サーブレットとハンドラー コードで printf(...) を使用して、バックエンドで何が起こっているのか、バックエンドで何が起こっているのかを確認できます。私のブラウザウィンドウ。
詳細については:
幸運を！
ケン
