こんにちは、ヤプリで iOS エンジニアをしている三宅 (@tsushi130) です。
アプリエンジニアの方は使ったことのある人が多いと思いますが、今回は標題の Proxyman の活用について「エラーの動作検証」と「不具合調査」の 2点 紹介できたらと思います🙌🏻
エラーの動作検証
正常系はともかく、異常系の動作検証は例えばサーバーをモック化してエラーレスポンスを返すようにしたり、何かと準備が大変でコストが高かったりします。
そんなコストの高いエラーの動作検証ですが、Proxyman の Map Local という機能を利用して「特定のリクエスト時にエラーのレスポンスを返却」することで、とても簡単に動作検証や開発を早めることができます。
以下は公式ページから引用させていただいた画像ですが、Matching Rule で URL や Request Method を指定することで、特定のリクエストに限定してレスポンスを書き換えることができます。また wildcard も利用できるため、API 全体のレスポンンスを書き換えることも簡単です。
Map To で対象のリクエストが来た時に返却したい Response Header や Response Body を記述することができます。また、外部ファイルを指定することもできるので、チームや QA さんと共有するなど便利です。
エラーに該当するレスポンスに書き換えることで、簡単に動作検証ができそうです・・！
不具合調査
ストア公開済みのアプリではデバッグが困難だったり、開発環境でのデバッグでもリクエストやレスポンスを確認するには多少手間なこともあると思います。
そんな時には Proxyman をサーバー間の Traffic を Capture する中間者サーバーとして機能させることで、簡単に Request / Response の Header や Body を確認できます。
また、Break Point という機能を利用すると、Map Local と同様に特定のリクエスト時に「即時にレスポンスの書き換え」を行うことができるため色々な条件を検証したりしやすく、特にヤプリは Server-Driven UI な一面もあるので、柔軟にレスポンスを検証できるのはとても便利です。
まとめ
Proxyman を活用したデバッグ方法についていくつか紹介させていただきました！
気軽には難しい検証も、Proxyman を活用することで柔軟かつアプリのコードを変更せずに実施できるため、今後も様々なシーンで活用できればと思います。
一方で Traffic の Capture が簡単であることは、裏を返すと Request / Response を傍受されるリスクでもあるので、API 側での Validation を欠かさない、セキュアな情報は平文で乗せないなど、セキュリティ観点でも意識しながら開発に臨めるとよいですね🙌🏻
引き続きヤプリのアドベントカレンダーをお楽しみください！🎉
