DEV Community: Serge

How To Write Transactional Database Calls in TypeScript

Serge — Tue, 05 Nov 2024 06:28:47 +0000

If you write web services, chances are you interact with a database. Occasionally, you’ll need to make changes that must be applied atomically — either all succeed, or none do. This is where transactions come in. In this article, I’ll show you how to implement transactions in your code to avoid issues with leaky abstractions.

Example

A common example is processing payments:

You need to get the user’s balance and check if it’s sufficient.
Then, you update the balance and save it.

Structure

Typically, your application will have two modules to separate business logic from database-related code.

Repository Module

This module handles all database-related operations, such as SQL queries. Below, we define two functions:

get_balance — Retrieves the user’s balance from the database.
set_balance — Updates the user’s balance.

import { Injectable } from '@nestjs/common';
import postgres from 'postgres';

@Injectable()
export class BillingRepository {
  constructor(
    private readonly db_connection: postgres.Sql,
  ) {}

  async get_balance(customer_id: string): Promise<number | null> {
    const rows = await this.db_connection`
      SELECT amount FROM balances 
      WHERE customer_id=${customer_id}
    `;
    return (rows[0]?.amount) ?? null;
  }

  async set_balance(customer_id: string, amount: number): Promise<void> {
    await this.db_connection`
      UPDATE balances 
      SET amount=${amount} 
      WHERE customer_id=${customer_id}
    `;
  }
}

Service Module

The service module contains business logic, such as fetching the balance, validating it, and saving the updated balance.

import { Injectable } from '@nestjs/common';
import { BillingRepository } from 'src/billing/billing.repository';

@Injectable()
export class BillingService {
  constructor(
    private readonly billing_repository: BillingRepository,
  ) {}

  async bill_customer(customer_id: string, amount: number) {
    const balance = await this.billing_repository.get_balance(customer_id);

    // The balance may change between the time of this check and the update.
    if (balance === null || balance < amount) {
      return new Error('Insufficient funds');
    }

    await this.billing_repository.set_balance(customer_id, balance - amount);
  }
}

In the bill_customer function, we first retrieve the user’s balance using get_balance. Then, we check if the balance is sufficient and update it with set_balance.

Transactions

The problem with the above code is that the balance could change between the time it is fetched and updated. To avoid this, we need to use transactions. You could handle this in two ways:

Embed business logic in the repository module: This approach couples business rules with database operations, making testing harder.
Use a transaction in the service module: This could lead to leaky abstractions, as the service module would need to manage database sessions explicitly.

Instead, I recommend a cleaner approach.

Transactional Code

A good way to handle transactions is to create a function that wraps a callback within a transaction. This function provides a session object that doesn’t expose unnecessary internal details, preventing leaky abstractions. The session object is passed to all database-related functions within the transaction.

Here’s how you can implement it:

import { Injectable } from '@nestjs/common';
import postgres, { TransactionSql } from 'postgres';

export type SessionObject = TransactionSql<Record<string, unknown>>;

@Injectable()
export class BillingRepository {
  constructor(
    private readonly db_connection: postgres.Sql,
  ) {}

  async run_in_session<T>(cb: (sql: SessionObject) => T | Promise<T>) {
    return await this.db_connection.begin((session) => cb(session));
  }

  async get_balance(
    customer_id: string, 
    session: postgres.TransactionSql | postgres.Sql = this.db_connection
  ): Promise<number | null> {
    const rows = await session`
      SELECT amount FROM balances 
      WHERE customer_id=${customer_id}
    `;
    return (rows[0]?.amount) ?? null;
  }

  async set_balance(
    customer_id: string, 
    amount: number, 
    session: postgres.TransactionSql | postgres.Sql = this.db_connection
  ): Promise<void> {
    await session`
      UPDATE balances 
      SET amount=${amount} 
      WHERE customer_id=${customer_id}
    `;
  }
}

In this example, the run_in_session function starts a transaction and executes a callback within it. The SessionObject type abstracts the database session to prevent leaking internal details. All database-related functions now accept a session object, ensuring they can participate in the same transaction.

Updated Service Module

The service module is updated to leverage transactions. Here’s what it looks like:

import { Injectable } from '@nestjs/common';
import { BillingRepository } from 'src/billing/billing-transactional.repository';

@Injectable()
export class BillingService {
  constructor(
    private readonly billing_repository: BillingRepository,
  ) {}

  async bill_customer(customer_id: string, amount: number) {
    const balance = await this.billing_repository.get_balance(customer_id);

    if (balance === null || balance < amount) {
      return new Error('Insufficient funds');
    }

    await this.billing_repository.set_balance(customer_id, balance - amount);
  }

  async bill_customer_transactional(customer_id: string, amount: number) {
    return await this.billing_repository.run_in_session(async (session) => {
      const balance = await this.billing_repository.get_balance(customer_id, session);

      if (balance === null || balance < amount) {
        return new Error('Insufficient funds');
      }

      await this.billing_repository.set_balance(customer_id, balance - amount, session);
    });
  }
}

In the bill_customer_transactional function, we call run_in_session and pass a callback with the session object as a parameter, then we pass this parameter to every function of the repository that we call. This ensures that both get_balance and set_balance run within the same transaction. If the balance changes between the two calls, the transaction will fail, maintaining data integrity.

Conclusion

Using transactions effectively ensures your database operations remain consistent, especially when multiple steps are involved. The approach I’ve outlined helps you manage transactions without leaking abstractions, making your code more maintainable. Try implementing this pattern in your next project to keep your logic clean and your data safe!

Thank you for reading!

If you want to reduce churn and increate conversion of your business check out my latest product Widgetform 💬. It is a highly configurable widget that allows you to collect insights about your users.

👏Don’t forget to like if you liked the article👏

Contacts
If you like this article don’t hesitate to connect on LinkedIn and follow me on Twitter.

Subscribe to my mailing list: https://sergedevs.com

Be sure to like and follow 👏

How to Split Applications Into Microservices—and When You Don’t Need Them

Serge — Tue, 05 Nov 2024 06:19:36 +0000

During my career, as with most developers with enough experience, I have seen bad and very bad microservice architectures and I have made bad decision too because it’s not obvious, everything related to software architecture is quite hard and requires a lot of experience. If you are new to the world of application architecture, this article is for you. Here I will try to show you what measures to use to to divide your application into services, when you need it, and when you don’t.

When You Need a Separate Service

When we talk about splitting an application into separate services, we have to be very cautious because every new service is a point of failure, an additional headache to the process of QA, deployment, etc.

Performance

One of the big reasons to have a separate service for some chunk of functionality is performance requirements. You may have your service built in Node.js or Python, but you definitely don’t want to write CPU-intensive calculations in these languages because you will be limited by their nature. In this case, it’s better to make it a separate service. Make a service in a more performant language such as: Rust, Golang. You can make it a service or you can embed it into an existing service.

Wrong Tool for the Job

Another case is if you have your core functionality written in, let’s say, Rust. You don’t want to write an admin portal or client portal in the same Rust service; it will take you ages. In this case, you are better off writing a separate service in Elixir, Ruby, JavaScript, or something that provides a full-stack framework that will save you time.

Criticality of the Service or Different Security Standards

Another considerable reason to split a piece of functionality into a separate service is the level of criticality of that service. Let’s say you wrote a piece of logic that does some calculations that do not require a lot of CPU or RAM, but these calculations are critical and must not be messed up. I would argue that it’s a serious reason to split that logic into a separate service in order to have a dedicated process for QA, CI/CD, and testing standards. You won’t need to give access to this repository to anyone except people who are responsible for this chunk of code; you will always know what to test and be highly cautious dealing with this service.

Infrastructure Cost

Another reason to have a separate service is infrastructure costs. Let’s take this example: you have a service A that is replicated into multiple geographical zones, and you have a piece of functionality that has heavy I/O load to and from a source that is located in one place. In this case, it’s better to split the I/O-related functionality into a separate service and place that service near the data source, because almost all cloud providers either provide output traffic for money or have limits. If your data-related service outputs terabytes of data, you have to care about the price that you will pay for this data.

When You Don’t Need a Separate Service

From my experience, you don’t need to make a separate service if you have one of the following cases.

Different Contexts

If you have a piece of functionality that has a different context, even if this context looks like a perfect candidate for a separate service – DON’T DO IT. Make it a different module and relax; there is nothing wrong with having your user management service as a module in your core monolithic service.

Different Scaling Requirements

If you have a chunk of code that will require serious scaling and you think that it’s better to make it a separate service, you shouldn’t if you can scale the incorporating service without too much cost. It’s always better to make something a separate module than a service unless you have different performance requirements (see “Performance” section). A module is always easy to split out into a service than do the opposite.

Language Preferences of Different Developers

No, you should not make a separate service if your developers don’t like the language and want to write in something else. It’s pretty much always better to keep the codebase consistent and in one place. By keeping things consistent, you will avoid a lot of headaches.

Thank you for reading!

👏Don’t forget to like if you liked the article👏

Contacts
If you like this article don’t hesitate to connect on LinkedIn and follow me on Twitter.

Subscribe to my mailing list: https://sergedevs.com

Be sure to like and follow 👏