しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

ngrok を使ったら Webhook のデバッグが非常に捗った話

SendGrid の Inbound Parse Webhook を使うコードは、Webhook 自体を公開しないと API 側が叩けないため、思った以上にデバッグがしにくいです。

前に便利ツールの紹介とかがあった気がしたので調べたら、公式ブログに Webhook をデバッグするいい感じの方法が紹介されてました。

1. RequestBinのようなWebhookのリクエストを収集するツールを利用して、Webhookがどういったリクエストを送信するか確認する
2. cURLやPostmanのようなツールを利用してテスト用のリクエストを生成する
3. ngrokのようなツールを利用してローカルマシン上でプログラムをテストする
4. Runscopeのようなツールを利用して全体のフローを確認する

Webhookとは? | ブログ | SendGrid

Visual Studio で開発しているので、デバッガーをアタッチした状態で Webhook を叩いてくれたら中身を自由に見れるわけです。なので今回デバッグのために ngrok を使ってみました。

ngrok について

ngrok - secure introspectable tunnels to localhost

f:id:shiba-yan:20150126235737p:plain

公式サイトの図を見て分かるように、インターネット上に公開されている特殊なエンドポイントに対してのリクエストを、関連付いているローカルマシンのポートに転送してくれるサービスです。

面倒なアカウント作成などは不要で、各 OS 向けのクライアントをダウンロードして、以下のコマンドで起動すればすぐに使えます。

ngrok (転送先のポート番号)

起動すると公開されているエンドポイントの URL が表示されるので、この URL を SendGrid の Parse Webhook として登録しました。あっという間です。

f:id:shiba-yan:20150126235158p:plain

肝心の IIS Express が使っているポート番号は、デバッグ実行すれば表示されるので問題ないはずです。

IIS Express と使う

ngrok を使うと localhost ではなく 127.0.0.1 に対してリクエストが転送されるので、IIS Express で動かしている場合そのままでは 400 エラーになってしまいます。これはアプリケーションがホスト名 localhost に対してバインドされているので、applicationHost.config を修正して対応します。

Make IIS Express works with http://127.0.0.1 | Cyan By Fuchsia

この記事では書いてないですが netsh http add urlacl を叩いて ACL に追加する必要もあります。

IIS Express の設定が終わってしまえば、何の問題もなく ngrok を使って Webhook のデバッグが出来るようになります。リモートデバッグも便利ですが、やはり開発マシン上でデバッグ出来た方が効率が良いです。

f:id:shiba-yan:20150126235207p:plain

localhost へ転送してくれるだけでもかなり便利なんですが、localhost:4040 で開くことが出来る Web インターフェースから直近のリクエストをリプレイすることも出来て、デバッグ用途として最高でした。

転送先のサーバーがエラーを返してもログを保存してくれていて、すぐに確認出来るのも良い感じです。