application.rb
Rails スタック全体でミドルウェアを実行し、config.ru
Rails スタックを先取りするという理解で正しいでしょうか?
つまり、たとえば、Rails アプリと同じセッションやその他の機能にアクセスしたい場合、ミドルウェアをapplication.rb
? ただし、私がやっていることは必ずしもRailsに依存していない場合は、config.ru
?
application.rb
Rails スタック全体でミドルウェアを実行し、config.ru
Rails スタックを先取りするという理解で正しいでしょうか?
つまり、たとえば、Rails アプリと同じセッションやその他の機能にアクセスしたい場合、ミドルウェアをapplication.rb
? ただし、私がやっていることは必ずしもRailsに依存していない場合は、config.ru
?
私は Rails/Rack の専門家ではありませんが、いくつかのラック アプリとミドルウェアを作成しました。ということで、これで頑張ってみます。
ここでは、初期化とランタイム実行という 2 つの別個のプロセスが行われます。初期化中、Rack互換サーバーはconfig.ru
デフォルトであなたのファイルで起動します。その場合、run YourApp::Application
行の前にあるものは、ファイルに明示的に含まれていないものにはアクセスできませんconfig.ru
。だからuse MyMiddleware something: MyRailsModel.first
うまくいきません。同じことをapplication.rb
orenvironment.rb
またはconfig/initializers/*.rb
Rails の初期化プロセスの途中で行うとしたら、すでに初期化されているすべてのものにアクセスできます。これは、おそらく必要になる Rails コアのすべてのものです。
しかし、それはすべて単なる初期化であるため、ミドルウェアに送信する構成引数にほとんど適用されます。実行時に、Rails はすでに完全に初期化されており、Rails のクラスやモジュールなどにアクセスできるはずです。しかし、必ず実行rake middleware
してスタックを調べ、独自のミドルウェアが他のミドルウェアやアプリ自体。Rails は単なる実際のアプリではなく、多くのミドルウェアをスタックに挿入します。また、スタック内の他のミドルウェアとの関係でミドルウェアがどこにあるかによって、リクエストの状態に影響します。
特にセッションに関しては、最近の Rails バージョンは Rack セッションを使用しているため、Rack からセッションにアクセスする際に問題は発生しないはずです。
おそらく、あなたが望むほど単純または決定的な答えではないことはわかっていますが、うまくいけば役に立ちます。ラックとミドルウェアは最初は複雑に見えますが、最終的にすべてがどのように機能するかをまとめてみると、舞台裏で行われているマジックはあまりなく、その最大の強みはその単純さにあることがわかります。理解しやすくなります。 .