Diceこの広告は、90日以上更新していないブログに表示しています。作りたいと思っていて色々調べていたのだけれど、以下のような場合にどうしようかなあと思っていた。Gateway経由でサービスを叩くアーキテクチャつまり別途フロントエンドのウェブページがあり、ブラウザを使ってAPI連携の検証をちゃんとしたいもちろんステージの概念があるのでAWSにフルデプロイしながら検証することもできなくはない。開発環境のテストにおいてローカルで完結できるというのは個人的な信条から必要だと思っているので何とかローカルで完結する検証環境をちゃんと作ってしまいたい。メインエントリをちゃんと書いて、handlerの設定を例えば次のようにしておくことでローカルで動作させるテスト自体は簡単にできる。挟み込んだユニットテストを書くことも相当楽にできる。ローカルサーバーで返してくれるような仕組みにしようとすると、生で書こうとすると骨が折れる。動作を行えるようなプロジェクトがあるが、対応のモチベーションがやはり低めっぽい。基本書かれているから、当然と言えば当然だとは思うけれど。内容ほぼそのままなので独立した別プロジェクトとして本格的に取り組んでいるわけでもなさそう。調べれば使えなくはないのかもしれないし、将来的にはpythonでもちゃんとofflineが使えるようになってるのかもしれないけれど、今回は自分で思い描いているサービスを作りたい欲の方が勝っているので採用を見送った。周りの連携に関して前例を調べてみる。すると、以下の公式ブログ記事が引っかかった。動作させるという記事だが、自分のやりたいケースとも一致する。利用して、WSGIというレイヤーを以下の通りうまく活用する。PythonのソースコードWSGI対応のソースコードできちんと書ければ、うまくローカル・本番環境の差し替えが実現可能となる。時に以下のことを行っている。ソースコードを呼び出す*1レイヤーをうまく重ね合わせる、というテクニックを利用しているのでもちろんオーバーヘッドは増えるというデメリットはある。Gateway経由で動作するアプリケーションをうまく作る、というところでありオーバーヘッドのデメリットを上回って自分のやりたいことができるというメリットを採用することとした。使って実装してみることにする。アプリケーションができるということを示すという意味でも。