nohというエンジニア向けQ&Aサイトを公開しました
nohというエンジニア向けQ&Aサイトを公開しました。
「AIに質問する」ボタンから質問を投稿するとGithubのIssueのような形で投稿され、AIが自動的に回答してくれます。もちろん、他のユーザーもコメントできるので既存Q&Aサイトのようにユーザー間で解決することも可能です。
投稿した質問含むコメントはインターネット海に公開されて誰かの手助けになるかもしれません。
サービス名に思い入れはそこまでなくてパッと決めたのですが、nohは日本語の能
から来ています。生成AIを積極的に活用するサービスにしていこうと思っていて、脳
にもかけています。能面をシンプルにしたようなロゴを考えているのですが、能力不足でできません。
技術
DBはFirestoreを使っています。
Firestoreを薄くラップするGraphQLサーバーをGraphQL Yogaを使って立てています。後で話しますが、GraphQLでラップしたことは失敗だと思っていてやめる方針です。
フロントエンドはNext.jsでSSRしていて、特筆することはない構成です。
良かったこと
実は今回初めてFirestoreを使ったのですが、本プロダクトにおいては採用してよかったと思います。RailsなどでAPIを作るよりもかなり工数減った気がします。
個人開発において最大のリスクは完成しないことです。開発に充てられる人材は多くの場合自分一人で、使える時間は仕事が終わった後と休日しかないので、開発コストを下げる優先度は高いなと感じます。noh以外にもプロダクトを作っていますが、完成しないまま4年を迎えつつあります(放置してる)。
とはいえFirestore(というかNoSQL)特有の制限もたくさんあるので、機能が増えてくると将来的にRailsなどへ移行したくなってくると感じます。要件次第ですね。現時点では、そのあたりの制限は目をつむって開発効率を取ることにしました。
また、今回Firestoreを採用した最大の理由は料金です。
Firestoreは読み込みと書き込みごとにお金がかかる従量課金です。サービスが大きくなって読み書き回数が増えてくると料金が高くなってしまいますが、CDNなどにキャッシュすることで緩和できます。サービス初期はほとんどお金がかからないのは非常にありがたいです。
これがRender.comでPostgreSQLを立てると月1000円くらいかかりますし、GCPのCloudSQL使うともっと高い。Staging環境作ると倍かかります。
悪かったこと
いろいろと思惑がありGraphQLでFirestoreをラップしたのですが、これは失敗でした。
思惑としてはRedisにキャッシュさせて即時パージできるようにしようと考えていたのですが、過剰な機能な上、Firestoreのメリットである利便性を失ってしまいました。今後は直接FirestoreSDKでデータを取得しつつ、アクセスが増えたらFirebase Functionsを使ってCDNにキャッシュしようと思います。
GraphQLでラップしたときにFirebase Admin SDKを使ってFirestoreのデータをやり取りしていたのですが、セキュリティルールを無視して動いてしまうので整合性を合わせる難易度を跳ね上げてしまいました。
まとめ
現状ChatGPT3.5 turboを使ってますが、予算に余裕ができればより高性能なモデルにしていきたいです。
まだまだ機能不足なので気長に育てていこうと思います。
お楽しみに✨
Discussion