プラットフォーム部（旧開発事業部）の dascarlet です。今回は Next.js と NestJS を利用し、 kikagaku.ai の管理アプリを立ち上げた話をします。ここで言う管理アプリとは、弊社の社員・講師がお客さまのデータを閲覧したり、必要な操作を行えるアプリケーションのことを指します。
立ち上げの背景
kikagaku.ai の管理アプリが必要となった背景としては、2つあります。
1. 必須オペレーションの増加
事業の拡大と共に必要になるオペレーションが増え、社内の従来の仕組みでは対応できないケースが少しずつ出てきました。
2. 将来への投資
プロダクト自体が大きすぎないうちに管理アプリを立ち上げておき、会社の成長と共に少しずつ開発していきたいという思いが入っています。
選定した技術
まずは選定した各フレームワーク等を紹介し、次に理由についてお話します。
フロントエンドアプリ フレームワーク：Next.js
CSS フレームワーク：Chakra UI
これらの採用理由は単純でした。 kikagaku.ai で既に採用されており、社内の他のメンバーが管理アプリを開発する際に技術的なキャッチアップが容易だと考えたからです。弊社はまだまだ小さい会社で開発リソースも限られているので、特に異論なく採用が決まりました。
管理アプリにデザインのこだわりはあまり必要ないと考えたので、Chakra UI で楽ができるところは楽をしています。
サーバーサイドアプリ フレームワーク：NestJS
社内では初の採用となります。弊社 CTO の祖父江と「サーバーサイドを開発するときになったら NestJS を採用したいよね」という話を以前からしており、採用に至りました。
個人的には Express をベースにしている点や、TypeScript をフルサポートしている点も良い印象でした。さらにModule の概念が Firestore の collection の概念と上手くマッチしそうな印象も持ったので採用しました。
また今後管理アプリが大きくなっていった時、他サービスとの API 連携なども発生しうることも考慮しました。サーバーサイドの採用はこのタイミングがベストだという結論に至りました。
Firestoreとの接続には Firebase Admin SDK を利用しています。Admin SDK は Cloud Firestore のセキュリティルールを無視するので、管理アプリとしての機能開発に集中することが出来ます。
Monorepo 構成：Yarn Workspaces
サーバーサイド・フロントエンド共に TypeScript での開発になるので、Type を共有したいと考えました。リポジトリの root に types というディレクトリを用意し、どちら側でも同一の型を参照できるようにしています。
フロントエンドアプリ デプロイ先：App Engine
サーバーサイドアプリ デプロイ先：Cloud Run
デプロイ：Cloud Build
認証：Identity-Aware Proxy
App Engine については、以前からの知見を元に採用しています。Cloud Run については Node.js アプリのデプロイ先としては初めての挑戦になりますが、問題なく安定稼働しています。
Identity-Aware Proxy への対応については後日詳細な記事を作成しようと思っています。
選定しなかった技術
React Admin
主に2つ理由があります。
1. 学習コストが高い
React Admin を選定すると Material-UI にロックされるという点が気になりました。これは事業部内で2つのCSSフレームワークを扱うようになるという点で、学習コストが高いと判断しました。
2. 自由度が下がる
フレームワーク自体にアプリケーションがロックされてしまい、自由度が下がることが懸念点でした。
弊社は創業当初 to B の事業のみ扱っていましたが、コロナ禍を経て to C 向けの事業も扱うようになりました。管理アプリに求められる機能も時間の経過と共に変化していくと考え、自由度をある程度担保できるよう Nest.js, NestJS のみの採用としました。
GraphQL
初めはサーバーサイドとフロントエンドの API 連携の部分に採用しようと考えていました。しかし社内のメンバーの大半がサーバーサイドアプリ開発の経験がなく、NestJS のキャッチアップがまず最初のステップだと考えました。
管理アプリ立ち上げ完了後に NestJS の勉強会を開催しました。幸いにも Pull-Request 作成も増えてきており、社内でサーバーサイドへの知見もたまり始めてきていると感じます。
導入は見送ったものの、管理アプリや別のアプリケーションへ導入したり挑戦する可能性は高いかなと思っています。
まとめ
比較的新し目の技術選定にしつつ、現状の事業部の状態や各個人のスキルも考慮しての立ち上げになりました。ベースを作り切っても、その後誰も追加開発や保守が出来なければ会社の成長を支えるアプリにはなれません。その点を天秤にかけ考え抜いたつもりです。
