DEV Community: Olo

Building an API in Node.js Without Dependencies

Olo — Mon, 19 May 2025 06:10:04 +0000

Looking at the progress Node.js has made in the past few years makes me think that many popular and widely used npm packages might soon be unnecessary or even deprecated. Most Node.js developers are familiar with packages like dotenv for working with .env files, node-fetch for making HTTP requests, and jest for testing.

These packages are awesome, but installing any new npm package in a project always adds some maintenance overhead. In some cases, that maintenance cost can become a real problem for organizations - especially with heavily distributed microservices. Building a backend or fullstack app with just pure Node.js might help with that, but is it really worth it?

Is it worth to build a REST API in pure Node.js without any dependencies ?

whole code mentioned in the article is here

We’re going to build an API that returns bitcoin rates. For the data source, we’ll use blockchain.com.

Endpoints:

/v1/bitcoin/rates - returns a list of bitcoin rates
/v1/bitcoin/rates/:currency - returns the exchange rate for a given currency

Repo setup with Typescript ❌

The Node.js team announced support for typescript files, also known as Type stripping. This lets us work with .ts files natively, so you get the benefits of static type checks. But you should keep in mind that this is just a soft layer. Node.js replaces TypeScript syntax with whitespaces at runtime, and doesn’t actually do any type checking. Also, .ts files can only use erasable TypeScript syntax, which means things like enums aren’t allowed (which might be for the best).

Routes handling ❌

To support different REST endpoints, you need to write a custom router that can trigger different route handlers for /v1/bitcoin/rates and /v1/bitcoin/rates/:currency. This takes a bit of playing around with regex:

 get(path: string, handler: RouteHandler): void {
      // Convert path parameters like :currency to named regex capture groups
      const patternString = path
        .replace(/\/:([^/]+)/g, "/(?<$1>[^/]+)")
        .replace(/\//g, "\\/");

      const pattern = new RegExp(`^${patternString}$`);
      routes.push({ method: "GET", pattern, handler, path });
    },

So that’s the first big downside of building a REST API without using packages like express.js - you have to build all the route handling yourself, plus add some support for middlewares.

HTTP communication with third-party services ✅
Sending HTTP requests to different APIs is much easier now, since you don’t need to install any extra packages. Node.js includes a browser-compatible version of fetch().

export async function fetchBitcoinRates(): Promise<BitcoinRates> {
  const response = await fetch(BITCOIN_TICKER_URL, {
    method: "GET",
    headers: {
      Accept: "application/json",
    },
  });

  if (!response.ok) {
    throw new Error(`HTTP error! Status: ${response.status}`);
  }

  return (await response.json()) as BitcoinRates;
}

Propagating request context ✅

Passing some kind of context down the request route can be a pain. Your functions always need to take that extra parameter, which was probably set up at request time in some middleware and added to the req object. For example:

export function createContextMiddleware() {
  return async (
    req: IncomingMessage,
    res: ServerResponse,
    next: () => Promise<void> | void,
  ) => {
    const user = await findUser(req.headers)
    const context: RequestContext = {
      traceId: generateTraceId(),
      timestamp: Date.now(),
      user,
    };

    res.setHeader("X-Trace-ID", context.traceId);
    req.context = context;
    next()
  };
}

And then every function in your controller, service, or repository will have to take that context or request as an argument to get metadata about the incoming request.

Luckily, this can be handled with Asynchronous context tracking. This lets you store data throughout the lifetime of a incoming request. You just need to call getStore() on the local storage object you created:

const myContext = asyncLocalStorage.getStore()

With this, you can easily build middleware that attaches caller metadata, and then reuse it anywhere else in your codebase.

import { AsyncLocalStorage } from "node:async_hooks";
import { IncomingMessage, ServerResponse } from "node:http";
import crypto from "node:crypto";

export interface RequestContext {
  traceId: string;
  timestamp: number;
}

export const asyncLocalStorage = new AsyncLocalStorage<RequestContext>();

function generateTraceId(): string {
  return crypto.randomUUID();
}

export function createContextMiddleware() {
  return async (
    req: IncomingMessage,
    res: ServerResponse,
    next: () => Promise<void> | void,
  ) => {
    const context: RequestContext = {
      traceId: generateTraceId(),
      timestamp: Date.now(),
    };

    res.setHeader("X-Trace-ID", context.traceId);

    await asyncLocalStorage.run(context, async () => {
      await next();
    });
  };
}

export function getContext(): RequestContext {
  return asyncLocalStorage.getStore()!;
}

Tests with Node test runner ✅

Since version 20, the Node test runner is available as a stable module. This means you can safely use it for testing. The syntax that Node provides is pretty similar to Jest. You check your function results with assert, and test suites are organized with describe, test, beforeEach... aliases, just like in Jest. Here’s a sample test for bitcoinService.ts:

describe("fetchBitcoinRates", () => {
    test("should return Bitcoin rates", async (ctx) => {
      const mockResponse = {
        USD: {
          "15m": 10000,
          last: 10000,
          buy: 10000,
          sell: 10000,
          symbol: "$",
        },
      };

      ctx.mock.method(global, "fetch", () => {
        return Promise.resolve({
          ok: true,
          status: 200,
          json: () => Promise.resolve(mockResponse),
        });
      });

      const rates = await fetchBitcoinRates();
      assert.deepEqual(rates, mockResponse);
    });
  });

The only problem with the current Node test runner is that mocking a function or object from a different module is still only an experimental feature. This was added to the Node ecosystem in the middle of 2024 by cjihrig, so hopefully it will become the official way to mock things soon.

This can be an issue if you want to test your code in isolation from the rest of your codebase.

Env file support ✅

This is a simple feature that makes life a lot easier for developers. Node now has native support for loading environment variables from a .env file. Just add the --env-file option to your node command, and Node will automatically load environment variables from the file you specify.

In-memory cache with SQLite ✅

Node supports using an in-memory database with SQL to access your data. This might seem kind of useless at first, but there are actually a few good use-cases for it. Here’s a sample of how I cached bitcoin rates in memory:

export function findAllBitcoinRates(): CurrencyRate[] {
  const context = getContext();
  const currentTimestamp = context.timestamp;

  const expirationTimestamp = currentTimestamp - BITCOIN_RATE_TTL_MS;
  const query = database.prepare(
    `SELECT symbol, last, buy, sell, "15m", timestamp FROM ${BITCOIN_RATES_TABLE} WHERE timestamp >= ?`,
  );

  // Can't pass the expected type to the query
  const result = query.all(expirationTimestamp);
  if (result.length === 0) {
    return [];
  }

  return result.map((row) => row as unknown as CurrencyRate);
}

The only thing missing is being able to pass a generic type to query.all so I don’t have to force TypeScript types with as unknown as CurrencyRate.

Would I build a production-grade API in pure Node.js without any npm packages?

The need to build custom route handling and the loose TypeScript support are the main reasons not to skip libraries completely.

Express.js already comes with a bunch of great features and is supported by the OpenJS Foundation, so using it with TypeScript is a really good way to get started. It’s simple, and will be easy to maintain in the future.

Also, it would be tough to avoid libraries that are clients or drivers, for example mongodb driver. So I’d always try to keep my package.json dependencies as minimal as possible, and only add new packages when really needed - someone will have to update them in the future!

Nest.js integration tests

Olo — Sun, 10 Oct 2021 15:46:31 +0000

Nest.js integration tests

TDD is really hype shortcut, but it's hard to follow this approach with only unit tests. The answer for this problem are integration tests .
Here I'll present you how to setup those tests with Nest.js framework and PostgresSQL database. Those tests will cover whole API request lifecycle, from controllers, services, dtos, repositories, database entities and much more...

Github

Complex example https://github.com/devsilk-software/nestjs-integration-tests

API setup

Basic endpoint which creates Dog and saves it in Postgres database:

Controller

Our entry-point which will listen for POST requests on /dogs path

import { Body, Controller, Post } from '@nestjs/common';
import { DogsService } from './dogs.service';
import { CreateDogDto } from './dto/create-dog.dto';

@Controller('dogs')
export class DogsController {
  constructor(private readonly dogsService: DogsService) {}

  @Post()
  async create(@Body() createDogDto: CreateDogDto) {
    const created = await this.dogsService.create(createDogDto);

    return {
      id: created.id,
    };
  }
}

Service

This is the class which has injected connection to Postgres database and executes save query

import { Injectable } from '@nestjs/common';
import { Connection } from 'typeorm';
import { DogPostgresEntity } from './database/dog.entity';
import { CreateDogDto } from './dto/create-dog.dto';

@Injectable()
export class DogsService {
  constructor(private connection: Connection) {}

  async create(createDogDto: CreateDogDto) {
    return this.connection.getRepository(DogPostgresEntity).save(createDogDto);
  }
}

Postgres entity

Definition of dog table in Postgres database

import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class DogPostgresEntity {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ type: 'varchar' })
  name: string;

  @Column({ type: 'int' })
  age: number;

  @Column({ type: 'varchar' })
  breed: string;
}

`dogs.module` imported in `app.module`

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { DogPostgresEntity } from './database/dog.entity';
import { DogsController } from './dogs.controller';
import { DogsService } from './dogs.service';

@Module({
  imports: [TypeOrmModule.forFeature([DogPostgresEntity])],
  controllers: [DogsController],
  providers: [DogsService],
})
export class DogsModule {}

Test module setup

The most important part, where we'll cover all utils necessary for start writing integration tests for our Dog endpoint

Setup Postgres with Docker Compose

Create docker-compose.int.test.yml at the root directory

version: '3.3'

services:
  int-postgres:
    container_name: int-postgres
    image: postgres
    ports:
      - 5432:5432
    env_file:
      - .int.env

Create .int.env file at the root directory where we will store database variables

POSTGRES_HOST=localhost
POSTGRES_USER=root
POSTGRES_PASSWORD=root
POSTGRES_DB=test-db
POSTGRES_PORT=5432

Create Makefile at the root directory with useful command

start-test-db:
    docker-compose -f docker-compose.int.test.yml up -d

Run make start-test-db command

$ make start-test-db

Now our testing database is running on port 5432, to use our tests we need to create some helpful utils

Setup test module

Create test.module.ts in test directory which will be used in every test file

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { TypeOrmModule } from '@nestjs/typeorm';

@Module({
  imports: [
    ConfigModule.forRoot({
      envFilePath: '.int.env',
      isGlobal: true,
    }),
    TypeOrmModule.forRoot({
      type: 'postgres',
      host: process.env.POSTGRES_HOST,
      port: +process.env.POSTGRES_PORT,
      username: process.env.POSTGRES_USER,
      password: process.env.POSTGRES_PASSWORD,
      database: process.env.POSTGRES_DB,
      autoLoadEntities: true,
      entities: [process.cwd() + '/**/*.entity{.ts,.js}'],
      synchronize: true,
    }),
  ],
})
export class TestModule {}

As you can see here we are referring to our .int.env just to get values used for setting up connection with Postgres

Create create-test-app.util.ts in test/utils directory

import { DynamicModule, ForwardReference, Type } from '@nestjs/common';
import { NestExpressApplication } from '@nestjs/platform-express';
import { Test } from '@nestjs/testing';
import { Connection } from 'typeorm';
import { TestModule } from '../test.module';

type Imports = Array<
  Type<any> | DynamicModule | Promise<DynamicModule> | ForwardReference
>;

interface TestApp {
  connection: Connection;
  app: NestExpressApplication;
}

export async function createTestApp(imports: Imports): Promise<TestApp> {
  const testingModule = await Test.createTestingModule({
    imports: [TestModule, ...imports],
  }).compile();

  const app = await testingModule
    .createNestApplication<NestExpressApplication>()
    .init();

  const connection = testingModule.get<Connection>(Connection);
  return {
    app,
    connection,
  };
}

What is happening here ? We are creating testingModule which is combination of TestModule created in previous step and modules passed via function arguments, based on that module we can create our NestExpressApplication and get connection to Postgres database.

Let's create last two utils which will be used in tests:

test/utils/clear-all-tables.ts

import { Connection } from 'typeorm';

export const clearAllTables = async (connection: Connection): Promise<void> => {
  await Promise.all(
    connection.entityMetadatas.map(({ name }) => {
      return connection.createQueryBuilder().delete().from(name).execute();
    }),
  );
};

This one will be triggered after every test providing to have database in the same state before every test case

test/utils/make-request.ts

import { INestApplication } from '@nestjs/common';
import * as request from 'supertest';

export function makeRequest(app: INestApplication) {
  return request(app.getHttpServer());
}

This one will be used to make HTTP request to our API in tests

Let's create our first integration test

import { HttpStatus } from '@nestjs/common';
import { NestExpressApplication } from '@nestjs/platform-express';
import { Connection } from 'typeorm';
import { clearAllTables } from '../../test/utils/clear-all-tables.util';
import { createTestApp } from '../../test/utils/create-test-app.util';
import { DogsModule } from './dogs.module';

describe('Dogs module', () => {
  let app: NestExpressApplication;
  let connection: Connection;

  beforeAll(async () => {
    const testApp = await createTestApp([DogsModule]);

    connection = testApp.connection;
    app = testApp.app;
  });

  afterEach(async () => {
    await clearAllTables(connection);
  });

  afterAll(async () => {
    await connection.close();
    await app.close();
  });
});

What is happening here ?
beforeAll - we are creating our application with createTestApp which returns connection to database and express application

afterEach - after every it we want to have the same state of database, so our tables needs to be empty

afterAll - we need to remember to close connection to database and close express app

Now we can add test scenarios for success respons in POST /dogs endpoint

describe('Dogs module', () => {
  let app: NestExpressApplication;
  let connection: Connection;

  beforeAll(async () => {
    const testApp = await createTestApp([DogsModule]);

    connection = testApp.connection;
    app = testApp.app;
  });

  afterEach(async () => {
    await clearAllTables(connection);
  });

  afterAll(async () => {
    await connection.close();
    await app.close();
  });

  describe('POST /dogs', () => {
    describe('201', () => {
      it('should create dog and return id', async () => {
        const response = await makeRequest(app).post('/dogs').send({
          name: 'Dingo',
          age: 3,
          breed: 'Beagle',
        });

        expect(response.status).toBe(HttpStatus.CREATED);
        expect(response.body.id).toBeDefined();
      });

      it('should create dog and save it to db', async () => {
        const given: CreateDogDto = {
          name: 'Dingo',
          age: 3,
          breed: 'Beagle',
        };

        const response = await makeRequest(app).post('/dogs').send(given);

        expect(response.status).toBe(HttpStatus.CREATED);
        expect(response.body.id).toBeDefined();

        // check if saved dog in database has same properties sent via POST request
        const found = await connection
          .getRepository(DogPostgresEntity)
          .findOne(response.body.id);

        expect(found).toMatchObject({
          id: response.body.id,
          name: given.name,
          age: given.age,
          breed: given.breed,
        });
      });
    });
  });
});

As you can see in every it we are making HTTP call to our API and then we can check the most important stuff - database changes and API responses. Thanks to such a approach we can test more complex endpoints which refers with multiple tables.

For VSCode users

If you don't want to run all test cases at once you can install Jest Runner. Thanks to that it's really easy to debug every test case separately

DEV Community: Olo

Building an API in Node.js Without Dependencies

Is it worth to build a REST API in pure Node.js without any dependencies ?

Repo setup with Typescript ❌

Would I build a production-grade API in pure Node.js without any npm packages?

Nest.js integration tests

Nest.js integration tests

Github

API setup

Controller

Service

Postgres entity

dogs.module imported in app.module

Test module setup

Setup Postgres with Docker Compose

Setup test module

Let's create our first integration test

For VSCode users

`dogs.module` imported in `app.module`