個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた - Qiita

結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。 このアーキテクチャでどんなものができるのよ、という視点で見ていただくと面白いかもしれません。 ↓ 背景 アーキテクチャに絶対の正解はない アーキテクチャには絶対の正解はありません。 なぜなら、プロダクトやフェーズによって求められる要件が異なり、それに適したア

[chiroruxx]

この理由でNoSQL採用すると後で死なない？NoSQLをRDBの代わりとして使わないほうがいいよ

[paradisemaker]

これ、スタートアップではものすごい技術的負債になるので、普通に RDS にしたほうがいいよ。 “初期のフェーズではDynamoDBで作って無理が出てきたらRDSとの併用を考える”

[mizchi]

個人的に今は next.js+firebase-auth+prisma+vercel だと思ってるんだけどDBどこのクラウドに置くかが決まらなくてまだ結論が出せない

[noseld]

NoSQL使いたいのは分かるけど、だからdynamo、そしてcognitoってのはAWSで完結させる前提ありきの構成に見えちゃう。firebaseやauth0などとフラットに比較してから最強を語って欲しい。

[oakbow]

どう見ても最強じゃない…。やたら無料圧が高いが月数千円くらいも払えないもんかね？少なくともバックエンドはherokuの方が保守コストかからず通常のRDB使えるし十分スケールするし、後からAWSに移行もできる。

[cocoiti]

個人的には結構すき、各コンポーネントは各自Saasで読み替えれば、スキーマレスなアーキテクチャ採用すると分析基盤つくりたくなったときにスキーマがほしくなるから個人的にはRDB選んどきたいかな・・・。

[beginnerchang]

みんな覚えておきな、こういう人が会社を潰すんだ。顧客の問題を解決しようとしないからね

[n_231]

dynamoDB(nosql)について一から学習するコストはrds常時動かすコストより高いと思うよ……

[door-s-dev]

Firebaseの話かと思ったら違った。自分がなんか作る時はHeroku使ってる。ノーコード系でいいのあったら知りたい

[fut573]

スケール前のスタートアップならこの辺のクラウドコストは人件費に比べて誤差程度では？ ビジネス要求に合わせて選定したほうが幸せになれそう。

[hokahokabob]

スタートアップの構成 dynamoの資料リンクあり、きゃつちあっぷ

[minamishinji]

興味深いけど、僕には難しそうだ…

[strawberryhunter]

スタートアップではなくて個人開発だけの話だと思う。それも貧乏あるいは多産な人向け。

[nabinno]

ServerlessFrameworkもAmplifyもAltCFnなのでどっちでもいい派。後々のことを考えるなら最初からAWS CDKで組むかなあ。

[ya--mada]

何を作るか分からないのにアーキテクチャだけ出されても…

[d4-1977]

サーバーレスを上手く活用できるようになりたい。データベースは悩ましい…

[nilab]

「ServerlessFrameworkを使い倒す」「フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます」「データベースはRDSは使わずにDynamoDBで」「APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ」

[diveintounlimit]

ぼくのかんがえたさいきょうのなんたら。個人開発なんで好きにしたら良いけどまったく最強じゃないな

[shag]

そもそもスタートアップが成功するかどうかに採用技術のアーキテクチャは大して寄与しないのでは？後で困るデータストアだけは別だけど。

[akahigeg]

叩いていい流れと思って過剰に叩いてる人がおるなあ。まあ確かに個人ならともかくスタートアップで費用節約のために脳死でDynamoDBはないと思うが。

[j5ik2o]

気持ちはわかるが無理ある。GSIの個数に限界あるしRDBと同じことできない。一般に要件の9割はRDBのクエリ。DynamoDBはスケールアウト可能な書き込みに特化したDBだよね。最強というならCQRSだよ

[appru]

よくある構成なのに、みんな、そんなに目鯨立てなくても… https://aws.amazon.com/lambda/resources/refarch/refarch-webapp/ あと、こんなやつが会社潰すとか誹謗中傷すぎない？マサカリと人格攻撃は違うぞ。

[taguch1]

成長してる時にrdsの変更コストが払えなくて地獄行きなプロダクトを何度繰り返せばいい？

[hokupod]

amplify でよいのでは

[taruhachi]

問答無用でDynamoDBっていってる記事に480LGTMも付いていることに危機感を覚えてブクマ。他は読んでない。

[masalib]

ブックマークのコメントが本編。認証はFirebaseの方が簡単だと思うだけど・・・

[aktkro]

toBサービスなら1ヶ月後に、toCサービスなら3ヶ月後に「RDBにしとけばよかった…」ってなるやつ

[yancy1969]

AWSをはじめ各種クラウドサービスはスタートアップ向けに無料クレジット付与してくれるので、それで解決す。

[inomaso]

アーキテクチャについて一家言持ってる人多いね

[lont_in]

スケール前ならまぁあり

[mr_mayama]

AWSに頼ってると…って思うところはあったんだけど、フルスタックで作れる脳みそがある前提でAPI GatewayとかLambdaとか触ってみると「万一AWS全体が死んでも設計やソースは活かせるな」って思える程には良く出来てる。

[chimerast]

"DynamoはNoSQLなのでスキーマが固定されず仕様の変更に柔軟に対応できます" ダウト！アプリケーションレイヤーをLambdaにしちゃうのもなあ。GraphQLは特殊なドメインにだけ刺さる技術で、容易に採用するべきものではないよ。

[convivial]

自分は割と同意な構成なんだけど、みんなDynamoDB嫌いなんだね。

[masatotoro]

appsyncを使わないで、LambdaでApolloですね。近いイメージ持ってます

[you1]

アカウント系はRDBで、mongoをコンテンツ系に使うと、結構柔軟にやりやすかった。サービスによるけど、ビズ側の要望には柔軟にできたりはする。

[sionsou]

NoSQL思想はわからんでもないけど（柔軟な変化に耐えたいとか）MongoDBで開始して結局RDS使ったワイが通りますよ。他はまぁ今どきの無難フレームワーク使っとけばどうとでも。あとHerokuやfirebaseオススメ

[hate_nao]

vercelってどんな制限があるんだろ

[onesplat]

お前らRDB好きすぎだろ。便利さは否定しないけどいい加減新しい技術学べよ。Dynamoは確かに辛いかもしれないけどありえないってほどの選択肢ではないしFirestoreでもいいじゃん

[biwakonbu]

課金ケチって3ヶ月後からトイチレベルの負債返済始まる地獄みたいなアーキテクチャしてる。

[kamocyc]

Dynamoは辛いっていう話しか聞かないけど実際どうなんだろう。