0

Consider the frontend makes an API call to a backend service.

client.get('/users');

and the response we are expecting is of the form:

{
    data: [
        {
            id: 1,
            name: 'John'
        },
        ...,
        {
            id: 10,
            name: 'Mary'
        },

    ]
}

if I were to use Typescript I would do something like:

type User = {
  id: number;
  name: string;
}

type UsersResp = {
  data: User[]
}

const users = (await client.get<UsersResp>('/users')).data;

Now, lets assume the backend makes a change and instead of sending back the aforementioned response, it just sends:

[
    {
        id: 1,
        name: 'John'
    },
    ...,
    {
        id: 10,
        name: 'Mary'
    },

]

Now the frontend will crush since there is no .data property.

My question is if there is any point at validating the response of the server in order to take some action in case the validation fails, ex. display a nice message to the user that something has gone terribly wrong.

Is there any point on doing that or it is just a boilerplate code that achieves nothing ?

entropyfeverone
  • 1,052
  • 2
  • 8
  • 20
  • 2
    Never trust network data. It's bad practice to not validate it. – jabaa Feb 23 '22 at 16:23
  • @jabaa This certainly applies for the backend, but I am asking for the frontend – entropyfeverone Feb 23 '22 at 16:24
  • This strikes me as an off-topic question. "Is this a good idea" is very subjective. It's going to depend on your priorities, risk, resources, whether something like this is worth it. – CollinD Feb 23 '22 at 16:24
  • Your app will crash on corrupted data. The obvious answer is: Validation achieves a better user experience. – jabaa Feb 23 '22 at 16:27
  • @entropyfeverone jabaa is right. It's *very good* to validate the responses. While developing, you'll spot and fix problems early when the data changes. Instead of finding out, say, two weeks later that there is a mysterious issue in one scenario and it takes you three hours to find that a slight change to the backend now delivers the wrong data. In production data wouldn't change randomly but you might still have a problem that you'd better be informed about than letting it slide and then *if you're lucky* bomb out with an error later. If you're unlucky it "works" but mangles the data. – VLAZ Feb 23 '22 at 16:38

1 Answers1

0

The need for validation depends on the situation. There is no simple yes/no answer and it depends on whether a breaking change is likely or not. When in doubt, I would always implement validation mechanisms because without error handling there could be unexpected behavior.

To answer your specific question:

lets assume the backend makes a change and instead of sending back the aforementioned response

From my understanding of your problem, you cannot completely rule out a malformed response. Therefore, the validation is not unnecessary boilerplate code. Without a validation, your client might run into an undefined state, resulting in the UI not working as expected and bad user experience.

One way of validating the shape of the response would be by using user-defined type guards.

nah0131
  • 329
  • 1
  • 8