DEV Community: vedant kale

Stop Writing try/catch in Every Controller

vedant kale — Tue, 14 Jul 2026 12:28:30 +0000

When I first started building APIs with Express.js, every async controller looked the same. I would write a try block, perform some database operations, and then write a catch block that called next(error).

It worked, so I copied the same pattern into every controller. One controller became ten. Ten became fifty. Eventually, I realized that half of my controller code wasn't actually business logic, it was just repetitive error handling.

That's when I discovered the Async Handler pattern.

The Problem

A typical Express controller often looks like this:

export const getUser = async (req, res, next) => {
  try {
    const user = await User.findById(req.params.id);

    if (!user) {
      throw new Error("User not found");
    }

    res.json(user);
  } catch (error) {
    next(error);
  }
};

There's nothing wrong with this code.

The problem is that every async controller ends up looking exactly the same.

Every file contains:

try, catch and next(error)

over and over again. Besides being repetitive, it's also easy to forget. Miss one try-catch block, and Express won't automatically catch errors thrown inside async functions.

What Is an Async Handler?

An async handler is a small wrapper function that automatically catches errors from async controllers. Instead of every controller handling its own errors, the wrapper does it for you.

A Simple Analogy

Imagine an office where every employee has to stop working whenever someone rings the front door. Besides doing their own job, they also have to greet every visitor. This quickly becomes repetitive and inefficient. Instead, the company hires a receptionist to handle every visitor. Now the employees can focus on their actual work while the receptionist takes care of the door. An async handler works the same way. Controllers focus on handling requests, while the async handler catches errors and passes them to Express's error handler.

Without an Async Handler

export const createUser = async (req, res, next) => {
  try {
    const user = await User.create(req.body);

    res.status(201).json(user);
  } catch (error) {
    next(error);
  }
};

It looks fine. Now imagine writing this in 40 different controllers. Most of the code ends up being identical.

With an Async Handler

First, create the wrapper.

export const asyncHandler = (fn) => {
  return (req, res, next) => {
    Promise.resolve(fn(req, res, next)).catch(next);
  };
};

Now the controller becomes:

export const createUser = asyncHandler(async (req, res) => {
  const user = await User.create(req.body);

  res.status(201).json(user);
});

Notice how the controller only contains its actual responsibility. There is no try-catch. If anything throws an error, the async handler catches it automatically and forwards it to Express.

How It Works

The wrapper accepts your controller function.

asyncHandler(fn)

When Express executes it:

Your controller runs.
If everything succeeds, Express sends the response.
If an error is thrown or a Promise rejects, .catch(next) is called.
Express forwards the error to your global error middleware.

Every controller gets consistent error handling without repeating code.

Common Mistakes to Avoid

1. Wrapping synchronous controllers

Async handlers are designed for asynchronous functions. Normal synchronous routes usually don't need them.

2. Using try-catch inside every wrapped controller

If you're already using an async handler, most controllers don't need their own try-catch blocks. Only use one when you want to recover from a specific error.

3. Forgetting a global error middleware

An async handler forwards errors; it doesn't send responses. Without a global error handler, those errors still won't be returned properly. So, create the global error middleware first.

4. Mixing business logic with error formatting

Controllers should call services. The global error middleware should decide how errors are returned. Keep those responsibilities separate.

Conclusion

An async handler doesn't make your application faster. It makes your code cleaner.

Instead of writing the same try-catch block in every controller, you write the wrapper once and reuse it everywhere. The result is smaller controllers, consistent error handling, and code that's much easier to maintain.

The lesson is simple:

Don't repeat error handling in every controller. Write it once, wrap your controllers, and let Express handle the rest.

Why Your Controllers Become 600+ Lines Long (And How a Service Layer Fixes It)

vedant kale — Sun, 14 Jun 2026 19:47:20 +0000

When I first started building APIs with Express.js, I made the same mistake many beginners make:

"If it works, just put it in the controller."

So that's exactly what I did.

Database queries? Controller.
Validation? Controller.
Business logic? Controller.
Error handling? Controller. Everything lived in the same file.

At first, this wasn't a problem. The project was small, the controllers were short, and finding bugs was easy. But as the application grew, so did the controllers. A controller that started with 20 lines slowly became 100 lines. Then 300. Then 600+ lines.

At that point, reading the code became difficult. Finding bugs took longer, testing became harder, and making changes felt risky because every responsibility was mixed together in the same file. That's when I discovered the Service Layer pattern.

What Is a Service Layer?

A service layer is responsible for handling your application's business logic.

Think of it this way:

Routes decide which endpoint should be called.
Controllers handle HTTP requests and responses.
Services handle the actual business logic.

Business logic includes things such as:

Database queries
Validation rules
Permission checks
User-related operations
Payment processing
Business rules specific to your application

Instead of putting all of this inside a controller, you move it into dedicated service files. This keeps your controllers small and focused while making your business logic easier to reuse, test, and maintain.

A Simple Analogy

A controller is like a waiter in a restaurant. The waiter takes your order and brings your food to the table. However, the waiter doesn't cook the food. The kitchen does.

In this analogy:

The controller is the waiter.
The service layer is the kitchen.

The controller receives the request, passes it to the service layer, and returns the result to the client. The actual work happens inside the service.

Without a Service Layer

A typical controller often starts looking like this:

export const getUser = async (req, res) => {
  const id = req.params.id;

  const user = await User.findById(id);

  if (!user) {
    return res.status(404).json({
      message: "User not found",
    });
  }

  return res.json(user);
};

At first glance, this seems fine.

The problem begins when more logic gets added:

Validation
Authorization checks
Database operations
Error handling
Business rules

Eventually, the controller becomes responsible for everything.

With a Service Layer

Controller:

export const getUser = async (req, res) => {
  try {
    const user = await getUserById(req.params.id);

    return res.json(user);
  } catch (error) {
    return res.status(404).json({
      message: error.message,
    });
  }
};

Service:

export const getUserById = async (id) => {
  const user = await User.findById(id);

  if (!user) {
    throw new Error("User not found");
  }

  return user;
};

Notice the difference.

The controller no longer knows how users are fetched. Its only responsibility is handling the request and returning a response. The service layer contains the business logic required to retrieve a user. This separation becomes increasingly valuable as your application grows.

Common Mistakes to Avoid

1. Putting all business logic inside controllers

Controllers should not become the place where everything happens. Their primary responsibility is handling the request-response cycle.

2. Turning services into another controller

Moving code to a service file is not enough. Services should contain business logic, not HTTP-specific logic such as req, res, or status codes.

3. Ignoring error handling

Service functions can throw errors. Controllers should properly handle those errors and return appropriate responses.

4. Creating services too early for tiny projects

Not every project needs a large architecture from day one. For small applications, simple controllers may be enough. As complexity grows, introducing services becomes more valuable.

Conclusion

The biggest lesson is simple:
Controllers handle requests and responses. Services handle business logic.

Keeping those responsibilities separate makes your code easier to read, test, maintain, and scale as your application grows.

The goal isn't to follow architecture patterns for the sake of it. The goal is to prevent your controllers from becoming 600-line files that nobody enjoys maintaining.

Fixing Circular Dependency Issues in My Node.js + Express API Project

vedant kale — Thu, 23 Apr 2026 11:41:13 +0000

While working on a Node.js + Express backend project, I ran into a frustrating issue caused by circular dependencies. It wasn’t immediately obvious, but it led to unpredictable runtime behavior and made debugging unnecessarily difficult.

I was using barrel imports (index.ts files) inside the same module.
At first, this felt clean and organized. But under the hood, it introduced hidden circular dependencies.

Example

// fileA.ts
import { funcB } from "./index";

// fileB.ts
import { funcC } from "./index";

// fileC.ts
import { funcA } from "./index";

// index.ts (barrel file)
export * from "./fileA";
export * from "./fileB";
export * from "./fileC";

The problem is, this creates a dependency loop:

A → B → C → A

Because of how Node.js module loading works, some modules are not fully initialized when they are imported. This results in: undefined values, Hard-to-trace bugs

The fix

To Fix this, I refactored the structure to remove circular dependencies completely.

1. Removed barrel imports inside the same module, Instead of importing from `./index`, I switched to direct imports.

// fileA.ts
import { funcB } from "./fileB";

2. Used relative imports for internal dependencies

3. Kept barrel files only for external usage, Barrel files are still useful. just not internally in the same module/folder.

// modules/user/index.ts
export * from "./user.controller";
export * from "./user.service";
export * from "./user.routes";

// outside the module
import { createUser } from "@/modules/user";

Conclusion

No more circular dependency issues, Cleaner and more predictable module structure, Easier debugging and maintenance

Barrel imports are helpful for simplifying external imports, but using them inside the same module can introduce hidden circular dependencies.

Use direct relative imports internally , Use barrel files only for external access

This small change can save hours of debugging and make your codebase significantly more stable.

DEV Community: vedant kale

Stop Writing try/catch in Every Controller

The Problem

What Is an Async Handler?

A Simple Analogy

Without an Async Handler

With an Async Handler

How It Works

Common Mistakes to Avoid

1. Wrapping synchronous controllers

2. Using try-catch inside every wrapped controller

3. Forgetting a global error middleware

4. Mixing business logic with error formatting

Conclusion

Why Your Controllers Become 600+ Lines Long (And How a Service Layer Fixes It)

What Is a Service Layer?

A Simple Analogy

Without a Service Layer

With a Service Layer

Common Mistakes to Avoid

1. Putting all business logic inside controllers

2. Turning services into another controller

3. Ignoring error handling

4. Creating services too early for tiny projects

Conclusion

Fixing Circular Dependency Issues in My Node.js + Express API Project

Example

The fix

1. Removed barrel imports inside the same module, Instead of importing from ./index, I switched to direct imports.

2. Used relative imports for internal dependencies

3. Kept barrel files only for external usage, Barrel files are still useful. just not internally in the same module/folder.

Conclusion

1. Removed barrel imports inside the same module, Instead of importing from `./index`, I switched to direct imports.