1. よかったこと
- 自分のスキルと作りたいものと向き合って技術スタックを定められたこと
- わからないこと・詰まったことは考えたうえで、生成AIを用いたことで効率よく進められたこと
2. 反省点・課題
- 技術スタックを体系的に学べてない
- API設計
- エンドポイント設計
- リクエスト・レスポンスデータの型設計（スキーマ設計）
- SQLとDB設計
- 裏でSQLがどう動いているかの体系的な理解（構文）
- DB設計の知識
- エラー解決能力
- フロントとバックの接続に対する理解
- CORS
- 流れの理解だけでひとつひとつの技術についての理解が浅い
- 全体的に理解が浅いので技術の採択判断ができない
- フロントが最小限なので、拡張したときに管理が大変
⇒Reactへ移行?再設計の余地あり - 責務意識
3. 各技術スタックの利点
3.1. 構成・役割
- フロント：HTML+CSS+Javascript
- 画面表示とユーザー操作
- FastAPI
- フロントからのHTTPリクエストを受けて処理
- Pydantic（schema）
- APIリクエスト・レスポンス値の型定義と検証
- SQLAlchemy
- PythonコードとDBの橋渡し
- PostgreSQL
- 実際のデータを保存
- pytest
- APIとDBの動作確認の自動化
3.2. FastAPI
- CURD中心でREST API型のアプリをシンプルに書きやすい
- 機能が整ってる
- 設計を分けやすい
3.3. SQLAlchemy
- PythonのオブジェクトとしてDBを扱える
- 可読性
- pythonコード一貫性
- 保守性
- DBアクセスを処理しやすい
3.4. PostgreSQL
- 本格的なRDBMSを使える
- 将来的に機能を拡張するときに対応できる
- 接続設定・SQL連携・本番を意識したDB設計が可能
3.5. HTML+CSS+Javascript
- 学ぶ対象を増やしすぎない
- fetch基礎理解
3.6. pytest
- 自動化による効率化
- 失敗時の原因特定の効率化
- テスト用DBを用意することでDB操作込みでのテスト可能
4. 今後の展望
- スマホ対応化
- フロントをReact(Next.js)に進化
- 機能拡張
- フォルダ機能
- 検索・絞り込み・並び替え機能
- 締切を可視化（カレンダー表示）
- タスク管理から予定管理へ進化
- DB・API再設計(正規化、インデックス、制約、エンドポイント)
- 非同期処理