個人開発で技術を選ぶとき、仕事とは違う基準で考えることが多いです。
仕事では、チームのスキルセットや保守性、採用市場まで考慮しますが、 個人開発では、そういった制約が無く自由に選べます。その自由さが面白くもあり、難しくもあります。
全体の構成
シンプル配当管理アプリは、モバイルアプリ・Webサイト・バックエンドの3つで構成しています。 モノレポで管理していて、それぞれ独立したモジュールになっています。
- モバイル: React Native + Expo
- Web: Astro
- バックエンド: Firebase（Firestore + Cloud Functions）
- 言語: すべてTypeScript
TypeScriptで統一したのは、コンテキストスイッチを減らすためです。 フロントもバックも同じ言語で書けると、一人で開発するときの認知負荷がかなり下がります。
React Native + Expoを選んだ理由
iOS・Androidの両方に出したかったので、クロスプラットフォームは必須でした。 Flutterも候補にありましたが、Webの経験がそのまま活きるReact Nativeを選びました。
Expoの恩恵がとても大きいです。ネイティブのビルド設定に時間を取られず、すぐにアプリのロジックに集中できます。EASでビルドとデプロイも一本化できるので、個人開発には特にありがたいです。
Firebaseという選択
認証、データベース、サーバーレス関数がワンストップで揃うFirebaseは、個人開発との相性がいいと思っています。
Firestoreのセキュリティルールで、ユーザーごとのデータアクセスを制御し、Cloud Functionsでは、株価の定期更新やSendGridを使ったメール通知を動かしています。
株価データはyahoo-finance2から取得していて、ユーザーが手動で更新する手間を省きました。
初期段階のインフラの運用コストをほぼゼロに抑えられるのも、個人開発では重要なポイントだと思います。
状態管理はZustand
Reduxは個人開発には重すぎますし、Context APIだと、ネスト地獄に陥りやすく可読性の低下やパフォーマンスの低下を招きやすいです。
Context APIのネスト地獄
<AuthProvider>
<ThemeProvider>
<PortfolioProvider>
<DividendProvider>
<SettingsProvider>
<App />
</SettingsProvider>
</DividendProvider>
</PortfolioProvider>
</ThemeProvider>
</AuthProvider>管理する状態が増えるたびにProviderが増え、どこで何を管理しているのか追いづらくなります。
Zustandはその中間で、ボイラープレートが少なく、必要十分な機能があります。
小さいアプリなら状態管理ライブラリすら不要かもしれませんが、配当の予測や履歴など扱うデータが多いアプリでは、導入してよかったです。
WebサイトはAstro
アプリの公式サイトはAstroで作りました。利用規約やプライバシーポリシー、使い方ガイドなど、静的なコンテンツが中心なので、Astroの軽さがちょうどいいです。
このポートフォリオサイトもAstroで作っています。ビルドが速く、出力がクリーンで、余計なJavaScriptを送りません。小規模な静的サイトには最適だなと感じています。
依存を少なくする
Sentryでエラートラッキングを入れたり、Lucideアイコンを使ったりと、案件で実際に使用するものや、気になっていたライブラリを実験的に使用したりしています。
ライブラリを追加するのは簡単ですが、それぞれがアップデートされ、壊れやすく、時が経てば非推奨になったり、メンテナンス性を考慮すると依存が少ないほど楽かなと思ったりします。
正解はない
結局のところ、技術選定に正解はありません。自分のプロジェクトの規模や目的に合っていて、自分が続けられるなら、それが正解だと思います。
流行りに乗る必要もないですし、誰かのベストプラクティスに従う必要もありません。個人開発なのだから、自分のペースで、自分に合うものを選べばいいと思っています。