| Client-side validation are much more important that server-side validations. Preventing a user from sending bad data to begin with avoids the poor usability of having to send bad a failed request and reset the form for editing. Database constraints only avoid bad data in the database. They still have to be duplicated for error checking in the server and client. Is JS is used on both the server and client, it makes a lot more sense to have ORM models that act as the single source of truth for structure (ie model/schema), condtraints, testing, and validations. Issues with unstructured data come either from laziness (ie not using schemas in production code) or mismanagement (ie not handling migrations properly between schema changes). Having the ability to use completely schema-free, unstructured data doesn't mean schema/validations should be ignored altogether. You wouldn't blame the gun if you shot yourself in the foot, would you? |
There may be more than one client connecting to the database at the same time (or even internal inconsistencies within the same process), and the only way to prevent data inconsistencies is to hand the final responsibility of validation to the thing that is actually storing the data, ie. the database.
In the end, your database is the single source of truth, as it is the only part of your architecture that is technically capable of doing so. Client-side validation and server-side validation (in the application) are niceties for UX purposes, but do not and cannot replace database constraints.