Home > Software design >  How to handle failed API contracts in frontend applications
How to handle failed API contracts in frontend applications

Time:11-19

I have developed several frontend applications and as I analyse I often need to refactor the front-end code or frontend crash in the following case:

Let's assume there is a endpoint /movies that returns the following response:

{
  "movieName": "Avengers Endgame",
  "genre": "Action, Thriller",
  "length": 120 // in minutes 
  "rating": 4,
  "id": 1
}

To handle this endpoint's response in the frontend application (React Typescript), I have created a MovieType and will render the data in the component.

// types.ts

  export type MovieType = {
    movieName: string;
    genre: string;
    length: number;
    rating: number;
    id: number;
  }
import React from 'react';

function MovieComponent() {
  const [movies, setMovies] = React.useState([] as MovieType[]);

  React.useEffect(() => {
    const data:MovieType[] = fetchDataSomeHow() as MovieType[];
    setMovies(data);
  })

  return (
    <ul>
      movies.map(movie => (
        <li key={movie.id}>
          {movie.movieName.toLoweCase()} - {movie.rating}
        </li>
      ))

    </ul>
  )
}

So here I have created MovieType by looking at the response of the /movies endpoint and marked movieName as required in MovieType. Here the MovieType is affected by the data returned by the /movies endpoint.

As I am using Typescript and I have defined movieName as string and required, I can use toLowerCase method without any additional checks.

Now let's suppose that there is some bad input in the movie database and in the response movieName is undefined/null or movieName is changed to name. Now the frontend application will crash because of runtime errors.

This happens whenever there is an API contract mismatch in the frontend and backend because of bad database entries or sudden backend API changes.

is there any standard or a good way to handle this kind of errors? I can easily make every field optional and then write frontend code but it will be messy and nonreadble. On the backend side, we have concepts of adapters that validate and sanitise the data and throws errors in case of invalid requests but on the frontend side, we can't hang users on an error page just because we got one field wrong in one object among 1000 objects.

CodePudding user response:

You can check if movie exists using && check:

movie && {movie.movieName.toLoweCase()} - {movie.rating}
<iframe name="sif1" sandbox="allow-forms allow-modals allow-scripts" frameborder="0"></iframe>

CodePudding user response:

I would classify the type as unknown. Big picture, you are getting something, and you don't know what it is. So it's unknown. After you do this, Typescript will force you to check everything, then you get all the benefits of the typed result.

You could still define the type

export type MovieType = {
    movieName: string;
    genre: string;
    length: number;
    rating: number;
    id: number;
  }

But your result from the API would initially be unknown. After you get your result, you would narrow the result. The unknown type will protect you from mistakes in this process. When it is appropriately narrowed, you could then assign it to a type of MovieType or work with those of that type.

const result: Record<string, unknown> = {
  movieName: "test",
};

export type MovieType = {
  movieName: string;
  genre: string;
  length: number;
  rating: number;
  id: number;
};

let someMovie: MovieType | undefined;

if (
  typeof result === "object" &&
  typeof result.movieName === "string" &&
  typeof result.genre === "string" &&
  typeof result.length === "number" &&
  typeof result.rating === "number" &&
  typeof result.id === "number"
) {
  someMovie = {
    movieName: result.movieName,
    genre: result.genre,
    length: result.length,
    rating: result.rating,
    id: result.id,
  };
}

Unfortunately I could not directly just use type unknown and narrow it all the way to a Record<string, unknown>. I asked my own question on this, but I think it may be impossible currently.

  • Related