Open6

如何にして金をかけずに個人開発でフルスタックウェブアプリを作るか・・・メモ

u-yasu-yas

前提

  • 将来スケールしたときにも対応できるwebアプリ
    • vpsでゴニョゴニョするのはなし
  • クラウドサービスは横断しても良い
    • cloudflare + AWS + GCP とかでも良い、terraformで管理できるとなお良い
  • EC2やGCEみたいな、インスタンスが立ち上がってる時間課金のようなものは使わない
    • lambdaやcloud functionなど、実行時間課金のサービスにすることで初期費用を抑えたい
  • できる限りRDBMSを使いたい
    • ここが一番悩ましいところ、DynamoDBやFirestoreで十分であればどうにでもできるけど、RDBMS系じゃないとつらい、となると一気に初期費用のコストが上がって構成の難易度が上がる・・・

※筆者はよく知ったかぶりで適当なことを言ってしまうので、もし間違ってることがあったら気軽にコメントで指摘してご教授してくれると嬉しいですm(_ _;)m

u-yasu-yas

使いたい言語・フレームワーク・サービス

フロントエンド -> Next.js

バックエンド -> NestJS or Golang(Echo)

  • 実行時間課金系じゃないと費用がかかるので、lambdaとかCloud Functionsで動くやつにしたい。
  • lambdaとかcloud functionsなんかだと、コールドスタートが発生して余計なことを考えないといけないので、できればJS系よりgolangとかで動かしたい。NestJSのほうが実装は楽そうだけどGoでやりそう
  • 上記が満たせればデプロイ先は正直どこでもいいかなと

認証系サービス -> Auth0 or Firebase Authentication or Cognito

  • よほどのことがない限りFirebase Authenticationかなと思った。無料枠が多い。Auth0は良さそうだけど値段が・・・Cognitoも良さそう
  • ただFirebase Authenticationの場合、2段階認証をやるにはIdentity Platformと連携しなくてはいけないし、2段階認証もsmsにしか対応してない。
    • GoogleとかTwitter認証だけに制限すれば余計な事考えなくてすむのでコスパよくいけそう?
    • Twitter認証はCognito対応してないからFirebase Authenticationになってしまう

データベース -> Firestore or DynamoDB or Postgres ※ここが一番の悩みどころ

初期費用のコスパと複雑ではないデータモデルの場合のFirestore、万能だが初期費用がかかるRDBMS

Firestore

  • メリット
    • すぐに使える
    • 初期段階なら費用のことは一切考えなくていいくらい安い
    • フロントエンドだけで完結するので、下手したらバックエンドが不要になり、開発スピードが相当上がる
    • 作りたいサービスのデータのモデルが複雑ではない or 頻繁なUpdateをしない or 複雑なクエリをつかわない。など、NoSQLの強みが活かせるのであれば相当良いかなと思う。
  • デメリット
    • クエリが貧弱すぎてつらい。
      • コレクショングループを使いだすともっと制限が増えてしんどい
      • elasticsearchとかalgoliaに検索をぶん投げるやりかたはあるが、結局そこで追加のコストが掛かるのでなんのためにFirestore選んだんだ・・・となる
    • スキーマ設計のベストプラクティスが確立されてない
    • Security Rulesが辛い
      • コレクションが少なければまだいいが、増えだすと相当つらい。一つのファイルにすべてのコレクションのバリデーションを書かないといけない。ドキュメントのプロパティ1つ1つにバリデーションを書こうとしたらかんたんに1000行超えちゃいそう。

DynamoDB

ちょっとしか使ったことがないからよくわからない・・・軽く調べた感じメリデメの大枠はFirestoreと同様な気がする

RDBMS

  • メリット

    • 昔から使われているので、設計のベストプラクティスがある程度存在するし、困ったことがあっても調べればとりあえずなんとかなる(気がする)
    • ORMと組み合わせれば型周りも自動生成してくれるし、
    • Hasuraと組み合わせればコンソールポチポチでバックエンドの実装コストを抑えられる
      • 最低限のビジネスロジックだけコードを書くですみそう
      • セルフホスティングすればそこまで費用かからない?cloud runとかなら実行時間だけですむから費用かからないと思ってるんだけどどうなんだろう・・・要調査
  • デメリット

    • 初期費用高い
      • AWSやGCPで立てようとすると起動時間課金なので、サービスをローンチしたら最低でも月3000円位(円安になってるのでもっとかかりそう)
        • リージョンを安いところにすればもうちょっと抑えられるけど、遅延が・・・
        • MySQLならplanetscaleが無料枠があって良さそうだなと思ったけれど、MySQLはhasuraだと対応していないから、apiは全部自分で書く必要ありそう
          • 個人で開発してると実装結構しんどそう・・・気合
u-yasu-yas

構成候補1 (aws寄り・rdbms)

  • Next.js
    • ホスティング-> Amplify Hosting
    • 認証 -> Amplify auth (cognito)
  • DB
    • postgres x fly.io
    • hasura をlambdaにdeploy(できるのか??)
  • API (hasura actions)
    • Amplify api (goで書く)
      ネックなのはAmplify Hostingの費用、無料枠がアカウント開設から12ヶ月後以降は無料枠がなく、最初から従量課金。0.01 USD/1 分で、Next.jsのデプロイに平均15分くらいかかる場合、1デプロイ0.15USDかかる。1ヶ月毎日2~3回デプロイした場合、3 x 31 x 0.15 = 13.95USD -> 2000円くらい?

構成候補2 (GCP寄り)

  • Next.js
    • ホスティング-> Cloudflare Workers
      ※GCPだとedge runtime活かせる構成できなさそう・・・?
      ※Vercelは最強だけど商用利用ならPROプランから始めないとだめだし初っ端から初期費用だけで2000以上かかりそう
    • 認証 -> Firebase Authentication
  • DB
    • postgres x fly.io
    • hasura をCloud Runにdeploy
  • API (hasura actions)
    • cloud run (goで書く)

2のほうが費用やすくなりそうな気がするので2かな・・・?

u-yasu-yas

候補3 (Cloudflareより)

フロントエンド

  • Sveltekit
    • ホスティング -> cloudflare pages

API

  • Golang(Echo)
    • ホスティング -> fly.io

DB

  • Litestream
    • ストレージにCloudflare R2

ストレージ(画像とか)

  • cloudflare r2

認証 firebase authentication

  • なぜGCSじゃなくてR2なの?
    • R2のほうが無料枠多い、安いから
  • なぜFirestoreじゃないの?
    • firestoreのクエリ制限がきつく、データモデルが相当単純じゃないと将来の運用がきつくなるのは確定だから
  • なぜCloud Functions使わないでFly.ioなの?
    • ColdStart考えるのがめんどくさいから、あとデフォルトでGrafanaがくっついてくれるので
  • なぜFirebaseHosting使わないでCloudflare Pagesなの?
    • CDNが制御しやすいから、あとEdge Worker無料で使えるから
u-yasu-yas

Firebase authenticationのかわりにSupertokensを使う

https://supertokens.com/pricing

5000mauまでfreeで使える。firebase authenticationはGCPやfirebaseにガッツリ依存しちゃうのが懸念だったのでこれでいいかも