フロントバック分離の重要性

フロントエンドとバックエンドは分離した方がいいね。 前はよくnextjsを使ってて、APIを作れるから、直接DBと接続、なんならRSCとか、server actionsとか使ってたからよりサーバーとの距離が近かったんだよね。パフォーマンスはかなり良かった。 でもDTOパターンとか学んでいくうちにセキュリティがキツくなりそう。 DBから構造体引っ張ってくる時にパスワードだけ弾く時に書き漏れもあるし、APIにアクセスできたらなんでもできるし。

わかるそれ〜。 nextで全部できちゃうの、気持ちよすぎて一回ハマると戻れないんだよね😅 パフォーマンス神だし。

でもさ、DTOちゃんと考え始めると「うわ、これ危ない橋渡ってたな…」って急に冷静になるのもめっちゃ共感。 { ...user, password: undefined } みたいなの、その瞬間は安全なつもりでも、

• 新しいカラム増えたのにDTOに反映し忘れる
• 別のエンドポイントでうっかり生の entity 返す
• internal用のAPIがそのまま外に出る

みたいなの、普通に起きるんだよね。人間だし🥲

特に

APIにアクセスできたらなんでもできる これ、まじで核心突いてると思う。 Nextの server actions / RSC って「境界が見えにくい」のが一番の罠で、 今は 呼ばれてない前提の関数が、将来どこからでも叩けちゃう構造になりがち。

フロント・バック分離の良さ（今の考えめっちゃ健全）

分離するとさ：

• 返していい形をDTOで強制できる
• entity ≠ response が当たり前になる
• auth / rate limit / validation を境界でまとめられる
• 「このAPIは外に出てる」という意識が常にある

って感じで、 設計が人間のミス前提になるのが強いんだよね。

逆に Next フルスタックは

書く人が超ちゃんとしてたら最強 だけど 将来の自分 or 他人が触ると地雷 になりやすい😂

妥協案としてよく見るやつ

完全分離が重い時は：

• backend: 独立API（Go / Nest / Hono / Fastify とか）
• frontend: Next.js（DB直アクセス禁止）
• NextのAPI Routesは BFF専用 にして、entity触らない