Handling Transactions in TypeORM and Nest.js With Ease | by Dmitry Shamshurin | Apr, 2022

Picture by panumas nikhomkhai

There are lots of circumstances when a number of items of knowledge have to be created/up to date concurrently as a single unit of logic (i.e. creating one entity doesn’t make sense and mustn’t occur with out updating one other as a result of they rely upon one another). Databases akin to PostgreSQL present us with an applicable software for this case: transactions (such databases are referred to as “transactional databases”).

In response to the Wikipedia, Transactions primarily are a number of operations handled as a single unit of labor with “all-or-nothing” impact. It begins, does some database modifications, after which both is dedicated or, in case of any failure, is rolled again. This fashion database both has a brand new state with the entire modifications utilized, or is returned to its authentic state as if nothing occurred.

TypeORM helps database transactions and its documentation offers a reasonably good clarification of learn how to use them:

As famous within the documentation, this can be very essential to make use of the supplied occasion of EntityManager, don’t ever use the worldwide supervisor, in any other case you’ll have errors and/or unpredictable outcomes.

Drawbacks of utilizing TypeORM instantly

We see that TypeORM makes our life lots simpler since we don’t need to cope with SQL transactions themselves, however utilizing it within the enterprise code nonetheless has some drawbacks:

  1. If we comply with the DataSource / EntityManager method, we’ve to place all of our database operations into this one callback, nevertheless complicated they’re and nevertheless lots of them you may have.
  2. If we comply with the QueryRunner method, we’ve to jot down plenty of boilerplate code and be sure that we didn’t miss something in it.
  3. In each circumstances it makes our code a bit more durable to learn, keep, and reuse.

So what different choices do we’ve (contemplating we’re utilizing the Nest.js framework)?

  1. Use decorators to manage the transaction (@Transaction() and @TransactionManager()), which isn’t really useful by the Nest.js docs.
  2. Embrace some third social gathering library like typeorm-transactional-cls-hooked (which is predicated on this cool “Continuation Local Storage” idea) or nest_transact.
  3. Construct one thing comparatively easy your self that can swimsuit our wants and can summary away working with TypeORM transaction interfaces.

As you may need already guessed, I’ll cowl the third choice on this publish.

My good friend (Anton Pavlov) and I began considering on how we are able to disguise the entire inside workings of transactions away from the enterprise logic in our Nest.js software. We got here up with an summary transaction class that handles all of transactional stuff and offers us with a easy technique to write transactions and reuse their code anyplace within the codebase:

As you may see, this class incorporates that boilerplate code for QueryRunner , so we don’t need to cope with it anymore whereas leaving all the pieces associated to precise operations to this class’ descendants. If we have to create a transaction, we inherit from this base class, after which simply implement the execute perform, placing all of our logic there.

Now let’s see how we are able to use this transaction class that we’ve created. Please keep in mind that this code serves just one goal — to point out learn how to work with transactions, and we don’t care about a number of the implementation particulars (or correct variable names).

  1. First we create the CreateUserTransaction class which inherits from our BaseTransaction, offering typed arguments for enter and output of the transaction.
  2. The transaction itself is fairly easy: we simply create a Person after which create Steadiness entity which is related to our Person utilizing the supervisor that was created behind the scenes within the base class.
  3. Then, in our UserService we simply inject the CreateUserTransaction and name the run technique on it.
  4. The transaction can be commited solely after the run technique returns. We may be 100% certain that our person can be created solely with the stability, and never in some other means. If there’s any error, it is going to be caught and transaction can be rolled again, that means nothing can be modified within the database.

Let’s say, we’ve two eventualities: we are able to create a easy person with an empty stability, or a premium person with some bonus cash.

Additionally, think about that we’ve some form of abstraction layer in our undertaking that works with the database and handles all the small print about entities.

For brevity, I’ll present only one superficial instance of such abstraction implementation, and the remainder needs to be fairly easy and related.

On this instance:

  1. Our UserService begins the “massive” essential CreateUserTransaction to create a person.
  2. Inside the principle transaction we first name the runWithinTransaction technique of our CreateBasicUserTransaction, passing the supervisor that was created by the outer transaction. This is essential as a result of this supervisor can be that one piece that holds all the pieces collectively.
  3. Then we name our database abstraction layer lessons akin to DbUserService, DbBalanceService that deal with all the pieces that we want (in relation to entities), be it a easy name to the TypeORM repository, a number of of such calls, some fetching and remodeling knowledge, or just about something that you simply see match on this layer. As soon as once more, it’s essential to make use of that handed EntityManager for each database operation.
  4. After the CreateBasicUserTransaction is completed with person creation, our essential transaction continues with checking if a person is premium, does some further work if wanted, commits the modifications to the database (through BaseTransaction class), and returns the CreatedUserData for our UserService.
  5. As within the earlier instance, if something goes incorrect at any of the steps above, the transaction can be rolled again, and our database can be secure from any “partial”modifications.

The described means of working with transactions utilizing TypeORM and Nest.js permits us to separate any related business-related database logic into manageable and reusable components, and we don’t need to care concerning the transaction dealing with itself.

The one draw back of this method is the need of “dragging” the transactional EntityManager in every single place alongside the strategies that work together with our database.

We couldn’t discover a easy means round it as a result of we didn’t wish to overcomplicate our code, e.g. by together with the aforementioned “continuation native storage” idea, or inventing some good containers for managers. In the event you consider one, please depart a remark to this text, and we’ll gladly take a look at any of your ideas.

Further studying and hyperlinks from the article

  1. Transactions in Wikipedia
  2. TypeORM documentation on transactions
  3. Nest.js documentation on working with databases
  4. Nest.js transaction library built with continuation local storage concept
  5. Great article by Mikhail Alfa providing a different take on handling transactions with TypeORM and Nest.js and his library

More Posts