カウシェでのAPI仕様整備と効率的なバックエンド開発の実現
4月から再びカウシェで働いています。今回は個人事業主として業務委託の形で関わっています。本記事では、4月以降に担当している具体的な業務内容ではなく、バックエンドサービスのAPI仕様における技術的負債の解消についてお話しします。
2022年10月にカウシェへ転職
私はメルペイを退職し、2022年10月からカウシェでバックエンドサービスの開発を担当するソフトウェアエンジニアとして働き始めました。カウシェのバックエンドでは、メルペイと同様にgRPCを使用してAPIが定義されていました。しかし、それまでの2年間の開発を通じて、API仕様に関するいくつかの技術的負債が蓄積していました。
具体的には、以下のような課題が存在していました。
バックエンドサービスのAPI仕様がまったく記述されていない
APIをテストするための自動テストが存在しない
この状態では、私としては安心して開発を進めることができず、まずはこれらの課題の解消に取り組む必要があると感じました。
E2Eテストフレームワーク
最初に着手したのは、バックエンドサービスのAPIを直接テストするためのE2Eテストフレームワークの構築です。このフレームワークは、メルペイで私が構築していたものをベースに、カウシェのサービスに適合するようカスタマイズしました。下図はそのフレームワークの概要です(下図)。
図の細かな説明については引用元の書籍をご参照いただくとして、簡単に要点を説明します。このフレームワークの構造は以下のようになっています。
左側: テスト対象となるサービスのプロセス。
右側: go test コマンドで実行されるテストプロセス。
これにより、サービスとテストのやり取りが効率的に行える仕組みになっています。
API仕様の技術的負債の返済
私が最初に取り組んだ開発タスクは、新規ユーザー向けの「お知らせ」機能において、「初回お知らせ」を表示するAPI(エンドポイント)の改修でした。この改修を進める中で、以下の2つを実施しました。
API仕様を.protoファイルに記述
改修対象のエンドポイントの実装コードを確認し、仕様を .proto ファイルに明文化しました。E2Eテストの作成
.proto ファイルで定義したAPI仕様を元に、E2Eテストを構築しました。
実際の開発フロー
以下の図は、API改修の際に採用した開発フローを示したものです。このフローに従い、API仕様の記述からテストの構築までを効率的に進めることができました。
最初のAPI仕様整備とその進化
私が最初に担当した開発タスクで改修したエンドポイントは、カウシェで初めてAPI仕様が整備されたエンドポイントでした。ただし、この時点ではまだE2Eテストフレームワークが図1の構成にはなっていませんでした。この構成に至ったのは、2つ目に割り当てられたタスクを開発したタイミングです。
その後、さらに3つほどの開発タスクを完了し、E2Eテストのガイドを執筆したのが11月下旬でした。このガイドが開発チーム内で共有され、API仕様の技術的負債解消への取り組みが本格化していきます。
技術的負債の返済の合意
E2Eテスト環境が整備され、図2の順序でAPI仕様を返済するプロセスが進む中、バックエンドサービスの開発チーム全体で「今後もこのプロセスに基づきE2Eテストを整備していく」ことが合意されました。
2023年11月、私が退職する頃には、カウシェのAPI仕様の技術的負債はかなり返済されており、開発チームは少人数で効率的な開発が可能な状態になっていました。
カウシェ内の新規機能「カウシェファーム」
カウシェファーム用の新規バックエンドサービスでは、最初から技術的負債を抱えない開発プロセスが採用されています。具体的には、API仕様を .proto ファイルに記述し、それに基づくE2Eテストを同時に開発するサイクルが確立されています。この取り組みにより、技術的負債を未然に防ぐ仕組みが実現しています。
今後の展望
私が在籍した1年間で、カウシェのAPI仕様の技術的負債は大幅に解消されました。しかし、すべてのバックエンドサービスで返済が完了したわけではなく、今後もサービスの拡張を進めながら、技術的負債の解消が続けられる予定です。
今年4月から取り組んでいること
実は、私は今年4月からGoogle CloudのFirestoreからSpannerへのデータベース移行を一人で進めています。この移行作業は現在も続いており、完了次第、詳細について記事を書きたいと思っています。
参考書籍の紹介
ペルメイやカウシェでのバックエンドサービスのAPI開発の経験を基にした内容は、以下の書籍に詳しくまとめられています。ご興味のある方はぜひご覧ください。
書籍タイトル: 『Web API設計実践入門』