発端
Xで、こういった投稿があった
フロントエンドで入力値チェックしてたらバックエンドでチェック不要でしょって話してるの聞いて、今そうなの？って思ちゃった
そういう現場が意外とあるらしい？？という現状らしい。それはもちろん間違っていると思うのだけど、きちんと説明できるようになりたかったので参加しました。
雑メモ
Always-Valid Domain Model · Enterprise Craftsmanship
バリデーションは「信頼できない情報」がはいってくる場所で行う。
「信頼できない」の線引
- Syntactic データ形式の検証
- Semantic データの意味の検証
Tierが異なる場所でも同様にバリデーションを実装しないと「信頼できない」を除去できない。
かつ、実装を共有すると「信頼できない」が貫通してくる可能性があるので、再利用性は考えないほうがいい？
Validが保証されたデータ -> 不変条件として保証されたデータ型を使えば、重複実装の必要がない
この考えに基づいて作られたバリデーションライブラリが存在する
colinhacks/zod: TypeScript-first schema validation with static type inference
Maybe
不変条件を型に落とし込む => モデリング
Validation と Verification
入力チェック文脈と品質保証文脈で意味が異なる
話題への回答
過激派
- データベースの制約でええやろ
良識派
- UXのためにFail Fastのためにバリデーション
- Tierをまたぐので、サーバーサイドでもバリデーション
まとめ
業務上Validなデータを定義しない限り、バリデーションの分類は曖昧になる。
(もうちょっと、まとめあったけど、自分の記憶に残ったのは↑)