なにがでるか

少し前からSendGridのイベントデータの突っ込み先として Azure DocumentDB が使えないか調べていたところ、しばやんさんがこんなツイートしているのを見かけました。たまたまだったのですが、ちょうど突っ込む部分ができたので GitHub に上げておきました。 SendGridのイベントデータはEvent Webhookという機能を使って取得します。全てのイベントデータを自由に扱うために不可欠な重要な機能なのですが、取れるデータがスキーマレスのJSON形式のデータなので、いわゆるRDBに突っ込もうと思うとそれなりにスキーマの調整に手間がかかります。 こういうデータの保存先としては、 MongoDB （特に MongoLab → 最強 ）や Treasure Data なんかが相性がいいわけですが、ちょっと前にAzureでDocumentDBというサービスが追加されたとのこと、ちょっと出遅れた感はありましたが、丁度良い機会だったので試してみました。 DocumentDBのガイドをみると興味深い特徴がいくつもあります。 スキーマレス JSON REST API トランザクション ストアドプロシージャ トリガ SQLクエリ MongoDBっぽい使い方ができて、MongoDBがカバーしていないところをカバーしようとしている雰囲気が伺えます。いかにもMS様っぽい登場のしかたですね。 パッと見、この特徴だけ見るとSendGridのイベントデータをREST APIを使ってそのまま突っ込めばトランザクションも効いてトリガも使えて最強かっ！！と期待したのですが、残念ながらそんなに話はうまくいかなかったので、その辺中心にポイントとなる箇所をまとめてみます。 配列を受け付けてくれないREST API REST API を見て気になったのが、データを生成する際は配列を渡せないこと。 Create a Document では一つずつ渡すインターフェイスなんですね。 SendGrid側は基本的にイベントデータを配列で渡してくるので、REST APIでデータを突っ込もうと思ったらこのAPIを配列長分繰り返し呼ばなくてはいけません。パフォーマンス的に無理があるというのは直感的に想像がつきます。 認証に一手間必要なRES...

Twitter眺めてたらこんなのが目に飛び込んできた。 わかる、その気持ち。 でも、自宅PCでメールサーバ立てるのはちょっと面倒だ。ちょうどAzureとSendGridが使えたのでやってみた。ソースは Github に上げてあるので、誰でも今すぐ彼女がいるというステータスを手に入れることができる。 手順 とりあえずSendGridのアカウントを取得する。 次に、AzureでWebサイトを立ち上げて、Githubからデプロイするよう設定する。たぶんこの方法だと、自分が管理しているリポジトリしか指定できないのかな？よくわからないけど。その場合、 リポジトリ をForkしてから指定すればおｋ。 デプロイが終わったらWebサイトの「構成」を開いてアプリケーション設定を行う。 SENDGRID_USERNAME：SendGridのアカウント SENDGRID_PASSWORD：SendGridのパスワード FROM：彼女のメールアドレス。つまり、返信メールのFromに設定したいアドレス。 FROM_NAME：彼女の名前。今回はsayakaちゃんだ。ちなみにここで日本語を指定すると返信メール内の名前が文字化けする。アプリケーションはUTF-8を想定しているので、Webサイトのアプリケーション設定ってUTF-8じゃないのかも？よくわからないけど。 次に、SendGridのダッシュボードにログインして、 Inbound Parse Webhook の設定をしてドメインとURLを対応付ける。 今回は、Hostnameの設定は SendGridブログ にあるbymail.inを使った5分間アプローチを使ってみた。Urlの方はAzure Webサイト上でPOSTの受け口となるURL（http://????.azurewebsites.net/vp）を設定する。 以上で準備完了。 早速、さやかちゃんに確認のメールを送ってみる。 数秒待つと、さやかちゃんが返事をくれた。俺達付き合ってる。 キモいって言うな。 中の話 ちょっとだけ仕組みの話をすると、Githubからデプロイしたのはnode.js向けのWebフレームワークexpress 4で動くアプリケーション。こいつ...