【マイレース開発記録(7)】Flask API設計
Yokoレースの裏側で何が起きているのか
前回までの記事では、
マイレースというアプリの発想や、
占星術ロジックの基本的な考え方について書いてきました。
今回は、いよいよ アプリの裏側 の話です。
画面では、うさぎが走るレースが表示されますが、
その結果はすべて サーバー側で計算 されています。
その中心にあるのが、Flaskで作った API です。
レース結果はサーバーで計算する
マイレースでは、ユーザーが次の情報を入力します。
- 生年月日
- 出生時間
- 出生地（都道府県）
- 占いたい日
これらの情報をもとに、
- 天体の位置
- それぞれのテーマのスピード
- うさぎの順位
- メッセージの種類
を計算します。
この処理を行うのが、FlaskのAPIです。
JavaScriptからは、次のような形でリクエストが送られます。
JavaScript
fetch("/api/calc",{
method:"POST",
headers:{ "Content-Type":"application/json" },
body:JSON.stringify({
birthday:b,
birth_time:tm,
prefecture:pr,
target:tg
})
})
ユーザーの入力データを JSONとしてサーバーに送信 し、
Python側で計算して結果を返します。
Flask側のAPI
Python側では、次のようなエンドポイントを作りました。
Python
@app.route("/api/calc", methods=["POST"])
def api_calc():
このAPIでは、
- 入力データを受け取る
- データの形式をチェックする
- 天体計算を行う
- レース結果を作る
- JSONとして返す
という流れになっています。
最終的には、次のようなデータをフロント側へ返します。
Python
return jsonify({
"phases": phases,
"speeds": speeds,
"finish_times": finish_times,
"rank_map": rank_map,
"messages": message_meta
})
フロント側のJavaScriptは、このデータを使って
- レースアニメーション
- 順位表示
- メッセージ表示
を描画します。
APIを分けた理由
最初は、
「全部JavaScriptで計算すればいいのでは？」
とも考えました。
しかし、途中で設計を変えました。
理由は大きく3つあります。
① 占星術計算はPythonの方が扱いやすい
天体計算には Swiss Ephemeris というライブラリを使っています。
これはPythonで扱う方が圧倒的に簡単です。
もしJavaScriptでやろうとすると、
- ライブラリの選定
- 計算精度
- 実装コスト
が大きくなってしまいます。
そこで、
計算はPython
表示はJavaScript
という役割分担にしました。
② ロジックをフロントに置きたくなかった
もう一つの理由は、設計の整理です。
もしロジックをJavaScriptに全部書くと、
- UI
- アニメーション
- 占星術ロジック
がすべて混ざってしまいます。
これは後から読むとかなり混乱します。
そこで、
計算はAPIにまとめる
という形にしました。
③ 将来の拡張を考えた
もう一つ理由があります。
それは 拡張性 です。
もしAPIで結果を返す形にしておけば、
将来的には
- スマホアプリ
- 別のフロントエンド
- データ分析
などにも使える可能性があります。
つまり、
レースロジックを
「サービス」として切り出した
というイメージです。
実はここからが大変だった
ここまで読むと、
「APIを作れば終わり」
のように見えるかもしれません。
しかし実際は、ここからが本当のスタートでした。
APIを作ったことで、
- 入力チェック
- データの整合性
- エラー処理
といった問題が一気に出てきました。
特に苦労したのが 入力データの検証（バリデーション） です。
AIとの開発で助かったこと
このAPI設計の段階で、
AIとの対話がかなり役に立ちました。
私は設計を考えるとき、
- ロジックを言語化する
- フローを説明する
- 仮説を立てる
という形でAIに話しかけます。
すると、
- 処理の順序
- 想定されるエラー
- 設計の矛盾
が整理されていきます。
AIがコードを書いたというよりも、
思考の整理を手伝ってもらった
という感覚に近いです。
発達特性の影響で、
複雑な処理を頭の中だけで整理するのが難しい場面もあります。
しかし、対話しながら設計を書き出していくことで、
ロジックの構造を一つずつ確認できました。
この開発スタイルは、
自分にとってかなり相性が良いと感じています。
次回予告
APIができたことで、
ようやくアプリの骨格が見えてきました。
しかし、ここで新しい問題が出てきます。
それが 入力データの検証 です。
- 出生地が未入力
- 日付の不整合
- 想定外の入力
こうしたケースをどう扱うかは、
思った以上に重要でした。
次の記事では、
として、
入力チェックの実装で苦労した話を書きます。
＼ 最新情報をチェック ／
