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 ?
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.