Tweet
Tweet

Slide 1

Slide 1 text

© KAUCHE, Inc. gRPCでの効率的な API開発とテストの進め方

Slide 2

Slide 2 text

© KAUCHE, Inc. 自己紹介 ● Shin Uozumi ● 株式会社カウシェ バックエンドエンジニア ● Goと犬が好き

Slide 3

Slide 3 text

© KAUCHE, Inc. Agenda ● カウシェについて ● カウシェのAPI開発フロー ● 振り返り ● まとめ

Slide 4

Slide 4 text

© KAUCHE, Inc. カウシェについて “誰かと一緒に ”を楽しむ ショッピングアプリ

Slide 5

Slide 5 text

© KAUCHE, Inc. backend 技術スタック

Slide 6

Slide 6 text

© KAUCHE, Inc. 構成 API Gateway Customer Service Partner Service Farm Service

Slide 7

Slide 7 text

© KAUCHE, Inc. カウシェの API開発フロー

Slide 8

Slide 8 text

© KAUCHE, Inc. カウシェの開発フロー API仕様ファースト開発 APIの仕様を先に記述し、テスト駆動で開発を行う

Slide 9

Slide 9 text

© KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ

Slide 10

Slide 10 text

© KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ ここの話

Slide 11

Slide 11 text

© KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ

Slide 12

Slide 12 text

© KAUCHE, Inc. なぜAPI仕様を書くか ● 元々protoファイルにはコメントがほとんど書かれていなかった API仕様の記述 ○ user_idに紐づくユーザーが存在しない場合 どうなるか？ ○ expire_timeに過去の日時を渡した場合は？

Slide 13

Slide 13 text

© KAUCHE, Inc. 以下のような問題があった ● フロントエンドメンバーはAPIの仕様をバックエンドメンバーに聞かないとわからない ● バックエンドメンバーも仕様を覚えていない場合、コードを読んで調べる必要がある ● ロジックが複雑な場合、それなりに時間がかかり非効率 このような問題を解決するために仕様を書く API仕様の記述

Slide 14

Slide 14 text

© KAUCHE, Inc. API仕様の記述 書くこと 1. APIの説明 2. エラーの説明 3. 個々のフィールドの説明

Slide 15

Slide 15 text

© KAUCHE, Inc. API仕様の記述 APIの説明 APIの説明を簡単に記載 APIの振る舞いを記載

Slide 16

Slide 16 text

© KAUCHE, Inc. API仕様の記述 エラーの説明 返されるエラーと どういう場合に返されるかを記載 validationを定義しているものは コメントには記載しない

Slide 17

Slide 17 text

© KAUCHE, Inc. API仕様の記述 個々のフィールドの説明 各フィールドの詳細の説明

Slide 18

Slide 18 text

© KAUCHE, Inc. 開発フロー 1. 仕様の決定 2. protoにインターフェイス定義 & API仕様をprotoのコメントに書く 3. E2Eテストの作成 4. 実装 5. リファクタ

Slide 19

Slide 19 text

© KAUCHE, Inc. E2Eテスト カウシェで行っているE2Eテストの書き方 ● protoファイルに記載した仕様通りにAPIが振る舞うか確認 ● E2Eテストでは「特定のマイクロサービス」をテストする

Slide 20

Slide 20 text

© KAUCHE, Inc. protoファイルに記載した仕様通りに APIが振る舞うか確認 protoのコメントに対応するようにテストを書く

Slide 21

Slide 21 text

© KAUCHE, Inc. マイクロサービスのテスト E2Eテストでは「特定のマイクロサービス」をテストする ● マイクロサービスAのテストではマイクロサービスAだけをテスト ● 依存するサービスはスタブを使う フロントエンド マイクロサービス A マイクロサービス C マイクロサービス B ここをテストする こっちはスタブ

Slide 22

Slide 22 text

© KAUCHE, Inc. 依存サービスのスタブ ● protoファイルから自動作成されたインターフェース定義(xxx_grpc.pb.go) から生成する マイクロサービスのテスト

Slide 23

Slide 23 text

© KAUCHE, Inc. スタブの使い方 E2Eテスト 依存サービスのスタブ E2Eテストコード テスト対象サービス 1. RPCのレスポンスの設定 2. テスト実行 4. 1で設定したレスポンスを返却 3. RPC呼び出し

Slide 24

Slide 24 text

© KAUCHE, Inc. スタブのメリット ● 並行で開発を進めることができる ○ 依存するマイクロサービスの完成を待たずに実装することができる ● エッジケースのテストができる ○ 依存するサービスでエラーが発生したときの確認 ➢ Abortedが返された時にリトライするか等 マイクロサービスのテスト

Slide 25

Slide 25 text

© KAUCHE, Inc. 振り返り

Slide 26

Slide 26 text

© KAUCHE, Inc. ● 仕様を確認する手間が減った ○ 仕様が明確化によるコミュニケーションコスト削減 ○ コードリーディング時間の削減 ● リリース時のQAが効率化 ○ 以前はQA環境に対して手動でAPIを叩いて確認していた ○ QA環境に対してE2Eテストを実行すればOK メリット

Slide 27

Slide 27 text

© KAUCHE, Inc. ● コードレビューの効率化 ○ 機能性の確認が楽になった ➢ protoの仕様通りにE2Eテストが実装されていたら、意図通りにコードが動くことが 確認できる ➢ 設計や可読性、一貫性といった部分のレビューに注力できる ● 外部品質と内部品質の向上 ○ 外部品質と内部品質の向上 ○ データベース移行もE2Eテストがあることで安心して進めることができている メリット

Slide 28

Slide 28 text

© KAUCHE, Inc. ● CIの高速化 ○ E2Eテストが増えてきてCIの実行時間が長くなっている ○ 並列化しにくい部分がある ➢ テストデータがバッティングする ➢ 並列化するとFirestore EmulatorがAbortedを返す 今後の課題

Slide 29

Slide 29 text

© KAUCHE, Inc. まとめ

Slide 30

Slide 30 text

© KAUCHE, Inc. ● API仕様ファースト開発により、開発プロセスの効率と品質が向上した ○ 仕様の明確化でコミュニケーションコストを削減 ○ テスト駆動により、内部品質と外部品質の向上 まとめ

Slide 31

Slide 31 text

© KAUCHE, Inc. 宣伝：積極採用中です！ カジュアル面談もやっています。 興味を持っていただけた方はぜひお気軽にご連絡ください。 We are hiring！ https://enjoy-working.kauche.com/

Slide 32

Slide 32 text

© KAUCHE, Inc. ご清聴ありがとうございました