gRPCでの効率的なAPI開発とテストの進め方

Transcript

1. © KAUCHE, Inc. gRPCでの効率的な API開発とテストの進め方
2. © KAUCHE, Inc. 自己紹介 • Shin Uozumi • 株式会社カウシェ バックエンドエンジニア • Goと犬が好き
3. © KAUCHE, Inc. Agenda • カウシェについて • カウシェのAPI開発フロー • 振り返り • まとめ
4. © KAUCHE, Inc. カウシェについて “誰かと一緒に ”を楽しむ ショッピングアプリ
5. © KAUCHE, Inc. backend 技術スタック
6. © KAUCHE, Inc. 構成 API Gateway Customer Service Partner Service Farm Service
7. © KAUCHE, Inc. カウシェの API開発フロー
8. © KAUCHE, Inc. カウシェの開発フロー API仕様ファースト開発 APIの仕様を先に記述し、テスト駆動で開発を行う
9. © KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ
10. © KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ ここの話
11. © KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ
12. © KAUCHE, Inc. なぜAPI仕様を書くか • 元々protoファイルにはコメントがほとんど書かれていなかった API仕様の記述 ◦ user_idに紐づくユーザーが存在しない場合 どうなるか？ ◦ expire_timeに過去の日時を渡した場合は？
13. © KAUCHE, Inc. 以下のような問題があった • フロントエンドメンバーはAPIの仕様をバックエンドメンバーに聞かないとわからない • バックエンドメンバーも仕様を覚えていない場合、コードを読んで調べる必要がある • ロジックが複雑な場合、それなりに時間がかかり非効率 このような問題を解決するために仕様を書く API仕様の記述
14. © KAUCHE, Inc. API仕様の記述 書くこと 1. APIの説明 2. エラーの説明 3. 個々のフィールドの説明
15. © KAUCHE, Inc. API仕様の記述 APIの説明 APIの説明を簡単に記載 APIの振る舞いを記載
16. © KAUCHE, Inc. API仕様の記述 エラーの説明 返されるエラーと どういう場合に返されるかを記載 validationを定義しているものは コメントには記載しない
17. © KAUCHE, Inc. API仕様の記述 個々のフィールドの説明 各フィールドの詳細の説明
18. © KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ
19. © KAUCHE, Inc. E2Eテスト カウシェで行っているE2Eテストの書き方 • protoファイルに記載した仕様通りにAPIが振る舞うか確認 • E2Eテストでは「特定のマイクロサービス」をテストする
20. © KAUCHE, Inc. protoファイルに記載した仕様通りに APIが振る舞うか確認 protoのコメントに対応するようにテストを書く
21. © KAUCHE, Inc. マイクロサービスのテスト E2Eテストでは「特定のマイクロサービス」をテストする • マイクロサービスAのテストではマイクロサービスAだけをテスト • 依存するサービスはスタブを使う フロントエンド マイクロサービス A マイクロサービス C マイクロサービス B ここをテストする こっちはスタブ
22. © KAUCHE, Inc. 依存サービスのスタブ • protoファイルから自動作成されたインターフェース定義(xxx_grpc.pb.go) から生成する マイクロサービスのテスト
23. © KAUCHE, Inc. スタブの使い方 E2Eテスト 依存サービスのスタブ E2Eテストコード テスト対象サービス 1. RPCのレスポンスの設定 2. テスト実行 4. 1で設定したレスポンスを返却 3. RPC呼び出し
24. © KAUCHE, Inc. スタブのメリット • 並行で開発を進めることができる ◦ 依存するマイクロサービスの完成を待たずに実装することができる • エッジケースのテストができる ◦ 依存するサービスでエラーが発生したときの確認 ➢ Abortedが返された時にリトライするか等 マイクロサービスのテスト
25. © KAUCHE, Inc. 振り返り
26. © KAUCHE, Inc. • 仕様を確認する手間が減った ◦ 仕様が明確化によるコミュニケーションコスト削減 ◦ コードリーディング時間の削減 • リリース時のQAが効率化 ◦ 以前はQA環境に対して手動でAPIを叩いて確認していた ◦ QA環境に対してE2Eテストを実行すればOK メリット
27. © KAUCHE, Inc. • コードレビューの効率化 ◦ 機能性の確認が楽になった ➢ protoの仕様通りにE2Eテストが実装されていたら、意図通りにコードが動くことが 確認できる ➢ 設計や可読性、一貫性といった部分のレビューに注力できる • 外部品質と内部品質の向上 ◦ 外部品質と内部品質の向上 ◦ データベース移行もE2Eテストがあることで安心して進めることができている メリット
28. © KAUCHE, Inc. • CIの高速化 ◦ E2Eテストが増えてきてCIの実行時間が長くなっている ◦ 並列化しにくい部分がある ➢ テストデータがバッティングする ➢ 並列化するとFirestore EmulatorがAbortedを返す 今後の課題
29. © KAUCHE, Inc. まとめ
30. © KAUCHE, Inc. • API仕様ファースト開発により、開発プロセスの効率と品質が向上した ◦ 仕様の明確化でコミュニケーションコストを削減 ◦ テスト駆動により、内部品質と外部品質の向上 まとめ
31. © KAUCHE, Inc. 宣伝：積極採用中です！ カジュアル面談もやっています。 興味を持っていただけた方はぜひお気軽にご連絡ください。 We are hiring！ https://enjoy-working.kauche.com/
32. © KAUCHE, Inc. ご清聴ありがとうございました