DEV Community: Nick

Handling Concurrency with Row Level Locking in PostgreSQL

Nick — Mon, 23 Jun 2025 23:05:22 +0000

Introduction

In any scalable system where multiple requests are being handled at the same time. Whether it's a microservice architecture, a monolithic backend, or even direct access to a database, concurrency becomes a critical concern. These issues often arise in subtle ways, especially when requests attempt to read and write shared data simultaneously.

Concurrency issues can easily be overlooked because they are often edge cases at a certain scale. But if concurrency handling is not addressed early, they can result in data loss and many lost hours of debugging strange inconsistencies.

One strategy to address this sort of problem is at the database layer. I will cover one such approach by using PostgreSQL's row-level locking feature, specifically the SELECT ... FOR UPDATE statement. Taking the time to understand these sorts of problems and having a strategy in place will surely save you and your team trouble down the road.

Background

Let's start with some quick background on locking in databases. This term may not be familiar to you if you haven't worked closely with how your database behaves under the hood, but I assure you, you have encountered locking before. For instance, take a standard update statement:

UPDATE users SET name = 'Nick' WHERE id = 1;

This operation does a few things behind the scenes: it locates the data from the target row, locks it, and then updates that value. The row-level lock is put on the row to ensure no other transactions can modify the row until the current one finishes. This operation usually happens so fast that we don't think about the lock, but it is absolutely there.

Locking behavior is governed through something called the isolation level. This specifies how transactions interact with another transaction's data. By default PostgreSQL (and most other databases) have an isolation level of READ COMMITTED. This means that the only data that can be read is data that has been committed, where uncommitted data (aka dirty reads) are not visible. Some databases (like SQL Server) allow READ UNCOMMITTED, which permits dirty reads. However, PostgreSQL does not truly support this level and you should in general avoid changing this.

We won’t go any deeper into isolation levels from here, but it’s worth understanding this concept before diving into row-level locking. Now, back to the problem at hand!

The Problem

Let's use a simple example of having an account that users can withdraw money from. You would probably have an endpoint in your service layer to withdraw from the account, which might have some SQL statements that look like this:

-- Start a transaction
BEGIN;

-- Read the current account balance
SELECT balance
FROM accounts
WHERE id = '1';

-- Perform some validation...

-- Update the account balance
UPDATE accounts SET balance = balance - 300 WHERE id = '1';

-- Commit the transaction
COMMIT;

Simple right? But what happens when two transactions perform this operation at the same time?

If there were two concurrent transactions, the account balance could be calculated incorrectly due to a race condition between the two transactions.

Let's say the account starts with a balance of 1000. Transaction 1 and Transaction 2 both begin and read the current balance, both see 1000. Transaction 1 subtracts 300 and commits. Then Transaction 2 subtracts 500 and commits.

Now the final balance is 500, but a total of 800 was withdrawn. Something’s clearly wrong. This is a classic race condition caused by a lack of concurrency control at the database level.

This problem is illustrated by the ladder diagram below.

Solving Concurrency with Row-Level Locking

In order to be able to ensure that the balance stays accurate, row-level locking can be used to set a lock on the data so it cannot be edited. At a high level, what we want to do is tell the database, "hey, database, I'm going to edit this row, make sure nothing happens to it while I work on it". This can be done with a locking method in PostgreSQL with a SELECT ... FOR UPDATE command. This command will put a lock on the row until the transaction in which it is included either commits or rolls back, so in turn can serialize these sorts of updates coming into the database.

The set of commands to execute this would not look any different, except the initial read through the SELECT clause would have FOR UPDATE added to the end.

-- Start a transaction
BEGIN;

-- Read the current account balance
SELECT balance FROM accounts WHERE id = '1' FOR UPDATE;

-- Perform some validation...

-- Update the account balance
UPDATE accounts SET balance = balance - 300 WHERE id = '1';

-- Commit the transaction
COMMIT;

Now, if two transactions try to withdraw from the same account:

Transaction 1 acquires the lock.
Transaction 2 is blocked until Transaction 1 commits or rolls back.
Transaction 2 then reads the updated balance and proceeds correctly.

Now, with this simple measure, we can ensure that the account balance stays accurate even during concurrent transactions. YAY!

Performance Considerations

While this approach solves concurrency issues, it can also bring along an increase in request latency. Since each transaction that accesses the same row must wait for the previous one to complete, these operations become serialized, effectively forming a queue. This ensures data integrity but can slow things down under heavy load.

In many cases, the tradeoff is worth it: consistency is more important than raw speed. However, if low latency is critical to your application, you may want to explore asynchronous, event-driven architectures instead. These systems allow you to decouple processing from user-facing requests, helping reduce perceived latency while still preserving correctness in eventual consistency models.

Is This the Right Approach for You?

Row-level locking is a powerful tool, but I do want to add that it may not be suitable for all applications.

The case for adding this will depend on your business case. In a financial application like in the above example, accuracy is a must. Think bank accounts, ticket sales, and inventory control. In these cases strict concurrency control is crucial.

But in other situations, perfect accuracy may not be worth the complexity or performance tradeoff. For example counting views or likes on a post or maybe tracking analytics events. In these cases it may be acceptable for the number to be slightly off due to concurrency.

The key is to understand your product requirements so you can make an informed decision and define your approach.

Look Out for Deadlocks!

While row-level locking prevents race conditions, it can introduce deadlocks if not used carefully. In the example above, we do not run the risk of a deadlock because there is a single account being worked on in each transaction.

Deadlocks occur when two (or more) transactions wait on each other for data in a circular fashion.

Transaction 1

SELECT balance FROM accounts WHERE id = '1' FOR UPDATE;
-- later
SELECT balance FROM accounts WHERE id = '2' FOR UPDATE;

Transaction 2

SELECT balance FROM accounts WHERE id = '2' FOR UPDATE;
-- later
SELECT balance FROM accounts WHERE id = '1' FOR UPDATE;

Both transactions are now waiting for the other to commit or roll back, that's a Deadlock!

PostgreSQL will recognize this issue and abort one of the transactions. In general, you should watch out for this pattern and keep a consistent order when acquiring locks to avoid this altogether.

Conclusion

Concurrency can be sneaky and should be handled early on during application development. Fortunately, with features like SELECT ... FOR UPDATE, PostgreSQL gives us the tools we need to handle concurrency safely. By applying these patterns early, you can save yourself a lot of debugging time and ensure your system scales with integrity.

If you want to go further into this topic, check out some of the other features PostgreSQL has to offer, including table and page-level locks. You can read more about them in the documentation here: 13.3 - Explicit Locking.

I hope you enjoyed this article. Please leave a comment if I missed anything or if you have used row-level locking in your projects!

Thanks for reading :)

Create an Auto-Incrementing Version Column With PostgreSQL Triggers

Nick — Tue, 04 Feb 2025 19:51:19 +0000

Introduction

When building database schemas, there will often be the desire to create a versioning column on all or some database tables. A developer's knee-jerk reaction may be to implement this at the code level. This approach can be quite simple depending on how your code is architected. Say you have a single CRUD service/module in your application, you could just add some logic there to increment a version column during an update. This approach can work fine but it is yet one more thing that needs to be kept track of in case your code-level patterns change from refactoring.

Utilizing a database trigger is a simple and more efficient approach to solving this problem. This is something that PostgreSQL (Postgres), among most modern databases, supports as a feature and its use can be quite powerful. To illustrate how this can be done we will walk through how to build a trigger in Postgres to implement an auto-incrementing versioning column.

Within this post, I will assume you have minimal knowledge of Postgres triggers and will explain every step of the way.

What Are Triggers and How Do They Work?

Postgres triggers let you create a declaration to execute a function within the database that ties into certain actions. Some might think of these as "hooks" that hook into database actions. The actions that I am referring to here are the DML statements INSERT, UPDATE, and DELETE. These actions are specified in the SQL standard. The logic contained in the function that is triggered can be further specified to fire either BEFORE or AFTER the action that is taking place. In addition to the previously mentioned DML commands, Postgres also supports adding triggers around the TRUNCATE action which not all databases support.

Another point to keep in mind is that triggers are transactional. This means that triggers are part of the same transaction as the statement that fired them and if the transaction is rolled back, the trigger's actions are also rolled back. This is important to keep in mind for debugging purposes and something to consider from an observability perspective when implementing triggers. Whenever you are adding more logic to your database there could, of course, be more failure points to consider that now lie outside of the code level.

Building A Postgres Trigger

To first clarify what our goal is here. We will create a table with a column called version that will initialize to 0, and our goal will be for each UPDATE statement executed against a row in this table, the version column will increment by 1.

Let's start with a DML statement to create a table to apply our trigger.

CREATE TABLE table_1 (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  version INTEGER NOT NULL DEFAULT 0,
  name VARCHAR NOT NULL
);

In this statement, I have added three columns to the table table_1.

id - This is set as our primary key and defaults to use the native Postgres function of gen_random_uuid() to give us a unique identifier for each row in the table.
version - This will serve as the version column we will increment with our trigger. It is set to default to 0.
name - A VARCHAR column we will use to test applying our updates.

Now to get something to work with, let's insert a row to our new table.

INSERT INTO table_1 (name) VALUES ('Nick');

If you run a SELECT statement you should see a new record in table_1.

SELECT * FROM table_1;

The first step to creating a trigger is to create a function. That may sound a little strange but creating a trigger is a two-part process. First, create a function, then create the trigger which will utilize the function. All the magic will happen inside the function which must be set as a special type of Postgres function. The function is created in a similar fashion to any other function or stored procedure except it must not take any arguments and must return a type of TRIGGER. In our case, the function will look like this.

CREATE OR REPLACE FUNCTION increment_version() 
RETURNS TRIGGER AS $$
BEGIN
    NEW.version = COALESCE(OLD.version, 0) + 1;
    RETURN NEW;
END
$$ LANGUAGE plpgsql;

A couple of points to note on the above statement:

I use CREATE OR REPLACE here which works as an "upsert" action for the function. If this is the first time creating a function just writing CREATE would have worked just fine.
The function is declared to return a trigger with RETURNS TRIGGER.
The OLD and NEW variables are available inside all Postgres triggers and correspond to the old table record and new table record respectively. The value for the column version is accessed through dot notation.
LANGUAGE plpgsql declares that the function is written in the PL/pgSQL procedural language.

Having the function, we can now apply the trigger to our table.

CREATE OR REPLACE TRIGGER update_version 
BEFORE UPDATE ON table_1 
FOR EACH ROW
EXECUTE FUNCTION increment_version();

The statement to apply the trigger is a little more simple than creating the function.

The trigger is created with the name update_version.
BEFORE UPDATE specifies that we would like to fire the trigger before an update statement executes on table_1.
FOR EACH ROW specifies that this should apply to every row affected by the update statement.
EXECUTE FUNCTION increment_version() declares that our function from the previous step will be called here.

The trigger is now applied. If you execute an update statement to the record we created earlier, you should see the version column increment by 1 with each update.

With the function already created it becomes very easy to extend this trigger to new tables. You would simply run the CREATE OR REPLACE TRIGGER statement against the table where you would want to apply the trigger. For example, if we had another table, table_2, we could execute the statement below.

CREATE OR REPLACE TRIGGER update_version 
BEFORE UPDATE ON table_2 
FOR EACH ROW
EXECUTE FUNCTION increment_version();

One point to note is that we used the same name for the trigger, update_version, on this new table, and that is perfectly ok! Trigger names must be unique within the context of the same table, but they can be the same across different tables. So, if we created a new trigger on table_2, we would have to give it a name other than update_version since this is now taken.

Adding Better Validation

At this point, you may be asking yourself, "What if the table didn't have a version column?". The answer to this is that the function we wrote would raise an error, and as mentioned before the trigger is transactional so it would make the entire transaction that this action was a part of rollback. If you are very careful and have good test coverage this may not be something to worry about, and the errors would surface rather quickly since you would be seeing a ton of failures coming from update operations. But, alas, programmers are human (for now), and we make mistakes.

To beef up the validation, we can update our function with an extra bit of logic that would put in a fail-safe for us in case the version column did not exist on the table. Here is the revised function.

CREATE OR REPLACE FUNCTION increment_version() 
RETURNS TRIGGER AS $$
DECLARE
    table_columns TEXT[];
    column_exists BOOLEAN;
BEGIN
    SELECT ARRAY_AGG(column_name)
     INTO table_columns 
     FROM information_schema.columns 
     WHERE table_name = TG_TABLE_NAME 
     AND table_schema = TG_TABLE_SCHEMA;

    column_exists := 'version' = ANY(table_columns);

    IF column_exists IS TRUE THEN
        NEW.version = COALESCE(OLD.version, 0) + 1;
    END IF;

    RETURN NEW;
END
$$ LANGUAGE plpgsql;

The updated function has some new logic to add the validation.

A query is made to read the columns of our table by querying against the information_schema.columns table, which is maintained under the hood by Postgres. A filter is made against the query with TG_TABLE_NAME and TG_TABLE_SCHEMA, which are variables that are available inside Postgres triggers and correspond to the name of the table and the schema where the table is located.
A check is made to see whether the version column exists with column_exists := 'version' = ANY(table_columns);.
The operation to increment the version column is made conditional depending on whether or not the column exists on the table.

Since we have overwritten the function with CREATE OR REPLACE FUNCTION, the name has not changed and this update will automatically go into effect wherever it is applied!

Conclusion

We were able to create a basic Postgres trigger to add versioning to our database records. This is a very simple use case, and the applications of Postgres triggers are endless. Hopefully this gives some insight into how easy it can be to implement a Postgres trigger and gets you thinking about what code-level logic can transition to your database layer.

To read more about Postgres triggers, you can check out the docs here

Thanks for reading!

Reusable NestJS Interceptors with a Factory Pattern

Nick — Thu, 23 Jan 2025 20:49:33 +0000

Intro

Anyone diving into developing APIs with NestJS has seen the benefits of binding logic to API endpoints with interceptors. While interceptors are a great tool to add code execution before your endpoints, they come with some code overhead to create an interceptor for every case in your application. I recently found myself creating interceptors for very similar use cases within a NestJS API and discovered a nice, reusable method of creating interceptors utilizing a factory pattern which alleviates some of the code bloat.

The factory pattern focuses on code reusability and efficiency. It uses an abstract class as a common interface in a factory function to create a NestJS interceptor on the fly rather than creating an individual interceptor.

Within this post I will assume that you have some basic understanding of NestJS. If you are brand new to NestJS I would recommend to have a look at the docs, specifically the "Overview" section of the docs before reading this article.

This pattern will also be utilizing TypeScript and I will assume you are familiar with some of the basic patterns of TypeScript (generics, class syntax, typing).

App Setup

To set the scene, we will begin with a very standard NestJS application. Say we have a REST API with a POST endpoint at /user/create where we create new user records.

To follow the standard NestJS patterns, we would have a controller, service, and module.

Controller

@Controller('user')
export class UserController {
    constructor(private readonly userService: UserService) {}

    @Post('create')
    createOneUser(@Body() dto: CreateOneUserDto) {
        return this.userService.createOne(dto);
    }
}

Service

@Injectable()
export class UserService {
    createOne(dto: CreateOneUserDto): string {
        // User create stuff goes here...
        return `User created successfully`;
    }
}

Module

@Module({
    imports: [],
    controllers: [UserController],
    providers: [
        UserService
    ],
    exports: [],
})
export class UserModule {}

This is a very standard setup of a NestJS Module so I won't go into any detail on the above code.

Now, say we want to add a validation step to the createOneUser controller method before we call our service. This is a case where one would typically reach for an interceptor to add this validation step. The standard pattern would be to implement a standalone interceptor that could hold some validation logic to execute before creating a new user, but what if we wanted to do the same thing in another module for a separate entity model? This would typically require us to create another interceptor to essentially do the same thing. This is the problem we will aim to solve with the factory pattern.

NestJS provides many other ways of binding logic to your endpoints, such as pipes and guards, but for this example, we will create an interceptor with our factory. Hopefully, you will see that this pattern could easily be re-crafted for pipes and guards as well.

Building An Interceptor Factory

To design this pattern for code reuse, we will introduce an additional service, a validation service, that will be called from the interceptor. So the interceptor will operate more like a pass-through to the new validation service. The flow would then look something like this:

Interceptor -> Validation Service -> Controller -> Service

Now, to start creating our factory we will begin by creating an abstract class to use as a common interface for our validation service.

export abstract class BaseValidationService<T extends any = any> {
    abstract validateCreate(dto: T): T;
}

This establishes an abstract class called BaseValidationService which we can extend to ensure we have a common interface for our validation service, and for future validation services that may use this pattern. This gives us type safety as we integrate our validation service into the factory. An abstract method of validateCreate has been defined which we can use to hold the validation logic for our endpoint.

For the validation service, we will create a new injectable service that will extend the base service we just defined. We could create a validation service like this:

@Injectable()
export class UserValidationService extends BaseValidationService<CreateOneUserDto> {
    constructor() {
        super();
    }

    validateCreate(body: CreateOneUserDto): CreateOneUserDto {
        if (body.id.length < 5) {
            throw new HttpException(
                'id must be greater than 5 digits',
                HttpStatus.BAD_REQUEST,
            );
        }

        return body;
    }
}

This complies with the format of the BaseValidationService through class inheritance and your IDE should give you some notice if something is wrong with how you are extending the abstract class. We define the validateCreate function which, for example purposes, will validate that a value for the id key in the body is greater than 5 digits. This is something that could typically be accomplished with a package like class-validator but this is just to illustrate the pattern.

Now, finally, to create the factory we can write a new factory function that will create an interceptor that will route the request to the validation service method we just defined.

export const ValidationCreateFactory = (
    validation: new (...args: any[]) => BaseValidationService,
) => {

    @Injectable()
    class ValidationInterceptor implements NestInterceptor {
        constructor(
            @Inject(validation.name)
            readonly validationService: BaseValidationService,
        ) {}

        async intercept(
            context: ExecutionContext, 
            next: CallHandler
        ): Promise<Observable<any>> {
            let body = context.switchToHttp().getRequest().body;
            body = await this.validationService.validateCreate(body);
            return next.handle().pipe();
        }
    }

    return ValidationInterceptor;
};

To take a step back and look at what this is doing. This is a function that accepts a class in the shape of our abstract class of BaseValidationService and returns a NestJS interceptor. Inside the interceptor, we go through a fairly standard flow of grabbing the HTTP request body and passing it as an argument to the validateCreate method in the validation service.

One special thing to note is how the interceptor can grab the instance of the validation service from the Nest DI graph. This is accomplished with the @Inject decorator, where a token for the validation service is used to create the dependency in its constructor method. This will be important as we add the validation service to our module where we will need to use the long-hand syntax for creating dependencies.

@Module({
    imports: [],
    controllers: [UserController],
    providers: [
        UserService,
        {
            useClass: UserValidationService,
            provide: UserValidationService.name,
        },
    ],
    exports: [],
})
export class UserModule {}

We can now utilize the factory function to put everything together inside the controller with the @UseInterceptors decorator much like we would add any typical interceptor.

@Controller('user')
export class UserController {
    constructor(private readonly userService: UserService) {}

    @Post('create')
    @UseInterceptors(ValidationCreateFactory(UserValidationService))
    createOneUser(@Body() dto: CreateOneUserDto) {
        return this.userService.createOne(dto);
    }
}

Now we have implemented a reusable pattern that would be able to add a validation step to any create endpoint in this Nest application. In case other entity models were added to this API, the separate module could easily tap into this pattern to add a validation step by simply creating a new validation service and using the ValidationCreateFactory function that we have defined. Looking further, imagine if there was an update endpoint where we wanted to validate the body of a separate update endpoint. We could create another factory to route the request to a separate validation method, that could be called validateUpdate. This is where you would really start to notice the code reusability benefits of this pattern.

Considerations

There is one special thing to note about this pattern. You will notice that the factory is just a function, which means that each time it is used will equate to a separate function call. Within a large application, this could result in some cold start performance issues as each factory call will be executed each time the app starts up. In most small applications this would probably be negligible but something to note in case you adopt a pattern like this in your application.

Conclusion

I hope you liked this post and took something away from it. Patterns like this can be really nice when using a framework like NestJS where there is a lot of class-based tooling. Keep in mind the performance drawback to this pattern but if it makes sense to use it in your application I hope you explore the possible use cases!

Thanks for reading :).

Creating an Array of Unique Objects in Javascript

Nick — Thu, 09 May 2024 01:50:31 +0000

I recently uncovered a nifty trick to be able to create a unique array of objects in Javascript that you should definitely add to your tool belt.

Have you ever found yourself building up some sort of array that contains objects that may contain duplicates? What I mean is ending up with something like this:

const arrayOfObjs = [
  {id: '123', code: 'ABC'},
  {id: '456', code: 'DEF'},
  {id: '123', code: 'ABC'},
  ...
]

So, how can we remove the duplicates here?

In these sorts of situations my instinct is to use lodash, but this can be done with plain old Javascript.

By utilizing the Map constructor and creating a new Map instance, this array can be filtered down to unique values.

const arrayOfObjsMap = new Map(
  arrayOgObjs.map((item) => {
    return [JSON.stringify(item), item];
  }),
);

const uniqueArrayOfObjs = arrayOfObjsMap.values();

This method of removing duplicates from the array takes advantage of the fact that keys in Maps are unique, so the removal of duplicates will inherently be taken care of through the construction of this Map.

The Map constructor can take an iterable (per the MDN docs) which can represent key-value pairs for the Map object. So, by using JSON.stringify() on the iteratees of our array we are able to create a unique string when constructing our Map keys which serves as the unique identifier for our objects. Then by simply calling values() on the new Map instance we are back to having an array of objects but now we have no duplicates.

Hope you find this useful!

Using Function Parameters with Conditional Types in Typescript

Nick — Thu, 04 Apr 2024 02:26:45 +0000

Lately, I find myself wanting to conditionally return one of two different types from a function, while still getting Typescript's static typing benefits. This is possible by constructing a conditional type in Typescript.

The concept itself is quite simple but becomes powerful when combined with querying data – which we will uncover towards the end of this post. But first, a contrived example...

A Basic Example

Say you have two different interfaces a Cat interface and a Dog interface.

interface Cat {
 sound: 'meow';
}

interface Dog {
 sound: 'woof';
}

And you would like to conditionally return one of the two from a function.

With conditional types, a ternary-like syntax can be used to construct a new type CatOrDog that can return either a Cat or Dog based on a generic.

type CatOrDog<T extends 'cat' | 'dog'> = T extends 'cat' ? Cat : Dog;

This new type can then be used in a function to conditionally return a Cat or a Dog based on a function parameter to dictate which we should expect to receive from a function.

function getCatOrDog<T extends 'cat' | 'dog'>(option: T): CatOrDog<T>  {
 if (option === 'cat') {
  return {sound: 'meow'};
 }

 if (option === 'dog') {
  return {sound: 'woof'};
 }
}

getCatOrDog('cat'); // returns Cat
getCatOrDog('dog'); // returns Dog

The above function will conditionally return a Cat or a Dog type depending on what is passed into the option parameter. This leads to a great developer experience as you can take advantage of Typescript's static type checking here and some modern IDEs can give you intelli-sense to flag any type errors when using this function during development.

Now that we have a basic example in place, let's move on to a more useful situation...

A Practical Use Case

The CatOrDog example is a contrived use of this pattern. The benefits become quite apparent when you combine this with fetching data from a database, which is where I find myself reaching for this pattern most often (usually with an ORM like TypeORM).

Say you have an application where you store user information in a table called user and contact information in a separate table called contact_info and there is a 1:1 relationship between the two tables, you may have interfaces set up similar to the following, which represent an entity structure in your database.

interface User {
 id: string;
 name: string;
}

interface ContactInfo {
 phone: string;
 address: string;
 userId: string;
}

Then say when you query users you may want to conditionally hydrate the contact information for a user. You could make a conditional type that uses a function parameter, as we did before, to determine whether you should expect to receive an instance of User or User & ContactInfo. The function can use the same function parameter to add a join to a query based on the input value.

type UserOrUserWithContactInfo<T extends boolean> = T extends true ? User & ContactInfo : User;

async function fetchUser<T extends boolean>(id: string, withContactInfo: T): Promise<UserOrUserWithContactInfo<T>> {
 const query = `
  SELECT *
  FROM user
 `

 if (withContactInfo) {
  query += `
   LEFT JOIN contact_info on user.id = contact_info."userId"
  `
 }

 const query += `
  WHERE user.id = '${id}'
 `

 // assume this executes our query string
 return connection.query(query);
}

await fetchUsers(false); // returns User
await fetchUsers(true); // returns User & ContactInfo

Now when using this function you can benefit from static type checking by conditionally adding a join to a query to fetch the contact information related to a user. This utilizes the new UserOrUserWithContactInfo conditional type which returns either a User or User & ContactInfo based on the boolean value that we pass to the withContactInfo function parameter.

You can read more about Typescript conditional types here.