お使いいただきありがとうございます。アップグレードするとアプリ起動後、記事一覧を読み込んだところでクラッシュしてしまいます。アップロードしたのですが、まだ審査待ちでリリースできていません。今しばらくお待ち下さい。gozo.SendFile(os.Args[1])みたいに書けたらいいと思ってますができません。それは諦めるとしてもちっとまともに書きたいんですがみなさんどうしてるんでしょうか。この記事が目に入って読んでみた。ルーター的なものとして認識されているのだな、と思った。なければ実装が不可能かと言えばそんなことはないものでもある。サーバー/インフラ的な側面でその役割を捉えている。何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。インフラ的な視点での役割は「Webシステム全体の系におけるリソース全体最適のための部品」である。なんのこっちゃ・・・ごめん、石投げないで。何でもいいのだがそのアプリケーションサーバーをバックエンドとしたときにフロントエンドで裁けるものはフロントエンドでバックエンドでなければ処理できないものだけバックエンドで処理するようにし「全体のリソース効率を上げましょう」というためのものである。最近はいろいろな実装があるので一概には言えないのだが、Webアプリケーションによるバックエンドのアプリケーションサーバーでは、特にスクリプト言語においては、それはマルチプロセスモデルを採用していることがほとんどだ。マルチプロセスモデルでは、1リクエストを1プロセスが担当することになる。従って、1システムで20プロセスが起動していたとすると同時に処理できる並行処理数は最大で20リクエストということになる。ご存知のようにアプリケーションサーバーはメモリを大量に消費する。メモリ使用量という文脈で「重い」と言える。その他大量のアセットを含む。導入していないシステムではこれらのすべてにアプリケーションサーバーが応答しなければならない。本来アプリケーションサーバーは、動的なリクエストを処理するために用意されているものであるにも関わらず、動的でないコンテンツにまで応答しなければならない・・・というので、先にみたように貴重なアプリケーションサーバープロセスが、どうでもいい静的ファイルのリクエストなどにも消費されてしまう、のである。アプリケーションサーバーの手前に配置する。クライアントに応答し、アプリケーションサーバーでなければ応答できないリクエストのみアプリケーションサーバーに転送する。ようにシングルプロセス・イベントドリブンなアーキテクチャの実装のものを用いる。的な意味のコンテキストスイッチングではなく、イベントの意味での。並行処理性能を稼ぐところが利点。そのためメモリ使用量の文脈では「軽い」。導入したい一番の理由である。リクエスト、あるいは大きなファイルをアップロードしてくるクライアントなど「あまり仕事はしないけどネットワーク接続の維持は要求される」されるような側面でも役に立つ。フロントだけ有効にしておきバックエンドは応答が終わったらそく切断、アップロードファイルは終わるまでフロント側でバッファリング・・・などである。この役割分担が、更に得意なものは得意なところで、というリソース全体最適化に寄与する。フロントエンド側でのアクセス制御というのはあくまで副次的な要素に過ぎない・・・というのがインフラ視点での認識ではある。フロントエンドエンジニアリングからしたらその視点が逆転する、というのはわからなくもない。賄ってしまうという力業を使う例も増えてる気もする。あったほうがいいよとは思うけど。・・・書いてるうちにだんだんドヤ顔になってきてしまった。自分の知識がある程度正しいという思い込みを前提に、きちんとこの辺の背景事情を続く世代に継承していけたらとも思うところです。ちなみに、この辺は『サーバー/インフラを支える技術』という(とっても)素晴らしい本に詳しく書かれているのでこちらを読むと良いと思う。介したデプロイを実践しているということを紹介した。契機に実行させると色々捗る、という話。このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。使うといろいろと都合がいい。レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。変更確定前に事前レビューするのにも向いてない。書けるようにするツール。