Dependency Injection (DI) can be a controversial topic. It’s interpreted differently across stacks, sparks lengthy forum debates, and fuels “best practice” posts from LinkedIn gurus — often with no working code to back them up. With so many libraries and framework-specific implementations, confusion is common.

Common Problems in DI

• Circular dependencies.
• Multiple DI libraries used within the same project.
• Unmaintainable code due to excessive dependencies.
• Memory leaks caused by poor object lifecycle management.

Available Options

In the TypeScript/Node.js ecosystem, several DI libraries are available:

• Inversify
• typeDI
• tsyringe
• awilix

I chose Awilix because it aligns most closely with the principles Martin Fowler outlines in his article on Dependency Injection. Another reason I favor Awilix is its strong support for TypeScript and Node.js as first-class citizens — a philosophy that aligns with the goals of this series.

Preparing the Example for DI

In the previous article, we created a RestController capable of handling a basic method. We also integrated a dependency-free library to manage environment variables in a resilient way. We organized the project into two main folders: apps, which holds technology-specific code like REST or GraphQL APIs, and core, which contains the business logic.

Now, let’s create a NoteController responsible for managing the logic related to Notes. Inside src/core, create a features folder, and within it, a notes directory. We’re intentionally avoiding a flat structure where all controllers, services, and models live in the same place. This allows each feature to grow independently and integrate with external services at its own pace.

The note.dto.ts file has been moved from the RestControllers folder to features/notes, since DTOs belong in the core layer where the business logic resides.

Using Aliases with tsconfig-paths

We installed the tsconfig-paths library to simplify import statements and improve readability. Update tsconfig.json with these aliases:

1
{
2
  "compilerOptions": {
3
    "baseUrl": ".",
4
    "outDir": "./dist",
5
    ...
6
    "paths": {
7
     "src/*": ["src/*"],
8
     "@core/*": ["src/core/*"],
9
     "@restAPI/*": ["src/apps/restAPI/*"]
10
    }
11
  },
12
  ...
13
}

Now, create NoteController, which encapsulates the business logic.

1
import { NoteDto } from "@core/features/note/note.dto";
2

3
export class NoteController {
4
  public getNotes(): NoteDto[] {
5
    return [
6
      {
7
        id: 1,
8
        content: "Hello 1 - from controller",
9
      },
10
      {
11
        id: 2,
12
        content: "Hello 2 - from controller",
13
      },
14
    ];
15
  }
16
}

And update NoteRestController as follows:

1
import { Controller, Get } from "@nestjs/common";
2
import { ApiOkResponse } from "@nestjs/swagger";
3

4
import { NoteDto } from "./note.dto";
5
import { NoteDto } from "@core/features/note/note.dto";
6
import { NoteController } from "@core/features/note/noteController";
7

8
@Controller("notes")
9
export class NoteRestController {
10
 private noteController: NoteController;
11

12
 constructor() {
13
   this.noteController = new NoteController();
14
 }
15

16
  @Get()
17
  @ApiOkResponse({
18
    type: [NoteDto],
19
    description: "Get all notes",
20
  })
21
  public getNotes(): NoteDto[] {
22
   return [
23
     { id: 1, content: "Hello 1" },
24
     { id: 2, content: "Hello 2" },
25
   ];
26
   return this.noteController.getNotes();
27
  }
28
}

This decouples framework-specific logic (NestJS) from the business logic (pure TypeScript).

Run the REST API again:

1
npm run start:dev:restAPI

Visiting the Swagger docs and hitting the GET /notes endpoint, you’ll see the updated response.

The Problem DI Solves

In this setup, we’re manually instantiating NoteController. But what happens as dependencies grow — both in the controller and the API layer? You’ll end up with a tangled web of constructor calls, hard-to-trace bugs, and code that’s difficult to test or scale.

Installing & Configuring Awilix

Install the library:

1
npm i awilix

The core concept of Awilix is a container: a centralized object that manages your dependencies. This makes your code predictable, testable, and less prone to hidden errors like circular dependencies or undefined injections.

Creating the Container

By convention, define the container in a dedicated file. Here’s a minimal example with strict: true, which helps catch issues during transpilation.

1
import { NoteController } from "@core/features/note/noteController";
2
import { createContainer, asClass, InjectionMode } from "awilix";
3

4
export const container = createContainer({
5
  injectionMode: InjectionMode.CLASSIC,
6
  strict: true,
7
});
8

9
container.register({
10
  noteController: asClass(NoteController).singleton(),
11
});

Updating the NoteRestController

Now, inject the NoteController using Awilix:

1
import { Controller, Get } from "@nestjs/common";
2
import { ApiOkResponse } from "@nestjs/swagger";
3

4
import { NoteDto } from "@core/features/note/note.dto";
5
import { NoteController } from "@core/features/note/noteController";
6
import { container } from "@core/container/container";
7

8
@Controller("notes")
9
export class NoteRestController {
10
  private noteController: NoteController;
11

12
  constructor() {
13
   this.noteController = new NoteController();
14
   this.noteController = container.resolve("noteController");
15
  }
16

17
  @Get()
18
  @ApiOkResponse({
19
    type: [NoteDto],
20
    description: "Get all notes",
21
  })
22
  public getNotes(): NoteDto[] {
23
    return this.noteController.getNotes();
24
  }
25
}

When you restart the project, you won’t notice any visual changes — but under the hood, you’ve eliminated future headaches by standardizing how dependencies are handled.

Conclusion

With minimal changes, we’ve separated business logic from framework-specific concerns and prepared our app to grow cleanly. This structure allows us to scale confidently by adding services, persistence layers, and more — without coupling logic to implementation details.

In the next article, we’ll implement full CRUD (Create, Read, Update, Delete) operations for Notes with database integration.

Have you dealt with tangled dependencies or scaling challenges in your backend projects?
Share your experience, ask questions, or explore the GitHub repo and try the setup yourself.