よく言われるやつ “フロントエンドとサーバーでのバリデーション責務分解”
フロントのバリデーションなんて簡単に突破されるから、サーバー側のチェックは絶対必須だよなｗ
サーバーサイド内でもバリデーションはレイヤーで分けるよね。ユーザー入力の検証とビジネスロジックの不変条件担保等。フロントも含めてそれぞれのレイヤーでやるべきことをやるだけではある。
なぜみんな、フロント側がバグってた可能性を考えないんだろう
バックエンドでチェックするのでフロントエンドは補助というのが古典的回答だが、コードを共通化しようとするとチェックにAPIを使うなどを考えたくなるよね。
フロントのバリデーションはUI/UXのために実装すべきで、バックのバリデーションはセキュリティのために実装すべき
vmwareのアカウントがbroadcomに移行したんだけど、日本語が文字化けしてるしフォームがdisabledなので変更もできなくて詰んだ。なのでdisabled消して進めたよ。元tweetも単純にフロントか仕様のバグじゃない？
すごく当たり前のことを、当たり前のように書いているだけではあるけど、簡潔によくまとまっていると思う。
前の人がやってるからヨシ！ではなくて自分の身は自分で守ろうという話。アクセス経路が限定されてるからDBの権限なんかフルコントロールでええやろとならんのと同じ。
バックはデータの整合性のために、フロントはUX向上のために、という観点で両方で好きなバリデーションやればいいと思う
複雑なバリデーションルールになる時や業務要件で変わる時にフロントとバックエンドで二重に持ちたくない時はある。新ルールのパスワードでは昔作ったパスワードと違ってフロントで弾かれると入力できなくなるとか。
フロントエンドはUXなので、バックエンドでセキュリティとデータ整合性を確保すべき定期。WordPressみたいなPHP案件だと、DB経験ないフロントエンド技術者がうっかり実装しちゃうことも多いので注意
https://participacionciudadana.minvu.gob.cl/sites/default/files/webform/anytime-trading.pdf
alway valid-domain modelの思想に従えばいいのである
確かにバリデーションの目的が違うから、実装の共通化もしなくて良いと思った。 なぜ共通化したくなっちゃうんだろう？
バックエンドで全てが完結したうえで、バリデーションデータなどはAPIで送ってくるのが理想。フロントエンドは余計なことをせず、ユーザーに負担をかけずに入力データを素直にバックエンドに送るのが責務
責任分界じゃなくて分解なのね。まあ間違いとも言えないけど。
結局、フロントエンドのバリデーションはあくまでもユーザーインターフェースの為のものなので、普通にやってもバックエンドでエラーになるものをフロントエンド側で頑張ると逆に良くない結果になるという。
フロントエンドとサーバーでのバリデーション責務分解
よく言われるやつ “フロントエンドとサーバーでのバリデーション責務分解”
フロントのバリデーションなんて簡単に突破されるから、サーバー側のチェックは絶対必須だよなｗ
サーバーサイド内でもバリデーションはレイヤーで分けるよね。ユーザー入力の検証とビジネスロジックの不変条件担保等。フロントも含めてそれぞれのレイヤーでやるべきことをやるだけではある。
なぜみんな、フロント側がバグってた可能性を考えないんだろう
バックエンドでチェックするのでフロントエンドは補助というのが古典的回答だが、コードを共通化しようとするとチェックにAPIを使うなどを考えたくなるよね。
フロントのバリデーションはUI/UXのために実装すべきで、バックのバリデーションはセキュリティのために実装すべき
vmwareのアカウントがbroadcomに移行したんだけど、日本語が文字化けしてるしフォームがdisabledなので変更もできなくて詰んだ。なのでdisabled消して進めたよ。元tweetも単純にフロントか仕様のバグじゃない？
すごく当たり前のことを、当たり前のように書いているだけではあるけど、簡潔によくまとまっていると思う。
前の人がやってるからヨシ！ではなくて自分の身は自分で守ろうという話。アクセス経路が限定されてるからDBの権限なんかフルコントロールでええやろとならんのと同じ。
バックはデータの整合性のために、フロントはUX向上のために、という観点で両方で好きなバリデーションやればいいと思う
複雑なバリデーションルールになる時や業務要件で変わる時にフロントとバックエンドで二重に持ちたくない時はある。新ルールのパスワードでは昔作ったパスワードと違ってフロントで弾かれると入力できなくなるとか。
フロントエンドはUXなので、バックエンドでセキュリティとデータ整合性を確保すべき定期。WordPressみたいなPHP案件だと、DB経験ないフロントエンド技術者がうっかり実装しちゃうことも多いので注意
https://participacionciudadana.minvu.gob.cl/sites/default/files/webform/anytime-trading.pdf
alway valid-domain modelの思想に従えばいいのである
確かにバリデーションの目的が違うから、実装の共通化もしなくて良いと思った。 なぜ共通化したくなっちゃうんだろう？
バックエンドで全てが完結したうえで、バリデーションデータなどはAPIで送ってくるのが理想。フロントエンドは余計なことをせず、ユーザーに負担をかけずに入力データを素直にバックエンドに送るのが責務
責任分界じゃなくて分解なのね。まあ間違いとも言えないけど。
結局、フロントエンドのバリデーションはあくまでもユーザーインターフェースの為のものなので、普通にやってもバックエンドでエラーになるものをフロントエンド側で頑張ると逆に良くない結果になるという。