たった8週間で作るPythonバックエンド | HACARUS Tech Blog

たった8週間で作るPythonバックエンド | HACARUS Tech Blog

ようやく先週、弊社の モバイルアプリ が Apple の審査を通過しました。この記事では、どのようにしてたった8週間でプロダクション品質のバックエンドAPIをアプリチームと連携しながら構築したかを解説したいと思います。

詳細に入る前に、まずは構築したバックエンドの概要図から。

見ての通り、弊社では AWS を IaaS として採用しています。AWS では様々なサービスが提供されていますが、その中でも特に開発時間の短縮に貢献したのは API Gateway でした。

当初は API Gateway とあわせて Lambda を使ってサーバレスなバックエンドにすることで、開発時間をさらに短縮できないかと試みましたが、それは適切でないとすぐに気付きました。一番の理由は Lambda の関数を書く際に、Raw SQLを扱わなければいけなかったことでした。何かしらの ORM を Lambda 内で使えるようにするための試みはデベロッパによって行われているものの、まだ時期尚早といった感じです。Lambda を使ってサーバレスなバックエンドをやる場合、最良の方法は RDS の代わりに DynamoDB を使うことだと思います。

API Gateway と Lambda に関する制約を評価した後に、自前の REST API を EC2 のウェブサーバ上で開発して、API Gateway を通じて公開するというやり方を決めました。API Gateway を使用していたため、クライアント側の API コードの生成はとても簡単でした。サーバ側の変更を即座にいつでもクライアント側に反映することができました。

API Gateway の中で特にお気に入りの機能は、クライント側のコードや実際のモバイルアプリを必要とせず、AWS Console 上で各 API をテストできることでした。さらに、ステージング環境を切り替える際にはステージ変数が有用でした。通常、クライアント側の設定ファイルを書き換えることになりますが、この場合は AWS Console 上で “Generate SDK” ボタンをクリックするだけで、別のステージング環境上に展開された API をアプリが指すようになります。下記は弊社におけるステージ変数とエンドポイントURLです。ポイントとしては、クライアント側の SDK が生成される際に ${stageVariables.url} が、それぞれのステージング環境で定義される値に置換されるところかと思います。

小ネタとして、ステージング環境はローカルのウェブサーバが稼働しているデスクトップPCを指すことができる点にも言及しておきたいと思います。弊社では ‘dev’ ステージを開発者のマシンを指すように設定することで、EC2 上にコードを展開せずに、実際のモバイルアプリを使いながら開発者が最新の API をテストできるようにしていました。クライアント側との整合性を保ちつつ、バックエンドの API を開発するには、このやり方が最も効率的だと分かりました。

API Gateway と生成されたクライアント側の API コード以外では、ユーザーのアイデンティティ管理とバックエンド資源へのセキュアなアクセス提供のために Cognito を使用しました。弊社が開発を開始した時点では User Pools がまだ無かったため、Developer Authenticated Identities を採用しました。おそらく、近い将来に User Pools に移行することになるかと思います。

上記のフレームワークを採用してからは、それぞれのイテレーションに必要な時間が劇的に短くなり、アプリチームは既存のコードを書き換えることなく、ほぼリアルタイムに最新の API を使えるようになりました。この結果、たった8週間でプロダクション品質のバックエンド API を開発することが可能になりました。


急成長中のスタートアップで開発の仕事に携わってみませんか?現在募集中の職種はこちらから。

ニュースレター購読Newsletter

登録はこちら