In many applications, completing more than a single update as an atomic unit (transaction) is needed to preserve data integrity. This installment of the ongoing Node.js Reference Architecture series covers the Node.js reference architecture team’s experience with integrating transactions into your application to satisfy this requirement.
Follow the series:
- Part 1: Overview of the Node.js reference architecture
- Part 2: Logging in Node.js
- Part 3: Code consistency in Node.js
- Part 4: GraphQL in Node.js
- Part 5: Building good containers
- Part 6: Choosing web frameworks
- Part 7: Code coverage
- Part 8: Typescript
- Part 9: Securing Node.js applications
- Part 10: Accessibility
- Part 11: Typical development workflows
- Part 12: Npm development
- Part 13: Problem determination
- Part 14: Testing
- Part 15: Transaction handling
- Part 16: Load balancing, threading, and scaling
- Part 17: CI/CD best practices in Node.js
- Part 18: Wrapping up
Ecosystem support for transactions
Unlike the Java ecosystem, there are no well-established application servers with built in support for transactions and no JavaScript specific standards for transactions. Instead, Node.js applications either depend on the transaction support within databases and their related Node.js clients and/or use patterns which are needed when business logic is spread over a number of microservices. These patterns include:
Leveraging database support for transactions
In the team's experience, if the updates that need to be completed atomically can be handled by a single Node.js component, and you are using a database with support for transactions that is the easiest case.
In some Node.js database clients, there is no specific support for transactions in the client, but that does not mean that transactions are not supported. Instead transactions are managed by using protocol level statements (for example BEGIN/COMMIT in SQL). PostgreSQL is one of those databases. A simple example of using a transaction from the node-postgres client documentation is as follows:
const { Pool } = require('pg')
const pool = new Pool()
const client = await pool.connect()
try {
await client.query('BEGIN')
const queryText = 'INSERT INTO users(name) VALUES($1) RETURNING id'
const res = await client.query(queryText, ['brianc'])
const insertPhotoText = 'INSERT INTO photos(user_id, photo_url) VALUES ($1, $2)'
const insertPhotoValues = [res.rows[0].id, 's3.bucket.foo']
await client.query(insertPhotoText, insertPhotoValues)
await client.query('COMMIT')
} catch (e) {
await client.query('ROLLBACK')
throw e
} finally {
client.release()
}
In the team's experience transactions work best with async/await versus generators, and it is good to have a try/catch around the rollback sections in addition to those which do the commit.
The challenges of microservices
In the team’s experience, the more common case is that a Node.js application incorporates a number of microservices, each of which might have a connection to the database or even may store data across different types or instances of datastores.
The challenges that come with implementing transactions with microservices are not unique to Node.js and the common approaches include:
These are also used in Node.js applications.
Patterns for distributed transactions within a microservices architecture provides a nice overview of the challenges introduced when managing transactions across microservices and these two patterns.
In the team's experience, Node.js applications will most often use the Saga pattern as opposed to two-phase commit, in part since the microservices may not share the same data store.
When two-phase commit is used, it will have to depend on external support from an underlying data store. Some databases offer support to help with implementing the two-phase commit technique, so read through the documentation for the database you are using if you are planning to use that technique.
Learn more about Node.js reference architecture
I hope that this quick overview of the transaction handling part of the Node.js reference architecture, along with the team discussions that led to that content, has been helpful, and that the information shared in the architecture helps you in your future implementations.
We cover new topics regularly for the Node.js reference architecture series. In the next installment, read about load balancing, threading, and scaling in Node.js.
We invite you to visit the Node.js reference architecture repository on GitHub, where you will see the work we have done and future topics. To learn more about what Red Hat is up to on the Node.js front, check out our Node.js page.
Last updated: January 9, 2024