Eliminating duplication of validation metadata in client and server

Question

I tried to find some insight in how to handle the duplication of client-side and server-side validation in my app. If, for example, I have an User Entity like this on my back end:

type User struct {
    Id               int       `json:"id" validade:"required"`
    Email            string    `json:"email" validate:"required,email"`
    Name             string    `json:"name" validate:"required,max=20"`
    Nickname         string    `json:"nickname"`
}

When creating/updating a new user, for a better user experience, I have to validate this on the front-end with something like this (I use React to manage this, but this is similar):

<input type="email" name="email" required>
<input type="text" name="name" required maxlength="20">
<input type="text" name="nickname">

So, if I want to change the nickname field to be mandatory, I would have to change this validation logic in 2 completely different apps, on different teams, which is pretty complicated.

When I was studying REST a few years ago, I learned about HATEOAS, in which the server tells the client where the URIs are located. And I was thinking if there is something like this for validation metadata so that I don't have to create this unnecessary coupling.

I tried to find something like this on my search, but with no luck. My idea was to make something like a OPTIONS request to my back-end and it would return the basic data schema for my front, and it would use this for validation:

{
    "id": {
        "type": "integer",
        "required": true
    },
    "email": {
        "type": "email",
        "required": true
    },
    "name": {
        "type": "string",
        "required": true,
        "maxlength": 20
    },
    "nickname": {
        "type": "string",
        "required": false
    }
}

I think there is some kind of tool or best practice to handle this, but I couldn't find it. Right now, I have this validation metadata duplicated and it's kinda bad, but I can manage. Does someone knows how to handle this in a smart way?

Answer 1

There are only three ways of handling this:

1. Duplicate the validations
2. Validate in the API and return errors in the response.
3. Expose the validation rules via the API.

Whichever strategy you choose, you should be doing #2 anyhow. Never trust data from the client.

There is no magic library that can fully handle this. Even if you expose the validation rules via an API call, you still need logic on the client to interpret those rules.

Answer 2

An often overlooked option is to just emit the necessary client side representation from the same server side object that holds all the rest of the logic.

This is the only way to have validation and other parts of the logic not duplicated elsewhere, while still having proper client-side validations.

REST fits this thinking perfectly. You don't have to come up with a lot of new stuff. Your "options" is more or less what forms do in HTML, only with less validation options. You have to come up with a "form" syntax that has some validation rules, or maybe even just have javascript in there to be executed on the client. Key is again, you'll have to emit that from the server-side object, else you'll be duplicating stuff again.