Next.jsを使う場合のDBについて
自分でバックエンドを書くか、BaaSを使うか
Rails APIモードを使うよりも、FirebaseやSupabaseやPlanetScaleのほうが連携が簡単そうな予感がしています。
Rails APIモードを使う場合、Fly.ioなどを使ってサーバーを立てる必要があり、なおかつそのDBの使用量を考慮に入れる必要があります。
Fly.ioはデータが少なければDB代が全く掛かりません。しかしそれはBaaS（Backend as a Service） も同様です。SupabaseやPlanetScaleも、Hobby用としては全くお金が掛からず、さらにNext.jsと連携がしやすいため、認証・認可周りについてもあまり悩まずに実装できそうな気がしています。
Rails APIを使う場合の具体的なプラクティス
バックエンドにRailsを使う場合は、CORS設定をすればNext.js側から簡単にRails APIを叩いてJSONを返してもらえるようになります。
しかし問題はここからで、Rails APIを使う場合には、ログイン後の事を考えて認証・認可周りを構築する必要があります。具体的にはAuth0やFirebase AuthenticationやCognitoなどを使って、なおかつそれらの公式ドキュメントを参考にJWTの設定をする必要もあります。これはとても大変そうです。
正直、このあたりに関してはよく分かっていない部分も多いです。OAuth2.0を使うと、このあたりの設定はかなり簡単にできるらしいです（JWTを使わずに済む？）。
OAuth2.0の認証・認可をRails側で行いたい場合には、omniauth-google-oauth2を使って、Next.js側で行いたい場合にはNextAuth.jsを使うのが良さそうです。
タマキさんのブログ記事がとても分かりやすいのでオススメです！
OAuth 2.0を使ってGoogle APIにアクセスする - Roll With IT
ちなみにこの記事を書くために調べている途中で知ったのですが、JWTとOAuthはそれぞれ片方だけ使うことも、両方とも組み合わせて使うことも、どちらも可能だそうです。
OAuth vs JWT (JSON Web Tokens): An In-Depth Comparison
- OAuthだけ
- JWTだけ
- OAuth×JWTを両方使う
両方とも組み合わせると、セキュリティ面では一番安全らしいです。ただ、個人サービスにおいては、OAuthだけにしておくのが一番簡単で無難だと思います。
サーバーレス（BaaS）の使用の容易さ
更に簡単にDBを使う方法があります。それはサーバーレスにしてしまうことです。
もしサーバーレスにすれば（BaaSを使えば）、バックエンドの設定に悩まされることなく簡単にDBを使うことができるはずです。Rails APIを使うメリットは、複雑なビジネスロジックを用いる場合とか、元々Railsを使っていたアプリのフロントエンド部分を引き離すとか、そういう場合に使うと想定されます。
つまり、極端な話DBがJSONを返してくれれば、バックエンドについては何とでもなります。個人規模のサービスでは、Next.jsにDBを組み合わせたいなら、むしろRailsを使わないほうが開発速度は上がりそうです。逆に、Railsを使うのであればフロントはHotwireにしてしまうのが一番開発速度が速いと思います。
個人で開発するぶんには、バックエンドを重視したい場合はRails×Hotwire、フロントエンドを重視したい場合はNext.js×Supabaseあたりの選択が良さそうな予感がしています（PostgreSQL派なので）。
とはいえ、Next.js＋Rails APIでアプリを作成すると、中規模以上のプロジェクトに近い形でコードが書ける＆APIサーバー周りの知識が高まるので、もし就活する場合にはアピールポイントの１つになると思います。
※ふわっとした理解なので、間違いがあれば遠慮なくご指摘ください！
おまけ
以前FBC内の分報に書いたのですが、『引用箱 QuoteList』の次なる自作サービスとして、Discordのログをまとめて自動的にブログ記事を生成してくれるサービス『Discord Log（ディスコードログ）』の開発をしようと考えています。
フロントエンドはNext.jsにしようと思っているのですが、それ以外の技術選定がまだ終わっていません。
もし、オススメのサービスやライブラリがありましたら教えて頂けると嬉しいです👀
追記（2023-06-25）
『DiscordLog』を作る場合には、Discord Botを作る必要があります。そして、作ったDiscord Botを動かすためにはホスティングサービスが必要で、サーバーがあったほうが便利です。
そのため、Next.js＆Supabaseのようなサーバーレスのアーキテクチャは、『DiscordLog』を作るのに適していません（結局node.jsをどこかのサーバーで動かす必要があるため）。
例えば、RailsやDjangoのようなフルスタックフレームワークを使って、その中でdiscordrbやdiscord.pyのようなラッパーを使ってあげたほうが、遥かに作りやすい気がします。
- shardlab/discordrb: Discord API for Ruby
- Rapptz/discord.py: An API wrapper for Discord written in Python.
このまま突き進むと「Next.jsとSupabaseとPrismaの学習をしたい！」という当初の目的が達成できなくなってしまうため、『DiscordLog』ではなく、別のWebサービスを作りたいと思います。
（もちろん、フロントをNext.js、バックエンドをRailsにすればそこそこ簡単に作ることは可能ですが、その場合はNext.jsではなくHotwireだけで充分そうな気がしました）
そのため、この『DiscordLog』のアイデアについては他の方にお譲りしたいと思います！ 作ってみたい方は、ぜひご自由に作ってみてください！✨
少しだけDiscord Botについて補足
技術検証前はDiscord APIを叩く必要があると思っていたのですが、前述のdiscordrbやdiscord.py、それからdiscord.jsなどのREADME、あるいはDiscordの公式ドキュメントを読んだ感じだと、ENVファイルの設定がされたbotがあればチャンネルに投稿されたテキストの取得は実現可能で、外部APIを叩くわけではなさそうな気がしました。
また、Webhookという簡単にDiscordと連携できる機能もあるのですが、これは投稿オンリーで、読み取りに関してはできなさそうです。めちょっく。
