5

いくつかのミッション クリティカルなアプリのために社内で使用する FastCGI ベースの Web フレームワークがあります。したがって、既存の PSGI 準拠フレームワークへの移行はあまり現実的ではありません。フレームワークを単純な古い CGI.pm から Plack ハンドラに移行することに成功しました。

ただし、Apache の構成ファイル内には、mod_rewrite ルールの形式で、非常に多くのルーティング ロジックがあります。Apache のリバース プロキシ経由で Plack::Handler::FCGI を使用して、新しく PSGI に準拠したフレームワークを使用するアプリをデプロイする場合、mod_rewrite ルールはいくつかの微調整を加えて、そこで引き続き機能すると思います。（これを行う予定ですが、まだ試していません）。

しかし、mod_rewrite の代わりとしての Plack::Middleware::Rewrite について読んで興味をそそられました。

mod_rewrite ルールを Plack::Middleware::Rewrite ルールに変換し、すべてのアプリ ロジックを完全に Perl に移行して、PSGI の利点を最大限に活用する必要がありますか?

答えはイエスだと思いますが、私は PSGI アプリをデプロイした経験がないので、正しい道をたどっていることを確認するために経験を共有できる人がいれば幸いです。

サブ質問 PSGI のアイデアは、Web サーバーの処理をできるだけ少なく (そしてできるだけ速く) し、他のすべてのものをアプリケーション サーバー (ミドルウェア) に委譲することですか?**

4

1 に答える 1

3

PSGI の利点は、展開の柔軟性です。mod_rewrite にルールがある限り、Apache を使い続けることになり、PSGI の利点を十分に活用できません。

ただし、Apache に満足している限り、すべてのルールを書き直す強い動機はないと思います。mod_rewrite が頭を悩ませているなら、それを試してみてください。

また、 Router::SimpleやPath::Routerなどを使用して、メインのアプリ コードにルーティング ロジックを配置することも検討してください。

ところで、あなたが本当に FastCGI に執着していない限り、Plack::Handler::FCGI を使用する理由はおそらくないでしょう。リバース プロキシとして Apache を使用すると、アプリは Starlet または他の Plack Web サーバーのいずれかで実行されます。

于 2013-09-17T03:04:29.037 に答える