Would you define a form's validation rules once and share them with the server, or keep two sets, and what does each choice cost?

Every form of any size faces this question once: are the rules written twice - once for the interface, once for the service - or written once and read by both? It is a judgment call with real tradeoffs, which is why it comes up in design discussions rather than in code review. ## Why the duplicate set rots Two independent rule sets are two places to change and one of them will be missed. The two failure directions are asymmetric but both bad: - **The client is stricter than the server.** Users are blocked from submitting values the service would happily accept. Nobody files a bug, because the form looks like it is working; the business simply loses the submissions. - **The client is laxer than the server.** The form says the value is fine and the service refuses it. If the form cannot present that refusal well, the user is stuck at a green field with a failing submit - the worst experience in this whole area. Drift also hurts the messages: the same rule worded differently in two places means the user sees one phrasing while typing and another after submitting. ## What a shared definition buys, and what it costs | Approach | Buys | Costs | |---|---|---| | One declarative definition, consumed by both | No drift for shared rules; one place to change; consistent messages | Coupling between interface and service releases; a lowest-common-denominator rule language; version skew across deployed clients | | Two hand-written sets | Each side free to use its own idioms and add its own rules | Drift on the first unmatched change; duplicated wording; silent over-strictness | | Server-described rules fetched at run time | Always current; no client redeploy for a rule change | A round trip before the form can judge; a rule language to interpret; behaviour before the description arrives | The shared definition has to be *data*, not code, to travel: a declarative description of constraints, from which each side builds its checks. The moment a rule needs arbitrary logic it stops being portable, which is the natural boundary of what should be shared at all. ## What is not shareable Three categories stay server-side by nature: 1. **Rules over state the client cannot see** - uniqueness across all records, quota and balance checks, anything involving other users' data. 2. **Rules that depend on who is asking** - a field one role may set and another may not. 3. **Rules about concurrency** - the value was free when checked and is taken now. Even a perfectly shared rule set cannot make a client-side verdict current. And one category stays client-side: the *timing and presentation* policy - when a rule runs, when its verdict may show, how the message reads in the user's language. A shared schema describes constraints, not the moment a user should be told about them. ## Version skew is the interesting part Once the definition ships inside the client, deployed clients carry copies of it at different ages. Consequences a lead has to plan for: - The service must remain the authority, and must keep returning machine-readable per-field verdicts, because some client will always be judging by an older rule set. - Loosening a rule is safe to deploy service-first; tightening it will be enforced before older clients warn about it, so those users meet a rejection with no client-side preview. That is acceptable if the rejection is presented well, and it usually motivates shipping the schema change to clients first. - Fetching the definition at run time removes skew but adds a dependency the form needs before it can validate, plus a rule interpreter, plus a decision about what to do when the fetch fails. ## The rule that does not change Whatever is shared, the service validates the payload it receives. That is not redundancy to be optimised away - the client is a participant, not a gatekeeper, and a request can arrive without ever having passed through the form. The timing consequence for the form is concrete: treat every local verdict as provisional, keep the submission path capable of receiving a per-field rejection for a field the client cleared, and never let the presence of client rules become a reason to weaken the service's own. ## A practical default For one product with one team shipping both sides, share a declarative definition for the mechanical constraints, keep the server-only rules where they belong, and treat the client copy as an accelerator for the user rather than as the verdict. For a public service with independently released clients, publish the constraint description as part of the interface contract and version it, so the drift you cannot prevent at least becomes visible.