Client-side vs server-side validation when saving records

[seancolsen]

Question

When a user tries to write invalid data to a record, where should we perform the validation? On the client, or the server? Can we come up with a generalized approach that will help us determine when to validate on the client and when to validate on the server?

Considerations

Validation failure scenarios

• (a) NULL value for a NOT NULL column
• (b) value(s) in violation of a unique constraint
• (c) value that does not fit within the column's specified length
• (d) FK constraint violation
• (e) CHECK constraint violation
• ... (this list is not exhaustive)

Arguments for validating on the client

• Client-side validation provides a faster UX.
• At the DB level, Postgres will stop validation after it reaches the first error. This means we can't get info from the DB about multiple validation failures when trying to insert a new record.

Arguments for validating on the server

• Because server-side validation is still necessary in all cases, relying on it exclusively helps to reduce complexity and development time.

• In some situations, the client lacks the necessary data to perform the validation (e.g. unique and FK constraints).

• Some situations may have edge cases which create difficulty in making the client's results consistent with the server's results.

  For example, consider failure case (c) with a string containing the emoji 👩‍❤️‍👩 which has the code points \uD83D\uDC69\u200D\u2764\uFE0F\u200D\uD83D\uDC69.

  In Javascript, "\uD83D\uDC69\u200D\u2764\uFE0F\u200D\uD83D\uDC69".length gives 8.

  Whereas in Postgres, select length(E'\uD83D\uDC69\u200D\u2764\uFE0F\u200D\uD83D\uDC69'); gives 6.

  (Surely there's a way to get JS to match PG, but it's not as straightforward as it might seem.)

Prior discussions

• In Fix Not Null Violation to return detailed error response #1053, we seem to be converging on a decision to rely on client-side validation for (a).

[seancolsen]

I'd like to propose we use client-side validation for (a), and server-side validation for everything else.

[kgodey]

I think client-side validation wherever possible with server-side as a fallback makes sense, I'd propose doing it for:

• Situation (a)
• Situation (c) if the text involved is not too complicated (e.g. detect emoji and check length if there's no emoji)
• Data type validation (e.g. don't rely on the server to tell you that "hello world" is not a datetime type)

Reasoning: I think better UX trumps other arguments here, and I don't think that the development time/complexity reduction is significant (I assume it will be hours, not days).

New situations should be evaluated on a case-by-case basis, but this should provide a good guideline.

[seancolsen]

I want to push back on this a bit.

Continuing with the emoji example... I don't know exactly how Postgres comes up with a length of 6 in this case, but I doubt the discrepancy would be limited to emojis. It probably has to do with the zero-width joiner which is a code point used in some languages too. I raise the emoji example not just to highlight an edge case -- but rather to argue that edge cases like this probably exist that we're not even aware of. They're all solvable. But I wouldn't count on them all being simple. Unicode is simple most of the time. But the edge cases can be quite complex. Validating an email is simple most of the time. But it, too, can be complex when it comes to the edge cases.

Yes, client-side validation makes the UX a bit snappier. But Mathesar would still be totally usable without it. And I don't think it will necessarily take hours to get it right, especially for data type validation. I'd rather see us put that time into building features that affect wether or not someone can use Mathesar at all. We can always add more client side validation later on.

[kgodey]

Okay, I'm convinced on situation (c). I think it would be nice to open a draft issue to track investigating client side validation for it.

Perhaps the rule of thumb could be that if researching and implementing the validation takes only an hour or two, we should prioritize it now, otherwise we open a GitHub issue for it for future consideration. With data type validation, I think some cases will be simple and some won't (e.g. checking if something is an ISO datetime shouldn't be that hard), and I'd like us to handle the cases that are simple.

[pavish]

Perhaps the rule of thumb could be that if researching and implementing the validation takes only an hour or two, we should prioritize it now, otherwise we open a GitHub issue for it for future consideration.

I agree with @kgodey and I think we can follow this.

[seancolsen]

Sounds good. I added a separate answer for this to make it easy to see the final decision of this discussion.

[seancolsen]

To move forward with a decision, I'm marking this as the answer from @kgodey's comment:

If researching and implementing the validation takes only an hour or two, we should prioritize it now, otherwise we open a GitHub issue for it for future consideration