DEV Community

Manoj Khatri
Manoj Khatri

Posted on

The Everyday Backend Engineer: Step 4 — Dependency Injection

#node #javascript #webdev #softwaredevelopment

Welcome back to The Everyday Backend Engineer: Practical Design Patterns. We have successfully wrapped up our Creational Patterns. Today, we step firmly into Category 2: Structural Patterns by exploring the absolute backbone of clean architecture and testability: Dependency Injection (DI).

Let’s dismantle the bad habits of hardcoding modules and look at how to inject dependencies like a pro.

🔴 The Problem: Hardcoded Coupling (The Testing Wall)

Imagine you are writing a standard business logic workflow inside a UserService. To register a user, this service needs to talk to a database client to save the records.

A very common, instinctive approach is to import and initialize the database connection directly inside the service file:

// ❌ Bad Practice: Tight coupling via inline instantiation/imports
const db = require('../config/database'); // Hardcoded dependency

class UserService {
    async createUser(userData) {
        if (!userData.email) throw new Error("Email is required");

        // Directly invoking the hardcoded database instance
        return await db.query("INSERT INTO users ...", [userData.email]);
    }
}

module.exports = UserService;
Enter fullscreen mode Exit fullscreen mode

Why does this kill your codebase?

Your UserService is now tightly coupled to that specific database configuration file. This presents two massive problems:

  1. Zero Testability: If you want to write a Unit Test for the createUser logic, you cannot isolate it. Running the test will actually hit your live or local database. You cannot cleanly mock or fake the database layer.
  2. Rigid Architecture: If you decide to switch your database client or swap out PostgreSQL for MongoDB in the future, you have to surgically alter every single service file that hardcoded this import.

🟢 The Solution: "Don't Create Tools, Receive Them"

Instead of letting a class build or import its own tools, the class should explicitly declare what tools it needs via its constructor. The responsibility of providing those tools is moved entirely outward to the entry point of the application.

This simple shift in responsibility is called Inversion of Control (IoC), and passing those external tools into the constructor is Dependency Injection (DI).

🍳 The Real-World Analogy: "The Restaurant Chef"

Think of a professional Restaurant Chef. When the chef walks into the kitchen to cook dinner, they do not pause, grab bricks, weld steel pipes, and build the cooking stove themselves. The cooking stove is already installed and sitting on the counter (Injected). The chef simply receives the tool and focuses entirely on their core job: cooking the meal.

💻 The Clean Node.js Implementation

Let’s rewrite our service using structural Dependency Injection.

First, we define our service class to cleanly receive its dependencies rather than creating them:

// services/userService.js
class UserService {
    // 🎯 The Dependency is cleanly injected via the constructor
    constructor(databaseClient) {
        this.db = databaseClient; 
    }

    async createUser(userData) {
        if (!userData.email) throw new Error("Email is required");

        // Use the injected tool seamlessly
        return await this.db.query("INSERT INTO users (email) VALUES ($1) RETURNING *", [userData.email]);
    }
}

module.exports = UserService;
Enter fullscreen mode Exit fullscreen mode

Next, we wires things up cleanly at the entry point or composition root of our application (e.g., app.js or server.js):

// app.js (The Composition Root)
const express = require('express');
const dbSingletonInstance = require('./config/database'); // Outward tool
const UserService = require('./services/userService');

const app = express();
app.use(express.json());

// 🔌 Actively Injecting the Database Tool into the Service
const userService = new UserService(dbSingletonInstance);

// Route Handler
app.post('/users', async (req, res) => {
    try {
        const user = await userService.createUser(req.body);
        res.status(201).json(user);
    } catch (err) {
        res.status(400).json({ error: err.message });
    }
});
Enter fullscreen mode Exit fullscreen mode

🧪 Why This Changes Everything: Flawless Mocking

Because UserService accepts any object that implements a .query() method, writing a blazing-fast unit test without touching a real database becomes incredibly simple:

// tests/userService.test.js
const UserService = require('../services/userService');

test('should cleanly create a user without touching a real DB', async () => {
    // 1. Create a lightweight mock database object (A Fake Stove)
    const mockDb = {
        query: jest.fn().mockResolvedValue({ id: 1, email: 'test@example.com' })
    };

    // 2. Inject the fake DB into the service
    const userService = new UserService(mockDb);
    const result = await userService.createUser({ email: 'test@example.com' });

    // 3. Assertions run instantly in isolation
    expect(result.id).toBe(1);
    expect(mockDb.query).toHaveBeenCalledTimes(1);
});
Enter fullscreen mode Exit fullscreen mode

🧠 Code Smell Test: When should you use DI?

Look out for this structural layout during development:

  • The Smell: Inside a service or controller class file, you spot direct inline object initializations (new EmailClient()) or global database instances imported and invoked deep inside internal methods.
  • The Fix: Move those external instances into the file's constructor(dependency) parameters, and pass them in from the application's bootfile.

That wraps up Step 4! Your service layers are now beautifully decoupled and completely ready for unit testing.

Up next in our structural exploration is Step 5: The Decorator Pattern, where we will look at how to dynamically layer extra features onto existing objects without altering their original source code.

Do you manually wire your dependencies in Node.js via constructors, or do you use an automated IoC container library like InversifyJS or Awilix? Let's discuss in the comments below!

Top comments (0)