Let's Build an API Together - Part 23

Last Update: 29.01.2018. By Jens in API Series | APIs | Newsletter

Now we are ready to add users. We can do it two ways.

1. Add the User model and make a JPA reference to the Board
2. Reference the user only by its ID in the Board

Both options are valid. Which to choose depends on the context.

When we use option 1, we get the benefit of having a foreign key in the table relations in the database. We could also access the board via the User model right in code because we use JPA. The relation between the two objects is clear; in code and DB.

However, each time we query for a board, we’d need to have either the user object loaded or query by ourself using a join. We either have two queries or a join involved. It has a performance impact; probably minor but that depends on the context.

When performance or resource usage is more important that obvious model relations, the second option might be a better choice. Yet, it has the disadvantages that we might have orphans boards in the DB where the user has left.

Another point to consider is the role of the user model. In monoliths, it will be a mix of username, password, roles, personal details (like first name, last name), customer category, billing information, etc. Do we need all aspects in one model?

What about I use, e.g., GitHub as an authentication provider? Could I not just use the GitHub userid in the Board model? What benefit do I get when I add a user model in this case?

For our series, I’ll go with option 2 because I want to test if the API can run in a 128MB memory app instance later; curiosity.