Model Creators: Preventing from inconsistent data from 3rd parties

Published in

ImperdibleSoft

6 min readMar 31, 2020

Today I want to talk about a useful concept that has saved me tons of time when integrating my application with backend (and 3rd party APIs). And it is the concept of model creators.

But let’s start by the begining

What are models

First of all, what are models?

A model is a data structure that we define on order to store some data. For example, imagine that we have this object.

From here, we can infer that our model has 4 properties: firstName, lastName and gender, which are strings; and age, which is a number.

Models are a very important part on any application, because it defines how we are storing our data, so that is defining how we access to that data.

Why Model Creators

Another important reality is that we’re living in an interactive world. Our application is going to communicate with other applications, in order to get/save data. Think about a frontend making a request to backend, a backend making a query against a database, any service integrating with 3rd party APIs.

If you think about it, each application has its own models, which usually are different between them. As you can imagine, this is a problem.

Let’s imagine a common scenario. Imagine we’re trying to make a simple login:

As you can see, I’m able to retrieve loggedUser, but that object is generated by backend, and it may change. So, imagine that this API changes, and it’s not returning firstName neither lastName anymore.

Now, we have a problem, because we’ve used those properties throughout the entire application several times, so our application is going to break.

Model creators will help you to prevent these kind of situations.

Who are model creators for?

As you are figuring it out, this is a common problem for all of us. I bet all of you have faced some similar problems at least once per project. It doesn’t matter if you are frontend, backend or native developer. Shit happens 😕.

I usually say to my coworkers: Don’t trust backend guys. Never.

But, do you know what? Don’t trust frontend guys, neither. Don’t trust anyone. If you are a developer, you need to use model creators.

So, what are model creators?

Let’s go to the matter. What are model creators? Well, it’s something really simple. Model creators are just pure functions with very specific objectives.

Let’s talk about what we are doing on createUserFromServer.

First: Check incoming item’s properties

As you can see, the first thing I’m doing is checking mandatory properties for my user. These are properties that I need and I cannot operate without them, such as the id or the firstName.

Thanks to this, I can grant that my user is going to always have an id and a firstName.

Second: Discard malformed items

As you can see, if some of our mandatory properties is not present in backends model, the model creator is returning undefined.

This means that no user is going to be logged in in our application. Why? Because we don’t have enough data to operate with the information we got, so it’s better to prevent some weird or error-prone scenarios.

Third: transform into valid model for my application

Next step is ensure the output model is a valid model for our application. For example, we expect that id is a string, so we can infer something based on characters. We also expect age to be a number, in case it is present.

One not so funny anecdote I have. I was in a project where backend was returning ‘y’ or ‘n’ strings (representing ‘yes’ or ‘no’) instead of sending booleans.

This results in a scenario like the following:

As you can imagine, this is not a pleasant thing to be doing each time we want to validate a boolean. What if I tell you that sometimes, that ‘y’ was uppercase, and sometimes lowercase?

Well, now, I’m showing you what my model creator can do for me.

As you can see, I don’t care anymore if the ‘y’ is uppercase or not. In deed, I don’t care if it’s present or not, because my model creator has transformed it to an actual boolean. So I will have a regular boolean in my application, always 😁.

Bonus: Track malformed items

Now, you may notice that, if we are discarding malformed items, we are not going to realize there are malformed items.

In this example, we will think there is a problem with the login. In deed, we will think there is a frontend issue, because backend is responding with a 200 status, so “something must be failing in the frontend”, when the reality is that backend is not sending what we expect.

Well, there are 2 complementary solutions:

Log that as an error
Track it with an error tracking tool

Thanks to these 2 steps, we are going to get errors in our development console, so we can identify malformed items.

If we use an error tracking tool, we will be able to track errors from actual users, even if they think everything is OK and application is not crashing.

*Important note: Look that I’m not using throw new Error, because if I do that, my code execution will stop, and I don’t want that.

I want to remove the invalid item and continue my code execution. That’s why I’m using a console.error and tracking the error manually (in case my error tracking tool doesn’t track it automatically).

When should I use model creators?

So, based on this, I will encourage you to always use model creators. No matter if you are expecting a simple string. If the service that you are consuming is out of your application, use model creators.

Also, use them as soon as external data reaches your application, before storing/using it, so you can make sure that data stored in your application will always respect your models.

In this scenario, each time I execute login, I’m sure I’m always getting a valid response, so anywhere I access to loggedUser, it will be a valid user.

If backend’s model changes, because any reason, and I’m not able to get mandatory data, I won’t be able to login, and my application won’t crash.

More advantages

Now imagine backend is changing lastName and is renaming it to last_name.

Reliability

Thanks to our model creator, I will still have a lastName property, which is an empty string, because I’m looking for lastName instead of last_name, but it won’t be undefined, which means my application won’t crash when I try to access to that property.

Consistency

In deed, if I update my model creator, I will be able to transform backend’s last_name into my expected property lastName, so I won’t need to change that property name across my entire application 🥳.

More complex examples

There are a lot of scenarios where this can be a really useful practice. So I will show you some of the most common examples where model creators will save you tons of time.