Webサービス開発でのPostman活用方法

Postman Tokyo Meetup 2024.1 発表資料

Transcript

1. Postman Tokyo Meetup 2024.1 Webサービス開発でのPostman活⽤⽅法 2024/1/29 株式会社Future Techno Developers 中川 聡也
2. 謝辞 本日は登壇の機会をいただき、ありがとうございます。
 まず初めに、主催者の皆様、そして参加者の皆様に
 心から感謝申し上げます。
 1
3. サーバーレス：Serverless/Cloudflare/Momento /TiUG ゲーム‧アプリ：IGDA Japan / Japan Android Group Cloud Native：OCha Cafe! 他も顔出してます。どこかであったら声かけてください まずは⾃⼰紹介 @xiombatsg
 2 中川 聡也｜Satoya Nakagawa 何をしている⼈？ 商品開発をしているお客様を技術⾯でご⽀援 チーム構築のご⽀援(Platform Engineer,SRE…) どんなジャンル？ ゲーム/Webサービス/CG/組み込み/etc… どんなコミュニティに顔を出している？ Zenn: https://zenn.dev/nakagawa_satoya Postman利⽤歴 6年
4. 事業紹介 3 プロジェクト⽀援事業 Webサイト運営事業 ソフトウェア開発事業 Web診断事業 当社サービス 代理店‧顧客ご紹介企業様 お客様 保守担当メンバー‧パートナー 弊社は「ソフトウェア商品開発をサポートする」企業です
5. 最近こんなチラシを作りました
6. コミュニティ宣伝
7. もめんと会
8. 本題
9. 今⽇話すこと アジェンダ 8 無料版で頑張る話ではないです。 01 ⾒積り編 02 設計編 03 実装編 04 テスト、運⽤、その他 05 今後したいこと
10. まずは、
 Postmanの環境

11. PostmanはPro プラン運⽤ 1. うちでは固定のスタッフがほとんどいないので、プロジェクト採⽤を しています。 2. 時には海外のオフショアの⽅などもアサインしており、セキュリティに はとにかく気をつけています。 10 Proプランで運⽤しています Postmanファイルの受け渡しで パーソナル運⽤できますが、作 業効率やセキュリティを考え て、Proにしています
12. ワークスペースの作成 1. プロジェクト採⽤のため、チーム権限でもアクセスできないように 2. 複数掛け持ちの⽅は、両⽅に招待する形を取っています 11 ワークスペースの作成は常にプライベートで 本当はグループ管理にしたいん ですが、Enterprise 利⽤が必要 になってくるためこの形で落ち着 いています
13. ちなみに、料金 Pro プラン ※ピーク時は10~20slotsを使う時も 1. 1年で⾊々メンバーが⼊れ替わるのでMonthlyで⽉毎に管理しています(slot減らすのは⾯倒） 2. Flow Editor は中川が実験のために⼊れています(他のメンバーには触らせることはないかなと）
14. ⾒積り編
15. Web開発案件⾒積りってどうやってます？ 14 Laravel? Ruby on Rails? Wordpress? microCMS? 外部サービスは何使う？ 画⾯数は？ API数は？ テーブル数は？
16. ⾒積りで気にしていること 1. ⾒積りを求められるけど、その⾒積りがほぼ予算になる 2. ⾒積り担当者と作業担当者が変わるので、⾒積りの想定からずれることが多い 3. ⾒積り段階である程度、概要設計みたいなことはいつもしているので、これを作 業担当者にしっかり伝える 4. でも、失注したくないから翌営業⽇には⾒積り出したい 15 ⾒積りは早さと正確さが求められるけど、雑にやりたくない
17. 特に外部連携の⾒積り難しいですよね？ 16 SNS? Payment? お客様の基幹システム？ 画⾯数やAPI数はわかる けど、 外部連携は触らないとわ からないなぁ
18. うちではPostman で検討つけています 17 Postmanでは ある程度主要なサービスはワークスペースがある ことが多いです とにかくそれっぽいのを⾒つけたらワークスペースをfork
19. みつからない場合は 18 みつからない場合でも公式ドキュメントを読んで、コレクショ ンを作って、検討するのはすぐにできます。 例：銀⾏コードを取得するAPI SwaggerやOpenAPIが公式で公 開されているケースも増えてきた ので、そちらを探してインポート するのでも良いです。
20. ⾒積り後に向けて 19 この段階では失注する可能性はありますが、ストックしておく ことで、同様の案件の時に素早く検討できるようになります。  また、設計でも結局使いたくなるので、⾒積りで作った ワークスペースは残しましょう
21. 設計編 ※画⾯設計やテーブル設計など⾊々あります がそこは割愛
22. うちでは設計はCollectionで 21 Collection で設計するメリット 1. OpenAPIが普通に難しい 2. 外部の⽅が書けることはほぼ稀 3. ⾒積りの資産が使える Collection で設計するデメリット 1. OpenAPIの納品が必要だと⾯倒（うちのケースだとほぼないです。） 2. 設計タイミングではレスポンスを返すバックエンドが構築できていないことが多い
23. OpenAPIって難しくないですか？ 22 しっかり書こうとすると それなりに⼯数かかる モックサーバーを作っ て、Collectionでリクエ ストを保存して活⽤する ぐらいでよくないです か？
24. Collection から OpenAPIには変換できます ※https://www.postman.com/postman/workspace/postman-open-technologies-convert-post man-collections-into-openapi/overview うちではPostman to OpenAPI を使っています。
25. OpenAPIに変換する流れ 変換 1. Collectionをエクスポート 2. postman to openapi で openapi.yml に変換 (エラーが出る時があるので直します） 3. OpenAPIファイルに
26. OpenAPIにできれば htmlのドキュメントも作成できます うちではReDoc を使⽤しています。OpenAPI Generator で吐き出すHTMLだと⼀部出⼒されないもの があり、ReDocに落ち着きました ReDoc CLI で変換しています。
27. 実装編
28. OpenAPI は 色々なソースコードに変換できます ※https://openapi-generator.tech/ ⼤体の⾔語、環境向けに⽤意されているので、ほとんどカバーできます。
29. フロントはtypescriptで 1. typescript-axiosも使⽤していた時期もありますが、Node v18以降で fetch が標準対応されたので、fetch版を使⽤しています 2. またaxiosは⾊々対応が必要なことも多かったので、特に理由がなけれ ばfetchの利⽤をお勧めします。 3. ⾮typescript環境で使⽤したい場合は、typescriptだけ、bundleする対 応もしていましたが、最近はtypescriptをそのまま使⽤できる環境が増 えたので、typescriptで利⽤しています。 28 typescript-fetchで運⽤しています。
30. ラップして利用しています。 ※ラップして利⽤ ※Configurationをカスタマイズ
31. バックエンドは。。。実は使用していません 1. Laravel の場合 laravel-json-api を使⽤しているのですが、Generator の出⼒をそのまま活⽤することができません。 a. laravel-json-api の場合 スキーマファーストの開発になってくるの で、APIファーストと相性が悪く。組み込めないです。 b. laravel-json-apiを使⽤しないで、API作成したり模索中ではありま すが、プログラム構造上そのまま利⽤するのが難しいです。 2. Ruby, Java なども利⽤できる箇所もあるかもしれませんが、使⽤する フレームワークによって、使えたり使えなかったりがあるかと思いま す。 OpenAPI Generator の出⼒が噛み合わない
32. APIテスト編
33. APIテストはPostmanでしています 1. テストタブは開発時の実装確認に使⽤しています 2. 結合試験などのケースではコレクションを⼀つ⼀つ実⾏し、 結果を保存して、エビデンスにしています Postmanでのテスト テストタブではなくテストをコレクションで実⾏する 結合試験などのテストでは私が⾏うケースや外部テスターが⾏うケースなどあり、実装者とは別で ⾏うため、コレクションの実⾏結果をテストエビデンスにしています。 もちろんテストタブも Newman など CI環境でのテストに使⽤しています。
34. 運⽤編
35. Postman モニターで外部サービスのダウン検知しています。 1. Postman モニターで外部サービスのダウン検知しています。 まだやり始めたばかり 2. サービスの死活監視はCloudWatch とかやっていると思いま すが、案外外部サービスの死活監視ってできていなかったの で、定期的に実⾏して確認するようにしています。 Postman Monitor
36. 最近起こって慌てたこと Rapid APIとは API Marketplace で 利⽤料を払って、使⽤する サービスです。お客様都合で、こちらの利⽤ケースがあります。 アプリが運営都合でなくなってしまい、代替サービスを探す Rapid API のアプリがなくなってしまった 外部サービスのエンドポイントが急に変わる ⼀部のサービスですが、連絡もなく、変わるサービスがあります。 1年に数回あり、都度、切り替えて対応。 こういった課題をPostman Monitor で⾒える化
37. その他やっていること 1. 運⽤時の問い合わせなどのチェック 2. データの登録 3. などなど コレクションでデータメンテナンス
38. 今後やりたいこと
39. 設計にPostman Flowsを取り入れたい 1. 難しいロジックをPostman Flows で動くシーケンス図？とし て渡せれば実装者の⼿も早くなるのではと期待しています。 決済トランザクションなど難しいものはCollectionだけだとわかり づらい
40. ご清聴ありがとうございました