TypeScript With Fewer Types?
Outdated API Type Definitions

Let’s say you are on a front-end team called Team Alpha (because front-end teams are the alphas… kidding) and you are consuming an API created by Team Bravo.

Your team is large, so you went with TypeScript and laid out some type definitions for a particular API endpoint:

OK, cool. Not only do we have type safety, but it’s easy to understand the input and output of the API endpoint.

Fast-forward one week, and Team Bravo made a change to the /user endpoint. They sent a message in the api-news channel on Slack. Some people on Team Alpha saw it, while others missed it. Suddenly, your front end is breaking and you don’t know why. Here’s what was changed:

Now, the types you wrote to protect you are causing massive debugging headaches because they are out of date.

After a brief amount of time banging your head against the wall, you either finally read the update from Team Bravo or you find the source of the problem yourself.

Maybe the first time is no big deal. You update the types and move on with your life.

But how many times are you going to have to debug, update, and refactor? Probably forever.

Ideal Solution

If possible, a great “hands-free” solution is to use a type generator for your API schema. If you use GraphQL, you are in luck because there are solid options for type generators (GraphQL code generator, Apollo codegen, etc).

This way, when the API changes, you can run a command to download the changes in request and response types. If you had the time, you could automate it to trigger downloads every time the API repo is updated, for example. That way, you are always up to date.

If you are using TypeScript on both the client and server, then I think it would be smart to leverage that fact and share types downstream. It doesn’t matter how, just as long as you aren’t writing request and response types on the client.
['Kris Guzman']
['JavaScript', 'Web Development', 'Typescript', 'Technology', 'Programming']