イベントカレンダー「Unimory」の技術スタックと進化：個人開発の挑戦と成功

イベントカレンダー「Unimory」で使われている技術スタックとその変遷、そして個人開発の難しさに迫る！

2024年3月14日にVRChatの「個人開発集会」で行われた、つきみんさんによるイベントカレンダー「Unimory」の技術解説発表の内容をまとめました。Unimoryの開発で採用された技術スタックの変遷や、個人開発におけるデータベース選定の難しさ、将来的な展望について掘り下げます。

Unimoryとは？

Unimoryは、モダンなイベントカレンダーを目指して開発されたWebサービスです。開発のきっかけは、既存のイベントカレンダーサービスでは機能的に物足りなかったり、使い勝手が悪かったりするものが多かったため、ご自身が使いたいと思えるものを作りたいという思いから開発が始まりました。

Unimoryの特徴

Unimoryには、以下のような特徴があります。

• 繰り返しイベントに対応: 毎週○曜日や毎月末日などの定期的なイベント登録を簡単に設定できます。
• モダンでシンプルなUI: 洗練されたデザインとスムーズな操作性で快適に利用できます。
• Google OAuth認証: パスワードレスで安全かつ簡単にログインできます。
• 安価な運用コスト: 無料枠や低価格なサービスを積極的に活用することで、低コストでの運用を実現しています。
• 個人開発ならではの自由な発想: 開発者が本当に作りたいもの、実現したい機能を追求しています。

Unimory開発に使われた技術スタックの変遷

開発初期の2023年12月から現在（2024年3月）までの間、Unimoryでは様々な技術的挑戦と改善が行われてきました。ここでは、Unimoryの開発における技術スタックの変遷を時系列で追っていきます。

2023年12月：開発初期

• バックエンドフレームワーク：Deno
• データベース：Neon
• サーバーレスプラットフォーム：Cloudflare Pages & Cloudflare Workers

開発当初はDeno、Neon、Cloudflareといった技術を採用し、バックエンド側から開発が進められました。特に、Cloudflare Pages上で動くCloudflare Pages Functionsを活用することで、サーバーレスな環境での開発を実現しました。

2024年1月：認証機能の導入とRemixへの移行

• 認証：Lucia Auth（Google OAuth 2.0対応）
• サーバーレスデータベース：Upstash
• バックエンドフレームワーク：Remix

1月には、認証機能としてGoogle OAuth 2.0に対応したLucia Authを導入しました。また、セッション管理にUpstashを採用し、バックエンドフレームワークをDenoからRemixに移行しました。Remixは、Denoで開発されたフルスタックフレームワークであり、Unimoryのフロントエンドとバックエンドを統合的に開発できる環境を提供しました。

2024年2月：PlanetScaleの導入とCloudflare KVによるセッション管理

• データベース：PlanetScale
• セッション管理：Cloudflare KV

2月には、データベースをNeonからPlanetScaleに移行し、そのブランチ機能を活用することで、より安全な開発ワークフローを実現しました。また、セッション管理にCloudflare KVを採用し、Cloudflareエコシステムとの親和性を高めました。

2024年3月：ハッカソンでの挑戦と新たな課題

• 画像変換：Azure Functions
• オブジェクトストレージ：Cloudflare R2
• エラーロギング：Sentry

3月には、ハッカソンへの参加を機に、画像変換機能をAzure Functionsで実装し、変換後の画像をCloudflare R2に保存する仕組みを構築しました。さらに、エラーロギングツールとしてSentryを採用し、サービスの安定稼働に向けての取り組みを行いました。

個人開発におけるデータベース選定の難しさ：PlanetScaleの無料枠廃止

つきみんさんは、PlanetScaleの無料枠廃止という事態に直面し、個人開発におけるデータベース選定の難しさを痛感することに。

• 安定性: 無料枠では十分なSLAが保証されない場合があり、サービスの安定稼働に不安が残ります。
• 将来性: サービスの成長に伴い、無料枠では対応できないデータ容量や機能が必要になる可能性があります。
• 費用対効果: 個人開発では予算が限られているため、コストパフォーマンスの高いデータベースを選択する必要があります。

これらの問題点を踏まえ、つきみんさんは代替案としてSupabaseやTiDBなどのデータベースを検討し、最終的にSupabaseを採用することになりました。

Unimoryの将来と展望

つきみんさんは、Unimoryのさらなる発展に向けて、以下のような構想を持っています。

• フロントエンドとバックエンドの分離：REST APIを介した疎結合なアーキテクチャへの移行
• Deno Deployの採用：よりセキュアで信頼性の高いサーバーレス環境への移行
• 新しい認証ライブラリの検討：Auth.jsなどの導入
• ロギングシステムの強化：詳細なログ収集による問題解決の迅速化
• コミュニティの形成：Unimoryユーザー同士の交流を促進

まとめ：Unimoryの進化は続く

Unimoryは、個人開発の自由な発想と技術的な挑戦によって、着実に進化を続けています。今後も、ユーザーにとってより便利で使いやすいイベントカレンダーを目指し、開発が進められていくことでしょう。