👨‍🎓

Pythonプロトタイプ完成とRust移行の決断 - Day 15

に公開
Rust
個人開発
ipc
Tauri
tech

はじめに

Day 14では、連載の一区切りと今後の開発目的について書きました。

今回はPythonプロトタイプの完成の報告とバックエンドをRustへ移行する決断とその経緯について書きます。

Pythonプロトタイプの完成

Day 13で報告したgoals機能のチケット制への全面改修が完了しました。これによりPythonプロトタイプとして当初計画していた機能が一通り揃いました。

実装済みの機能は以下の通りです。

機能 ファイル 内容
時間記録 times.py 開始・終了・合計時間の計測。月別CSV自動出力
チケット管理 goals.py 親→子→孫の3階層チケット。作成・ステータス更新・completion_flag自動算出
ファイル操作 file_operations.py OSパス自動判定・CSV/JSONL読み込み
APIハブ main.py FastAPIによるエンドポイント定義

Rust移行を決断した理由

このタイミングで本番機能の実装を開始することにした理由は3点あります。

1. 開発当初からの方針

本番用バックエンドにはRustを使用する想定で開発を進めていました。Pythonはあくまでもロジックとデータ構造を確認するためのプロトタイプという位置づけです。

2. NN機能実装前に移行するコストが最小

NN機能をPythonで実装した後にRustへ移行しようとすると、PyTorchからBurnへの変換作業が発生します。プロトタイプの規模が小さい現時点で移行することで、書き直しのコストを最小化できます。

3. 3D描画時のボトルネック回避

フロントのUI方針変更（後述）に伴い、3D描画を実装する場合に現在のスタックではAPI通信を行う部分でボトルネックが発生すると判明しました。

フロント要件とUX方針の変更

goals機能の実装を通じて、フロントの操作性について再検討を行いました。

当初はVS Codeをモデルにしたマウス操作中心のUIを想定していましたが、ゲームコントローラー的に限定されたキーの組み合わせで全操作を完結させる独自UIに変更します。

変更前 変更後
マウス操作中心 キーボードのみで全操作完結
静的なコンポーネント配置 ユーザー操作に応じて動的にUIが変化
Electron + TypeScript Tauri + Three.js + TypeScript

3Dゲームのようにユーザーの操作に応じて画面が動的に変化する設計を目指します。Three.jsによる3D描画はTypeScript側で完結させ、Rustバックエンドでは描画計算を行わない方針です。

新しい技術スタック

層 技術
デスクトップFW Tauri
バックエンド言語 Rust
フロント言語 HTML / CSS / TypeScript
3D描画 Three.js
NN機能 Burn（将来実装時）
データ形式 CSV / JSONL / MD

PythonプロトタイプはTauri標準のIPC（コマンド方式）で連携していたFastAPIとは設計思想が異なります。HTTPサーバーは不要になり、TauriのIPCコマンド方式でフロントとバックを繋ぐ設計になります。

プロトタイプから引き継ぐ設計判断

Rust版でもPythonプロトタイプで確定した以下の設計判断は引き継ぎます。

  • フロントとバックエンドの完全分離
  • バリデーションはフロント・バックの2重チェック
  • 機能別モジュール化
  • 状態保持が必要な機能は永続インスタンス、リクエスト単位で完結する機能はリクエストごとにインスタンス化
  • データ保存先はOSのユーザーデータ領域に自動保存

おわりに

今日はPythonプロトタイプの完成とRust移行の決断について書きました。

プロトタイプを作ったことでデータ構造・API設計・フロントとバックの責務分離の判断が確定しました。Rust版ではこれをベースに本番品質の実装を進めていきます。

次の記事はRust版の実装が進んだ段階で公開します。

リポジトリはOSS公開準備中です。公開後にこの記事へリンクを追加します。

この記事は連載「クラウドに依存しないマイルストーン管理ツール開発記」のDay 15です。

Discussion