DEV Community: Athuliya P S

Debugging Financial Transactions in a Production ERP Application: Lessons from NestJS and PostgreSQL

Athuliya P S — Tue, 03 Nov 2026 03:41:04 +0000

Working on a financial module in an ERP application taught me that debugging is not simply about finding an error and changing a line of code. It requires understanding how different parts of an application communicate and how data moves through the system.

During my experience as a Full Stack Developer, I worked with ERP modules involving billing, inventory, CRM, and workflow approvals. One of the areas that helped me understand backend development better was investigating issues in financial transaction workflows.

Here are some lessons I learned from that experience.

1. Understand the Existing Workflow First

When a transaction-related issue occurs, it is tempting to immediately look at the code where the error appears.

However, understanding the complete workflow is more useful.

For example, a typical financial transaction may involve:

A frontend request containing transaction details.
A backend API receiving and validating the request.
Business logic processing the transaction.
Database operations storing or updating records.
A response returned to the frontend.

An issue at any stage can affect the final result.

I learned to understand the flow before deciding where the problem might be.

2. Trace the API Request

In a NestJS application, following the request through the backend helps narrow down the source of an issue.

A typical request flow looks like this:

Controller → Service → Database Layer → Response

The controller handles incoming requests, while the service contains the business logic.

When investigating an issue, some useful questions are:

Is the request reaching the correct endpoint?
Are the required fields being received?
Is the validation working as expected?
Is the service executing the expected logic?
Is the database operation completing successfully?

For example, if a payment request fails, I would check whether the request reaches the backend, whether the required transaction details are valid, and whether the service successfully completes the database operation.

This helps narrow down whether the issue is related to the API, business logic, or database interaction.

Breaking the workflow into smaller steps makes debugging more systematic.

3. Understand Database Relationships

Financial and ERP applications often involve multiple related entities.

For example, a billing workflow may involve customers, invoices, payments, and transaction records.

Understanding their relationships is important when investigating unexpected results.

Some useful checks include:

Whether the correct records are being retrieved.
Whether foreign-key relationships are configured correctly.
Whether the expected records exist in the database.
Whether an update is affecting the intended records.
Whether related data is being fetched correctly.

Working with PostgreSQL also helped me understand the importance of SQL queries when validating application behaviour.

4. Investigate ORM Behaviour

Working with TypeORM introduced me to another important part of backend debugging: understanding how the ORM interacts with the database.

An ORM makes database operations easier to manage, but developers still need to understand what happens behind those operations.

For example, it is useful to investigate:

Whether entity relationships are configured correctly.
Whether the expected query is being executed.
Whether records are being saved or updated correctly.
Whether the application is handling database errors appropriately.

Understanding both the application logic and the underlying database makes troubleshooting more effective.

5. Validate the Fix Before Considering the Issue Resolved

Finding a possible cause is only one part of debugging.

After making a change, the workflow needs to be validated again.

My validation approach includes:

Reproducing the original issue.
Identifying the step where the unexpected behaviour occurs.
Making the required code change.
Testing the affected API using Postman.
Checking the relevant database records.
Verifying that the expected workflow works correctly.

This is particularly important in financial workflows because an apparently small change can affect related operations.

6. What This Experience Taught Me

Working on production ERP applications helped me understand that effective debugging requires more than familiarity with a programming language.

A few lessons I took away:

Understand the business workflow before changing the code.
Trace API requests instead of making assumptions.
Understand database relationships and data consistency.
Use logs, API testing, and SQL queries to investigate issues.
Validate the complete workflow after fixing a defect.

Final Thoughts

Backend debugging becomes easier when the problem is approached systematically.

My experience with NestJS, TypeORM, and PostgreSQL helped me build a better understanding of how APIs, business logic, and databases work together in real applications.

I am continuing to strengthen these skills through practical development and by learning from the problems I encounter.

What is your usual approach when debugging an issue that involves both an API and a database?

I'd love to hear how other developers approach it.

Express.js vs NestJS: Understanding the Difference Between Flexibility and Structure

Athuliya P S — Mon, 02 Nov 2026 17:45:27 +0000

When building backend applications with Node.js, choosing the right framework can significantly influence how an application is developed, maintained, and scaled.

Two popular choices are Express.js and NestJS. Both help developers build server-side applications and REST APIs, but they approach application architecture differently.

I started exploring backend development with Express.js, where its simplicity and flexibility made it easy to get started. As I worked with more structured application requirements, I began appreciating what NestJS brings to backend development.

Let's understand their differences and when each framework makes sense.

1. Express.js: Flexibility and Simplicity

Express.js is a minimal and flexible web framework for Node.js.

It provides essential features such as routing, middleware, and request-response handling without enforcing a particular application architecture.

A basic Express application might look like this:

const express = require('express');

const app = express();

app.use(express.json());

app.get('/users', (req, res) => {
  res.json({ message: 'User list' });
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

Its simplicity makes it suitable for small APIs, prototypes, and applications where developers want complete control over their architecture.

However, as an application grows, developers need to establish their own conventions for organizing routes, business logic, database operations, and shared services.

Without consistent practices, maintaining a large codebase can become challenging.

2. NestJS: Structure and Modularity

NestJS is a Node.js framework built with TypeScript support and inspired by architectural concepts commonly found in enterprise application development.

Unlike Express, NestJS provides an established structure for organizing application components.

Some of its important concepts include:

Modules: Organize related functionality into separate sections of an application.
Controllers: Handle incoming requests and define application routes.
Providers and Services: Contain reusable business logic and application functionality.
Dependency Injection: Helps manage dependencies between different components, improving modularity and testability.

For example, a typical NestJS application may follow this structure:

src/
 ├── users/
 │    ├── users.module.ts
 │    ├── users.controller.ts
 │    ├── users.service.ts
 │    └── users.entity.ts
 │
 ├── app.module.ts
 └── main.ts

A simple NestJS controller might look like this:

import { Controller, Get } from '@nestjs/common';

@Controller('users')
export class UsersController {
  @Get()
  findAll() {
    return { message: 'User list' };
  }
}

Here, the @Controller() decorator defines the route prefix, while @Get() handles incoming GET requests.

This separation makes it easier to understand where different responsibilities belong.

When multiple developers work on the same application, having an established structure can also improve collaboration and consistency.

3. Express.js vs NestJS: Key Differences

Feature	Express.js	NestJS
Architecture	Minimal and flexible	Modular and structured
Language	JavaScript or TypeScript	TypeScript-first
Dependency Injection	Requires additional setup or libraries	Built-in
Routing	Direct route definitions	Controller-based
Code organization	Developer-defined	Established conventions
Learning curve	Relatively easy	Requires learning its concepts
Best suited for	Lightweight APIs and flexible applications	Structured and larger applications

One important distinction is that Express.js does not prevent developers from building scalable applications. It simply gives them more responsibility for designing and maintaining the architecture.

Similarly, NestJS provides structure, but developers still need to make good architectural decisions.

4. When Should You Choose Express.js?

Express.js can be a good choice when:

You are building a small REST API.
You need a lightweight framework.
You prefer defining your own application structure.
You want minimal initial configuration.
Your application has relatively straightforward requirements.

Its flexibility is one of its biggest advantages.

5. When Should You Choose NestJS?

NestJS can be a good choice when:

You are developing a larger backend application.
Your application has multiple business modules.
You work with a team of developers.
You want consistent coding conventions.
You need dependency injection and a structured testing approach.

Its modular architecture helps developers organize complex applications more consistently.

6. What I Learned From Working With Both

Moving from Express.js to NestJS changed how I approach backend development.

I began paying more attention to code organization, separation of concerns, and how different components interact within an application.

One of my biggest takeaways is that choosing a backend framework is not just about writing API endpoints.

It is also about thinking ahead:

How will the application grow?
How easily can another developer understand the code?
Where should business logic live?
How can different modules communicate?
How easy will it be to maintain and test the application?

Express.js helped me appreciate flexibility and simplicity.

NestJS helped me understand the importance of separation of concerns, modularity, and consistent architecture.

Neither framework is universally better. The right choice depends on the application's requirements, team structure, and long-term maintenance needs.

Final Thoughts

Express.js gives developers the freedom to design their own architecture, while NestJS provides conventions and built-in tools for creating structured applications.

For developers starting with Node.js, understanding Express.js can build a strong foundation. Exploring NestJS afterwards can introduce valuable architectural concepts.

Ultimately, good backend development is not about choosing the most popular framework. It is about choosing an approach that makes your application easier to build, understand, test, and maintain.

What do you prefer for backend development: the flexibility of Express.js or the structured architecture of NestJS?

I'd love to hear your thoughts!

DEV Community: Athuliya P S

Debugging Financial Transactions in a Production ERP Application: Lessons from NestJS and PostgreSQL

1. Understand the Existing Workflow First

2. Trace the API Request

3. Understand Database Relationships

4. Investigate ORM Behaviour

5. Validate the Fix Before Considering the Issue Resolved

6. What This Experience Taught Me

Final Thoughts

Further Reading

Express.js vs NestJS: Understanding the Difference Between Flexibility and Structure

1. Express.js: Flexibility and Simplicity

2. NestJS: Structure and Modularity

3. Express.js vs NestJS: Key Differences

4. When Should You Choose Express.js?

5. When Should You Choose NestJS?

6. What I Learned From Working With Both

Final Thoughts

Further Reading