PSGI / PlackでのWebアプリケーション開発の概要。 パート2

著者およびPragmaticPerl.comの編集長の許可を得て、私は一連の記事を公開し続けています。

元の記事はこちら。

PSGI / Plackに関する記事の続き。 Plack :: Builder、およびPlack ::ミドルウェアをより詳細に検討します。



前回の記事では、PSGI仕様、それがどのように表示されたのか、なぜ使用すべきなのかを見ました。 PSGIの実装であるPlackとその主要コンポーネントを調査し、それに割り当てられたタスクを実行する最も単純なAPIを作成し、主にPSGIサーバーを簡単に調査しました。



記事の第2部では、次の点を考慮します。

• Plack :: Builderは強力なルーターなどです。
• Plack ::ミドルウェア-「レイヤー」を使用して機能を拡張します。

事前分岐サーバーであるStarmanを引き続き使用します（事前実行プロセスのモデルを使用します）。

Plackの詳細:: Builder

前の記事で、Plack :: Builderを簡単にレビューしました。 今、それをより詳細に検討する時が来ました。 Plack :: BuilderとPlack :: Middlewareを考慮する決定は、非常に密接に相互接続されているため、非常に論理的です。 異なる記事のこれら2つのコンポーネントを考慮すると、両方の記事に相互参照が含まれることになります。これは、ジャーナル形式ではあまり便利ではありません。



Plack :: Builderの基本構造は次のようになります。

builder { mount '/foo' => builder { $bar }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構造は、PSGIアプリケーション（$バー）が/ fooに配置されることを示しています。 ビルダーでラップしたものは、関数への参照でなければなりません。そうしないと、次の形式のエラーが発生する可能性があります。



/usr/local/share/perl/5.14.2/Plack/App/URLMap.pm行71で「strict refs」が使用されている間、文字列（「stupid string」）をサブルーチン参照として使用できません。





ルートは、たとえば次のようにネストできます。

 builder { mount '/foo' => builder { mount '/bar' => builder { $bar; }; mount '/baz' => builder { $baz; }; mount '/' => builder { $foo; }; }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このエントリは、アプリケーション$ fooがアドレス/ fooに、アプリケーション$ barがアドレス/ foo / barに、アプリケーション$ bazがアドレス/ foo / bazにそれぞれ配置されることを意味します。



ただし、前のレコードを次の形式で記録することを誰も気にしません。

 builder { mount '/foo/bar' => builder { $bar }; mount '/foo/baz' => builder { $baz }; mount '/foo/' => builder { $foo }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

両方のエントリは同等であり、同じタスクを実行しますが、最初のエントリはよりシンプルでわかりやすいように見えます。 Plack :: Builderはオブジェクト指向のスタイルで使用できますが、個人的には手続き型で使用することを好みます。 オブジェクト指向形式のPlack :: Builderのアプリケーションは次のようになります。

 my $builder = Plack::Builder->new; $builder->mount('/foo' => $foo_app); $builder->mount('/' => $root_app); $builder->to_app;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このエントリは次と同等です：

 builder { mount '/foo' => builder { $app; }; mount '/' => builder { $app2; }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どの方法を使用するかは、純粋に個々の問題です。 Plack ::ミドルウェアを確認した後、Plack :: Builderに戻ります。

Plack ::ミドルウェア

Plack ::ミドルウェアは、CPANが「使いやすいPSGIレイヤー」と言うように、書くための基本クラスです。 これは何のためですか？ 特定のAPIの実装例を検討してください。



アプリケーションコードが次のようになっていると想像してください。

 my $api_app = sub { my $env = shift; my $req = Plack::Request->new($env); my $res = $req->new_response(200); my $params = $req->parameters(); if ($params->{string} && $params->{string} eq 'data') { $res->body('ok'); } else { $res->body('not ok'); } return $res->finalize(); }; my $main_app = builder { mount "/" => builder { $api_app }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプリケーションは正常に動作しますが、POSTメソッドを使用して送信された場合にのみデータを受信する必要が突然生じたと想像してください。



簡単な解決策は、アプリケーションを次の形式にすることです。

 my $api_app = sub { my $env = shift; my $req = Plack::Request->new($env); my $res = $req->new_response(200); my $params = $req->parameters(); if ($req->method() ne 'POST') { $res->status(403); $res->body('Method not allowed'); return $res->finalize(); } if ($params->{string} && $params->{string} eq 'data') { $res->body('ok'); } else { $res->body('not ok'); } return $res->finalize(); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題を解決するのに4行しかかかりませんでした。 ここで、別のアプリケーションを作成する必要があり、POSTメソッドによってのみ送信されたデータも受け入れる必要があると想像してください。 どうする？ この条件をそれぞれ記入しますか？ これは、いくつかの理由でオプションではありません。

• コードの量が増加し、その結果、エントロピー（単純な方が複雑な方が優れています）。
• 間違いを犯しやすい（人的要因）。
• プロジェクトを別のプログラマーに譲渡すると、彼は何かを忘れて何か間違ったことをする可能性があります（人的要因）。

そこで、問題を定式化します。 すべてのアプリケーションが、コードを変更せずに特定のプロパティを同時に取得することを確認できません。 それともできますか？



ミドルウェアエンジンは、アプリケーション全体にエンドツーエンドの機能を提供するのに最適です。 もちろん、対策を実感し、プログラム全体で本当に必要なコードのみを追加することは価値があります。



ミドルウェア（つまり、レイヤー）を構築するには、次の条件を満たしている必要があります。

• パッケージPlack :: Middleware :: MYCOOLMIDDLEWAREに入れます。MYCOOLMIDDLEWAREはミドルウェアの名前です。
• 基本クラスPlack ::ミドルウェアを拡張します（親qw / Plack ::ミドルウェア/;を使用）。
• 呼び出しメソッド（関数）を実装します。

したがって、上記のすべてを考慮して、最も単純なミドルウェアを実装します。

 package Plack::Middleware::PostOnly; use strict; use warnings; use parent qw/Plack::Middleware/; use Plack; use Plack::Response; use Plack::Request; sub call { my ($self, $env) = @_; my $req = Plack::Request->new($env); if ($req->method() ne 'POST') { my $new_res = $req->new_response(405); $new_res->body('Method not allowed'); return $new_res->finalize(); } return $self->app->($env); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何が起こったのかをさらに詳しく考えてみましょう。 基本クラスPlack :: Middleware（2ポイント）を継承し、呼び出しメソッド（3ポイント）を実装するパッケージPlack :: Middleware（1ポイント）にあるコードがあります。



提示された呼び出し実装は次のことを行います。

• Plack :: Middlewareおよびenv（my（$ self、$ env）= @_;）のインスタンスをパラメーターとして受け取ります。
• アプリケーションが受け入れるリクエストを作成します（前の例で使用したものと同様の作成）。
• POSTリクエストメソッドがそうであるかどうかをチェックし、ミドルウェアはリクエスト処理をさらにスキップします。

要求メソッドがPOSTでない場合はどうなるかを検討してください。



メソッドがPOSTでない場合、新しいPlack :: Responseオブジェクトが作成され、アプリケーションを呼び出さずにすぐに返されます。



一般に、ミドルウェアの呼び出し関数は、正確に2つのアクションを実行できます。 これは：

• アプリケーションを実行する前のEnv処理。
• アプリケーション後の結果の処理。

これについては、ニュアンスをまとめて理解するときに、記事の最後で説明します。

Sharing Plack ::ミドルウェアとPlack :: Builder

Plack ::ミドルウェア:: PostOnlyの既成レイヤーがあります。PSGIアプリケーションがあり、問題があります。 問題は次のようになります。「現時点では、アプリケーションの動作にグローバルに影響を与えることはできません。」 できるようになりました。 Plack :: Builderの最も重要なポイントであるenableキーワードを考慮してください。



enableキーワードを使用すると、Plack :: Middlewareをアプリケーションに接続できます。 これは次のように行われます。

 my $main_app = builder { enable "PostOnly"; mount "/" => builder { $api_app; }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、同時に非常にシンプルで非常に強力なメカニズムです。 すべてのコードを1か所にまとめて、結果を確認します。



PSGIアプリケーション：

 use strict; use warnings; use Plack; use Plack::Builder; use Plack::Request; use Plack::Middleware::PostOnly; my $api_app = sub { my $env = shift; warn 'WORKS'; my $req = Plack::Request->new($env); my $res = $req->new_response(200); my $params = $req->parameters(); if ($params->{string} && $params->{string} eq 'data') { $res->body('ok'); } else { $res->body('not ok'); } return $res->finalize(); }; my $main_app = builder { enable "PostOnly"; mount "/" => builder { $api_app }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ミドルウェア：

 package Plack::Middleware::PostOnly; use strict; use warnings; use parent qw/Plack::Middleware/; use Plack; use Plack::Response; use Plack::Request; sub call { my ($self, $env) = @_; my $req = Plack::Request->new($env); if ($req->method() ne 'POST') { my $new_res = $req->new_response(405); $new_res->body('Method not allowed'); return $new_res->finalize(); } return $self->app->($env); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションは、次のコマンドで起動されます。

 /usr/bin/starman --port 8080 app.psgi
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Plack :: Builderはパッケージ名を自動的にPlack ::ミドルウェアに置き換えるため、コードでは「PostOnly」を有効にしました。 enable "PostOnly"、つまりenable "Plack :: Middleware :: PostOnly"を意味します（+プレフィックスを使用してクラスへのフルパスを指定できます。たとえば、 "+ MyApp :: Middleware :: PostOnly"を有効にします。エディター）。



これで、GETメソッドを使用してlocalhost ：8080 /にアクセスすると、メソッドが405の応答コードで許可されていないことを示すメッセージが表示されますが、POSTメソッドでアクセスすると、すべて正常になります。



警告の「WORKS」行は、アプリケーションコードでは無駄ではありません。 メソッドがPOSTでない場合、アプリケーションが実行されないことを確認します。 GETを送信してみてください。STDERRスターマンにはこのメッセージは表示されません。



PSGIサーバーには、興味深い動作機能がかなりあります。これらについては、以下の記事で確実に検討されます。



Plack ::ミドルウェアのさらに便利なポイントを見てみましょう。

• アプリケーション実行後の処理結果。
• ミドルウェアにパラメーターを渡します。

2つのPSGIアプリケーションがあり、一方がPOSTで動作し、もう一方がGETでのみ動作することを確認する必要があるとします。 たとえば、次のように、GETメソッドにのみ応答する別のミドルウェアを記述することで、問題を真正面から解決できます。

 package Plack::Middleware::GetOnly; use strict; use warnings; use parent qw/Plack::Middleware/; use Plack; use Plack::Response; use Plack::Request; sub call { my ($self, $env) = @_; my $req = Plack::Request->new($env); if ($req->method() ne 'GET') { my $new_res = $req->new_response(405); $new_res->body('Method not allowed'); return $new_res->finalize(); } return $self->app->($env); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題は解決しましたが、多くの重複が残っています。



この問題を解決することで、次のことに対処できます。

• 変数をミドルウェアに渡すためのメカニズム。
• アプリケーション用のミドルウェアを個別に接続します。

この問題の解決策は次のとおりです。目的のメソッドを変数として渡します。 Plack :: Builderからの有効化の検討に戻りましょう。 enableは変数を受け入れることができます。 次のようになります。

 my $main_app = builder { enable "Foo", one => 'two', three => 'four'; mount "/" => builder { $api_app }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ミドルウェア自体では、これらの変数は$ selfから直接アクセスできます。 たとえば、変数oneに渡される値を取得するには、ミドルウェアコードで$ self-> {one}を参照する必要があります。 PostOnlyの変更を続けます。



例：

 package Plack::Middleware::GetOnly; use strict; use warnings; use parent qw/Plack::Middleware/; use Plack; use Plack::Response; use Plack::Request; sub call { my ($self, $env) = @_; my $req = Plack::Request->new($env); warn $self->{one} if $self->{one}; if ($req->method() ne 'GET') { my $new_res = $req->new_response(405); $new_res->body('Method not allowed'); return $new_res->finalize(); } return $self->app->($env); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スターマンを再起動し、localhost：8080にリクエストを送信します。STDERRには次のように表示されます。

 two at /home/noxx/perl/lib/Plack/Middleware/PostOnly.pm line 12.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、変数はPlack :: Middlewareに転送されます。



このメカニズムを使用して、ミドルウェアを作成します。

 package Plack::Middleware::Only; use strict; use warnings; use parent qw/Plack::Middleware/; use Plack; use Plack::Response; use Plack::Request; sub call { my ($self, $env) = @_; my $req = Plack::Request->new($env); my $method = $self->{method}; $method ||= 'ANY'; if ($method ne 'ANY' && $req->method() ne $method) { my $new_res = $req->new_response(405); $new_res->body('Method not allowed'); return $new_res->finalize(); } return $self->app->($env); } 1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ミドルウェアは、パラメータで渡されたリクエストメソッドにのみ応答できるようになりました。 わずかに変更された接続は次のようになります。

 my $main_app = builder { enable "Only", method => 'POST'; mount "/" => builder { $api_app }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、要求メソッドがPOSTである場合にのみ、アプリケーションが実行されます。



アプリケーション実行後の処理結果を検討してください。 メソッドが許可されている場合、「ALLOWED」という単語が応答本文に追加されるとします。



つまり、アプリケーションがokを与える必要がある場合、もちろん有効なメソッドで要求が実行されない限り、okはALLOWEDを与えます。



Only.pmを次のフォームに持っていきましょう。

 package Plack::Middleware::Only; use strict; use warnings; use parent qw/Plack::Middleware/; use Plack; use Plack::Response; use Plack::Request; sub call { my ($self, $env) = @_; my $req = Plack::Request->new($env); my $method = $self->{method}; $method ||= 'ANY'; if ($method ne 'ANY' && $req->method() ne $method) { my $new_res = $req->new_response(405); $new_res->body('Method not allowed'); return $new_res->finalize(); } my $plack_res = $self->app->($env); $plack_res->[2]->[0] .= 'ALLOWED'; return $plack_res; } 1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

$ self-> app->（$ env）は、3つの要素の配列（PSGI仕様）への参照を返します。その要素の本体は変更され、回答として提供されます。



許可されたメソッドによってstring = dataおよびstring = data1変数を渡すことにより、これがすべて正常に機能することを確認してください。 最初のケースでは、メソッドが有効になっていると、答えは「okALLOWED」になり、2番目の「not okALLOWED」になります。



結論として、上記のすべてを1つのPlackアプリケーションに正確に組み合わせることができる方法を検討します。 元のタスクに戻ります。 変数stringを受け入れる単純なAPIを開発し、string = dataがokの場合はok、そうでない場合はokを返し、次のルールも遵守する必要があります。



住所に連絡するとき/任意の方法に応答するとき。

アドレス/投稿にアクセスするときは、POSTメソッドにのみ応答します。

/ getアドレスにアクセスするときは、GETメソッドにのみ応答します。

実際、記述されるアプリケーションは1つだけです-$ api_appとわずかに変更されたビルダーです。



その結果、上記のすべてを使用して、次の形式のアプリケーションを取得する必要があります。

 use strict; use warnings; use Plack; use Plack::Builder; use Plack::Request; use Plack::Middleware::PostOnly; use Plack::Middleware::Only; my $api_app = sub { my $env = shift; my $req = Plack::Request->new($env); my $res = $req->new_response(200); my $params = $req->parameters(); warn 'RUN!'; if ($params->{string} && $params->{string} eq 'data') { $res->body('ok'); } else { $res->body('not ok'); } return $res->finalize(); }; my $main_app = builder { mount "/" => builder { mount "/post" => builder { enable "Only", method => 'POST'; $api_app; }; mount "/get" => builder { enable "Only", method => 'GET'; $api_app; }; mount "/" => builder { $api_app; }; }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、ミドルウェア接続はネストされたPlack :: Builderルートで機能します。 コードのシンプルさと一貫性に注意する価値があります。



延期された回答は、非同期サーバーに関する記事（Twiggy、Corona、Feersum）で検討されます。