DEV Community: Vadim Orekhov

DI Benchmark: Vanilla, RegistryComposer, typed-inject, tsyringe, inversify, nest.js

Vadim Orekhov — Sat, 25 Feb 2023 15:43:00 +0000

In the previous articles, I've introduced a framework-less and clean way to perform Dependency Injection in TypeScript.

The approach has multiple pros such as type-safety, zero-cost overhead, and others.

However, the one missing piece I had was - benchmarking.

In this article I'm going to compare the performance of the following DI approaches/libs:

Application

For the test I'm defining the following application dependency tree:

The implementation of the functions and services does not really matter for our tests, since we only test the dependency resolution performance. So the most important thing here is the depth of the graph.

In the application to resolve findUserReviewedProducts the server needs to resolve all findUserByUsername, findUserReviews, findProductById, and also their dependencies: UserStore, ProductStore, and UserReviewStore, etc.

So, to resolve findUserReviewedProducts - 9 other dependencies need to be resolved.

NOTE: For fare comparison, all dependencies' lifetimes are Singleton, so once one is resolved, it can be cached for the whole application lifetime.

Competitors

Vanilla TypeScript

Typesafe implicit allocation of the dependency graph.

So the code looks like this:

// ...
const productStore = new MysqlProductStore(getMysqlClient);
const userStore = new RedisUserStore(getRedisClient);
const userReviewStore = new DynamodbUserReviewStore(getDynamodbClient);

const { findProductById } = new ImplFindProductById(productStore);
const { findUserByUsername } = new ImplFindUserByUsername(userStore);
const { findUserReviews } = new ImplFindUserReviews(userReviewStore);

const { findUserReviewedProducts } = new ImplFindUserReviewedProducts(
  findUserByUsername,
  findUserReviews,
  findProductById
);

return Object.freeze({
  getMysqlClient,
  getRedisClient,
  getDynamodbClient,
  findProductById,
  productStore,
  userStore,
  userReviewStore,
  findUserByUsername,
  findUserReviews,
  findUserReviewedProducts,
});

NOTE: I'm using Vanilla TypeScript as a baseline for all the benchmarking since it's the most performant solution.

Registry Composer

Typesafe dependency injection approach, that does not require to use of any libraries. Very similar to vanilla TS, but the main benefit - it is helping to organize the registration complexity.

new RegistryComposer()
  .add(implGetMysqlClient())
  .add(implGetRedisClient())
  .add(implGetDynamodbClient())
  .add(mysqlProductStore())
  .add(redisUserStore())
  .add(dynamodbUserReviewStore())
  .add(implFindProductById())
  .add(implFindUserByUsername())
  .add(implFindUserReviews())
  .add(implFindUserReviewedProducts())
  .compose();

typed-inject

Typesafe dependency injection framework for TypeScript. Conceptually it's very similar to Registry Composer except, it requires adding specific public static inject field to every class. Registration of functions is also not very pretty.

createInjector()
  // ...
  .provideClass("ProductStore", DecoratedMysqlProductStore)
  .provideClass("UserReviewStore", DecoratedDynamodbUserReviewStore)
  .provideClass("UserStore", DecoratedRedisUserStore)
  .provideClass("DecoratedImplFindProductById", DecoratedImplFindProductById)
  .provideFactory(
    "FindProductById",
    provideFn(["DecoratedImplFindProductById"], "findProductById")
  )
  .provideClass(
    "DecoratedImplFindUserByUsername",
    DecoratedImplFindUserByUsername
  );
// ...

tsyringe

Lightweight dependency injection container for TypeScript. The container is decorator-driven and not typesafe.

// ...

container.register("ProductStore", {
  useClass: DecoratedMysqlProductStore,
});

container.register("UserReviewStore", {
  useClass: DecoratedDynamodbUserReviewStore,
});

container.register("UserStore", {
  useClass: DecoratedRedisUserStore,
});

// ...

inversify

Another popular decorator-driven and not typesafe dependency injection container for TypeScript.

const container = new Container({
  defaultScope: "Singleton",
});

// ...
container.bind("ProductStore").to(DecoratedMysqlProductStore);
container.bind("UserReviewStore").to(DecoratedDynamodbUserReviewStore);
container.bind("UserStore").to(DecoratedRedisUserStore);
// ...

nest.js

Unlike others, nest.js is not just a DI library, it's a complete framework for building backend services. The DI system is very similar to Angular Modules.

@Module({
  providers: [
    DecoratedImplFindProductById,
    DecoratedImplFindUserByUsername,
    DecoratedImplFindUserReviewedProducts,
    DecoratedImplFindUserReviews,
    // ...
    {
      provide: "FindUserReviews",
      useFactory: ({ findUserReviews }: DecoratedImplFindUserReviews) => {
        return findUserReviews;
      },
      inject: [DecoratedImplFindUserReviews],
    },
    {
      provide: "ProductStore",
      useClass: DecoratedMysqlProductStore,
    },
    {
      provide: "UserReviewStore",
      useClass: DecoratedDynamodbUserReviewStore,
    },
    {
      provide: "UserStore",
      useClass: DecoratedRedisUserStore,
    },
    // ...
  ],
})
export class RootModule {}

NOTE: nest.js is a little out of scope since it doesn't expose it's DI container explicitly. But I've decided to test it as well since it's a very popular solution.

Benchmark Suites

For the benchmarking, I'm using the benchmark.js library with the default config.

There are 3 different benchmarks I'm performing:

Cold Start

The Cold Start suite covers the case when you just start an application. To do so, we need to skip caching when we start each test. It's achieved by using a helper function requireUncached.

function requireUncached(module: string) {
  delete require.cache[require.resolve(module)];
  return require(module);
}

For example for inversify for every test, I do: Similarly, for nestjs:

requireUncached("reflect-metadata");
requireUncached("@nestjs/core");
requireUncached("@nestjs/common");

Resolution

This suite verifies the performance of service resolution only. Meaning, the cold start happens on the test startup and does not affect the metrics.

For example, the code for the tsyringe looks like this:

container.resolve("FindUserReviewedProducts");

Cold Start + Resolution

The last suite is a combination of both: the cold start and resolution.

requireUncached("reflect-metadata");
requireUncached("inversify");

...

createContainer().get("FindUserReviewedProducts");

Scenario Test Cases

Each scenario contains the following test cases:

vanilla - a test case for a state object created by implicit allocation
registry-composer - a test case for a state object created by using RegistryComposer
typed-inject - a test case for a DI container created by using typed-inject library
tsyringe - a test case for a DI container created by using tsyringe library
inversify - a test case for a DI container created by using inversify library
nest - a test case for a DI container created by using nest.js library
tsyringe#frozen - a test case for a state object created from a DI container created by using tsyringe library
inversify#frozen - a test case for a state object created from a DI container created by using inversify library

Benchmarking

Benchmarking / Cold Start

What we can see from the chart: the transpile-time solutions are 3x faster than the runtime containers.

NOTE: even transpile-time solutions are 3x times faster, it does not mean your app will start 3x times faster, since we only compare DI framework timing, excluding any extra dependency your app might have.

Benchmarking / Resolution

Since benchmarking all transpile-time and frozen solutions is accessing a field by name, it's very fast. We can see that all the solutions can perform ~950M op/sec. While runtime container solutions perform in the range of 1M-6M op/sec, which is 150x times slower.

Benchmarking / Cold Start + Resolution

Similarly to just the Cold Start test, the transpile-time solutions are 3x faster than the runtime containers.

Conclusion

The results I got are pretty obvious. The runtime container adds overhead, compared to transpile-time solutions. It's especially clear for Resolution tests since the runtime is 150x times different. The runtime containers are less performant and not typesafe, but provide an easier way to manage services lifetimes. While the transpile-time solutions are typesafe, very fast, and make the application code framework agnostic, but require more care at the code design stage (especially for the scope lifetime dependencies). At the end of the day, it's up to you what solution to use, since each has its pros and cons.

A full example source code can be found here

Using DataLoader with AsyncLocalStorage over Fastify/GraphQL Yoga | Pure DI in TypeScript Node.js

Vadim Orekhov — Fri, 10 Feb 2023 02:07:29 +0000

In the previous tutorial, I've implemented GraphQL Server using GraphQL Yoga.
Today, I'm going to extend our service by using DataLoader.

I will use the repo as starting point.

DataLoader

GraphQL gives us the ability to combine multiple queries into one request like this:

query {
  order0: order(id: "order-0") {
    id
  }

  order1: order(id: "order-1") {
    id
  }

  order2: order(id: "order-1") {
    id
  }
}

If we invoke the query, we will see that our StubOrderStore.find was hit 3 times.
It's not an issue with our in-memory implementation but might become a problem when the OrderStore implementation is I/O related.

What if we could combine all the underlying requests into one batch request, this would definitely improve the performance.

This is one of the use cases where DataLoader can help.

Let's add the DataLoader to our StubOrderStore.

// stub-order-store.ts

import DataLoader from "dataloader";
...

export class StubOrderStore implements OrderStore {
  private readonly loader: DataLoader<ID, Order | undefined>;

  constructor(private readonly logger: Logger) {
    this.loader = new DataLoader(this.batchLoad);
  }

  find(id: ID): Promise<Order | undefined> {
    return this.loader.load(id);
  }

  private batchLoad: DataLoader.BatchLoadFn<ID, Order | undefined> = (ids) => {
    this.logger.info(`calling StubOrderStore.batchLoad with orderIds: ${ids}`);

    return Promise.resolve(
      ids.map((id) => ({
        id,
      }))
    );
  };
}

Now, when we call our API we have only one message logged:

calling StubOrderStore.batchLoad with orderIds: order-0,order-1

So, DataLoader combines all different find calls into a single call to batchLoad. Moreover, it has deduplicated order-1 calls, which is cool.

Scoped DataLoader State

There is a problem we start facing if we call our API with the same orderIds one more time: we don't get any StubOrderStore.batchLoad messages anymore, meaning the Orders are stale now. That happens because DataLoader caches the batchLoad results per key per DataLoader instance. This is a very useful feature for cases when we want to cache data in the scope of the HTTP request. Unfortunately, with the current implementation, our Orders will never be reloaded from the persistence, since we have one instance of DataLoader for the whole application lifetime.

To fix the issue, we can store DataLoaders in AsyncLocalStorage as we did for RequestId before.

Let's add a new dependency to our StubOrderStore class: GetDataLoader fn:

// stub-order-store.ts
import { BatchLoadFn, GetDataLoader } from "./dataloader";
...

export class StubOrderStore implements OrderStore {
  constructor(
    private readonly logger: Logger,
    private readonly getDataLoader: GetDataLoader<ID, Order | undefined>
  ) {}

  find(id: ID): Promise<Order | undefined> {
    const loader = this.getDataLoader(this.batchLoad);

    return loader.load(id);
  }

  private batchLoad: BatchLoadFn<ID, Order | undefined> = (ids) => {
    this.logger.info(`calling StubOrderStore.batchLoad with orderIds: ${ids}`);

    return Promise.resolve(
      ids.map((id) => ({
        id,
      }))
    );
  };
}

In the code above, we invoke getDataLoader for every find, this gives us the flexibility to work with scoped DataLoader.

Now we also need to update our registry code:

// registry/stub-order-store.ts
export function orderStore() {
  return (deps: {
    createLogger: CreateLogger;
    getDataLoader: GetDataLoader;
  }) => {
    const orderStore = new StubOrderStore(
      deps.createLogger(StubOrderStore.name),
      deps.getDataLoader
    );

    return {
      orderStore,
    };
  };
}

Let's define the GetDataLoader interface:

// dataloader.ts
import DataLoader, { BatchLoadFn } from "dataloader";

export { DataLoader, BatchLoadFn };

export type GetDataLoader<K = any, V = any> = (
  loadFn: BatchLoadFn<K, V>
) => DataLoader<K, V>;

export type RunWithDataLoaders = <R>(callback: (...args: any[]) => R) => R;

Now we need to add the implementations for the interfaces.

Calling getDataLoader should either create a new DataLoader for a given loadFn, or return the existing one if exists.

type DataLoadersMap = Map<
  BatchLoadFn<unknown, unknown>,
  DataLoader<unknown, unknown>
>;

export class DataLoaderStore {
  private readonly dataLoadersMapAls = new AsyncLocalStorage<DataLoadersMap>();

  getDataLoader: GetDataLoader = (loadFn) => {
    const dataLoadersMap = this.dataLoadersMapAls.getStore();
    if (!dataLoadersMap) {
      // throwing an exception here to simplify the cient's code
      throw new Error(
        "'getDataLoader' should not be called outside of 'runWithDataLoaders' callback"
      );
    }

    return getOrCreateDataLoader(loadFn, dataLoadersMap);
  };

  runWithDataLoaders: RunWithDataLoaders = (callback) => {
    return this.dataLoadersMapAls.run(new Map(), callback);
  };
}

function getOrCreateDataLoader(
  loadFn: BatchLoadFn<unknown, unknown>,
  dataLoadersMap: DataLoadersMap
) {
  const existingDataLoader = dataLoadersMap.get(loadFn);
  if (existingDataLoader) {
    return existingDataLoader;
  }

  const newDataLoader = new DataLoader(loadFn);
  dataLoadersMap.set(loadFn, newDataLoader);

  return newDataLoader;
}

// registry/dataloader-store.ts
export function dataLoaderStore() {
  return () => {
    const { getDataLoader, runWithDataLoaders } = new DataLoaderStore();

    return {
      getDataLoader,
      runWithDataLoaders,
    };
  };
}

// create-app-registry.ts
export function createAppRegistry() {
  return new RegistryComposer()
    ...
    .add(dataLoaderStore())
    ...
    .compose();
}

The next step is to run runWithDataLoaders on every Fastify request, similar to what we did for RequestId.

// fastify-plugins/run-with-dataloaders-plugin.ts
export function runWithDataLoadersPlugin(deps: {
  runWithDataLoaders: RunWithDataLoaders;
}): FastifyPluginCallback {
  const plugin: FastifyPluginCallback = (fastify, _, next) => {
    fastify.addHook("onRequest", (_request, _reply, callback) => {
      deps.runWithDataLoaders(callback);
    });

    next();
  };

  return fp(plugin);
}

Registering runWithDataLoadersPlugin on our Fastify server:

// registry/fastify-server.ts
export function fastifyServer() {
  return (
    deps: Parameters<typeof runWithRequestIdPlugin>[0] &
      Parameters<typeof runWithDataLoadersPlugin>[0] &
      ...
  ) => {
    const server = Fastify({});

    server.register(runWithRequestIdPlugin(deps));
    server.register(runWithDataLoadersPlugin(deps));
    ...

    return {
      fastifyServer: server,
    };
  };
}

Finally, we can run our server again and repeat the same request.
We can now see the message for every HTTP request:

calling StubOrderStore.batchLoad with orderIds: order-0,order-1

...

calling StubOrderStore.batchLoad with orderIds: order-0,order-1

Full example source code can be found here

Conclusion

In this tutorial, we covered the usage of the DataLoader library using a global approach and a request-based with AsyncLocalStorage.
In a subsequent article, I will switch the gears and focus on the DI frameworks benchmarking.

Using GraphQL Yoga with Fastify | Pure DI in TypeScript Node.js

Vadim Orekhov — Fri, 03 Feb 2023 01:42:24 +0000

In the tutorial preceding this one, I demonstrated how to create a logging service with metadata. In this article, I will be implementing a new GraphQL endpoint for our application.

I will use the repo as starting point.

Data Store

Before we start implementing the GraphQL server, let's make changes to our business logic layer by adding a new implementation for FindOrderById.

// order-store.ts
interface OrderStore {
  find(id: ID): Promise<Order | undefined>;
}

// find-order-by-id-from-store-provider.ts
export class FindOrderByIdFromStoreProvider {
  constructor(private readonly store: OrderStore) {}

  findOrderById: FindOrderById = (orderId) => {
    return this.store.find(orderId);
  };
}

// registry/find-order-by-id-from-store.ts
export function findOrderById() {
  return ({ orderStore }: { orderStore: OrderStore }) => {
    const { findOrderById } = new FindOrderByIdFromStoreProvider(orderStore);

    return {
      findOrderById,
    };
  };
}

In the code above I also introduced OrderStore interface. We can have multiple implementations for the interface, such as one making requests to SQL DB, or another making HTTP requests to a server.

Essentially, the FindOrderById is our business logic primary port, while OrderStore is a secondary port, in terms of hexagonal architecture.

For now, let's implement the stub adapter for OrderStore:

// stub-order-store.ts
export class StubOrderStore implements OrderStore {
  constructor(private readonly logger: Logger) {}

  find(id: ID): Promise<Order | undefined> {
    this.logger.info(`calling StubOrderStore.find with orderId: ${id}`);

    return Promise.resolve({
      id,
    });
  }
}

// registry/stub-order-store.ts
export function orderStore() {
  return ({ createLogger }: { createLogger: CreateLogger }) => {
    const orderStore = new StubOrderStore(createLogger(StubOrderStore.name));

    return {
      orderStore,
    };
  };
}

// create-app-registry.ts
export function createAppRegistry() {
  return (
    new RegistryComposer()
      // ...
      .add(orderStore())
      .add(findOrderById())
      // ...
      .compose()
  );
}

GraphQL Server

Since I was using fastify I'm going to integrate it with GraphQL Yoga because of simple integration.
First of all, we need to install some dependencies:

yarn install graphql graphql-yoga dataloader
yarn install -D @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-resolvers ts-node

Now we can add graphqlRoutes FastifyPlugin:

// routes/graphql.ts
type HandleNodeRequest = (
  nodeRequest: NodeRequest
) => Promise<Response> | Response;

export function graphqlRoutes({
  handleGraphQLNodeRequest,
}: {
  handleGraphQLNodeRequest: HandleNodeRequest;
}): FastifyPluginCallback {
  return (fastify, _, next) => {
    fastify.route({
      url: "/graphql",
      method: ["GET", "POST", "OPTIONS"],
      handler: async (req, reply) => {
        const response = await handleGraphQLNodeRequest(req);

        response.headers.forEach((value, key) => {
          reply.header(key, value);
        });

        reply.status(response.status);

        reply.send(response.body);

        return reply;
      },
    });

    next();
  };
}

Here we added a simple route for any HTTP method, that just forwards the request to graphqlYoga.handleNodeRequest.

Let's create the route registrar now:

// registry/graphql-yoga.ts
export function graphqlYoga<
  TServerContext extends Record<string, any> = object,
  TUserContext extends Record<string, any> = object
>(options?: Omit<YogaServerOptions<TServerContext, TUserContext>, "schema">) {
  return ({
    createLogger,
    graphqlSchema,
  }: {
    createLogger: CreateLogger;
    graphqlSchema: GraphQLSchemaWithContext<TUserContext & TServerContext>;
  }) => {
    const graphqlYoga = createYoga<TServerContext, TUserContext>({
      ...options,
      logging: createLogger("GraphQLYoga"),
      schema: graphqlSchema,
    });

    return {
      handleGraphQLNodeRequest: graphqlYoga.handleNodeRequest.bind(graphqlYoga),
    };
  };
}

and add it to our fastifyServer:

// registry/fastify-server.ts
export function fastifyServer() {
  return (
    deps: Parameters<typeof runWithRequestIdPlugin>[0] &
      Parameters<typeof ordersRoutes>[0] &
      Parameters<typeof graphqlRoutes>[0]
  ) => {
    const server = Fastify({});

    server.register(runWithRequestIdPlugin(deps));
    server.register(ordersRoutes(deps));
    server.register(graphqlRoutes(deps));

    return {
      fastifyServer: server,
    };
  };
}

GraphQL Schema

Now we can register our GraphQL schema:

# schema.gql
type Order {
  id: ID!
}

type Query {
  order(id: ID!): Order
}

Using graphql-codegen we can generate the typescript definitions from the schema file, see config here.

// graphql-schema.ts

import { Resolvers } from "./generated/resolvers-types";

export function graphqlSchema() {
  return ({ findOrderById }: { findOrderById: FindOrderById }) => {
    return {
      graphqlSchema: createSchema({
        typeDefs: fs.readFileSync(
          path.join(__dirname, "../schema.gql"),
          "utf8"
        ), // <-- I read schema from file here, but we can also use [esbuild loader](https://github.com/luckycatfactory/esbuild-graphql-loader)
        resolvers: {
          Query: {
            order: (_, args) => findOrderById(args.id),
          },
        } as Resolvers,
      }),
    };
  };
}

// create-app-registry.ts
export function createAppRegistry() {
  return (
    new RegistryComposer()
      // ...
      .add(graphqlSchema())
      .add(graphqlYoga())
      /// ...
      .compose()
  );
}

// index.ts
async function main() {
  const registry = createAppRegistry();

  const server = Fastify({});
  server.register(runWithRequestIdPlugin(registry));
  server.register(ordersRoutes(registry));
  server.register(graphqlRoutes(registry));

  try {
    await server.listen({ port: PORT });

    console.log("listening on port", PORT);
  } catch (err) {
    server.log.error(err);
    process.exit(1);
  }
}

Let's run the app now and try to hit our new /graphql endpoint

POST /graphql HTTP/1.1
Host: localhost:3000
Content-Type: application/json
Content-Length: 80

{"query":"query {\n  order(id: \"order-0\") {\n      id\n  }\n}","variables":{}}

Response:

{
  "data": {
    "order": {
      "id": "order-0"
    }
  }
}

Full example source code can be found here

Conclusion

In this article, we learned how to add the GraphQL Yoga plugin to Fastify using a Pure Dependency Injection registry.
In the next article, I'll cover a more interesting topic: how to use DataLoader with GraphQL Yoga and AsyncLocalStorage.

Implementing logging with metadata | Pure DI in TypeScript Node.js

Vadim Orekhov — Thu, 26 Jan 2023 04:37:24 +0000

In the previous tutorial, I've shown how to implement a RequestId feature using AsyncLocalStorage.
Here, we will extend the functionality of our app by adding Logger with metadata.

I will use the repo as starting point.

Logger

Why not use console.* instead? The utilization of a custom logging mechanism, such as the implementation of a Logger interface, offers lots of advantages over relying solely on the use of console. These benefits include:

The ability to selectively log only certain levels of information (such as warnings and above)
The inclusion of additional metadata within the log output
The implementation of a logger name
The potential for future flexibility in terms of easily replacing the logging mechanism without necessitating extensive modifications to the underlying codebase.

Let's switch things up and start using a new logging tool instead of just sticking with console.log. This change will give us more control and options for handling our logs.

// logger.ts
export interface Logger {
  info(message: string, data?: any): void;
  error(message: string, data?: any): void;
}

export type CreateLogger = (name: string) => Logger;

This is the essential part I will use later.

Business logic

Let's replace console.log with our logger.

// stub-order-service.ts
class StubOrderService {
  constructor(
    private readonly getRequestId: GetRequestId,
    private readonly logger: Logger
  ) {}

  findOrderById: FindOrderById = (orderId) => {
    const requestId = this.getRequestId();

    this.logger.info(
      `calling findOrderById with orderId: ${orderId}, requestId: ${requestId}`
    );

    return Promise.resolve({
      id: orderId,
    });
  };
}

// registry/stub-order-service.ts
function stubOrderService() {
  return ({
    getRequestId,
    createLogger,
  }: {
    getRequestId: GetRequestId;
    createLogger: CreateLogger;
  }) => {
    const { findOrderById } = new StubOrderService(
      getRequestId,
      createLogger(StubOrderService.name)
    );

    return {
      findOrderById,
    };
  };
}

Here we made our stubOrderService require createLogger function.

Now we need to register createLogger implementation.

Console Logger

// console-logger.ts
class ConsoleLogger implements Logger {
  constructor(private readonly name: string) {}

  info(message: string, data: any): void {
    console.info(message, { ...data, logger: this.name });
  }

  error(message: string, data: any): void {
    console.error(message, { ...data, logger: this.name });
  }
}

// registry/console-logger.ts
export function consoleLogger() {
  return (): { createLogger: CreateLogger } => {
    return {
      createLogger: (name) => new ConsoleLogger(name),
    };
  };
}

And don't forget to register consoleLogger in our registry.

// create-app-registry.ts
export function createAppRegistry() {
  return (
    new RegistryComposer()
      .add(consoleLogger())
      // ...
      .compose()
  );
}

When we run our application now, we get a similar output as before:

Request:

GET /orders/123/receipt HTTP/1.1
Host: localhost:3000

Output:

INFO: calling findOrderById with orderId: 123, requestId: <random-guid> { logger: 'StubOrderService' }

RequestId Logger Metadata

The logger parent class is really helpful when trying to debug code. To make it even better, we could add some extra information automatically when we log something. For example, we could include the RequestId we implemented in the previous article every time we log a request.

// logger-metadata.ts
type LoggerMetadata = Record<string, any>;

type GetLoggerMetadata<T extends LoggerMetadata = LoggerMetadata> = () => T;

// console-logger.ts
class ConsoleLogger implements Logger {
  constructor(
    private readonly name: string,
    private readonly getLoggerMetadata: GetLoggerMetadata
  ) {}

  info(message: string, data: any): void {
    console.info(message, this.stitchData(data));
  }

  error(message: string, data: any): void {
    console.error(message, this.stitchData(data));
  }

  private stitchData(data: any): any {
    return {
      ...this.getLoggerMetadata(),
      ...data,
      logger: this.name,
    };
  }
}

// registry/console-logger.ts
export function consoleLogger() {
  return ({
    getLoggerMetadata,
  }: {
    getLoggerMetadata: GetLoggerMetadata;
  }): { createLogger: CreateLogger } => {
    return {
      createLogger: (name) => new ConsoleLogger(name, getLoggerMetadata),
    };
  };
}

// request-id-logger-metadata.ts
class RequestIdLoggerMetadataProvider {
  constructor(private readonly getRequestId: GetRequestId) {}

  getLoggerMetadata: GetLoggerMetadata = () => {
    return {
      requestId: this.getRequestId(),
    };
  };
}

// registry/request-id-logger-metadata.ts
interface RequestIdLoggerMetadata {
  requestId?: string;
}

class RequestIdLoggerMetadataProvider {
  constructor(private readonly getRequestId: GetRequestId) {}

  getLoggerMetadata: GetLoggerMetadata<RequestIdLoggerMetadata> = () => {
    return {
      requestId: this.getRequestId(),
    };
  };
}

// create-app-registry.ts
export function createAppRegistry() {
  return (
    new RegistryComposer()
      .add(requestIdStore())
      .add(requestIdLoggerMetadata())
      .add(consoleLogger())
      // ...
      .compose()
  );
}

Now when we have RequestId logged as part of metadata, we can remove it from the business logic:

// stub-order-service.ts
class StubOrderService {
  constructor(private readonly logger: Logger) {}

  findOrderById: FindOrderById = (orderId) => {
    this.logger.info(`calling findOrderById with orderId: ${orderId}`);

    return Promise.resolve({
      id: orderId,
    });
  };
}

// registry/stub-order-service.ts
function stubOrderService() {
  return ({ createLogger }: { createLogger: CreateLogger }) => {
    const { findOrderById } = new StubOrderService(
      createLogger(StubOrderService.name)
    );

    return {
      findOrderById,
    };
  };
}

Let's run our code, and check the output:

INFO: calling findOrderById with orderId: 123 { requestId: <random-id>, logger: 'StubOrderService' }

Chaining Logger Metadata

Works perfectly, but what if we have multiple GetLoggerMetadata? We can change the signature to chain the getLoggerMetadata. Let's add another metadata provider that will just add the environment name to our logs:

// registry/environment-logger-metadata.ts
export function environmentLoggerMetadata(name: string) {
  return ({ getLoggerMetadata }: { getLoggerMetadata?: GetLoggerMetadata }) => {
    return {
      getLoggerMetadata: () => ({
        ...getLoggerMetadata?.(),
        environment: name,
      }),
    };
  };
}

The interesting part here is environmentLoggerMetadata depends on optional getLoggerMetadata and registers getLoggerMetadata. If getLoggerMetadata exists, it will be extended with environment field, otherwise, just environment field will be added.

We should also update requestIdLoggerMetadata to make getLoggerMetadata chainable.

export function requestIdLoggerMetadata<TParent extends LoggerMetadata>() {
  return ({
    getRequestId,
    getLoggerMetadata,
  }: {
    getRequestId: GetRequestId;
    getLoggerMetadata?: GetLoggerMetadata<TParent>;
  }) => {
    const provider = new RequestIdLoggerMetadataProvider(getRequestId);

    return {
      getLoggerMetadata: () =>
        ({
          ...getLoggerMetadata?.(),
          ...provider.getLoggerMetadata(),
        } as Norm<TParent & RequestIdLoggerMetadata>),
    };
  };
}

We can also improve the code by using pipe pattern here. Feel free to left a comment with sample code (the code should be typesafe) :)

Let's update our registry code

// create-app-registry.ts
export function createAppRegistry() {
  return (
    new RegistryComposer()
      .add(environmentLoggerMetadata("local"))
      .add(requestIdStore())
      .add(requestIdLoggerMetadata())
      .add(consoleLogger())
      // ...
      .compose()
  );
}

Output:

INFO: calling findOrderById with orderId: 123, requestId: 79b6a17e-65dd-41ea-bc6e-e82a4b4143a5 {
  environment: 'local',
  requestId: '79b6a17e-65dd-41ea-bc6e-e82a4b4143a5',
  logger: 'StubOrderService'
}

The chaining is a very powerful tool here, which we can use to add, replace, or extend our Registry Services easily.

Full example source code can be found here

Conclusion

In this tutorial, we learned how to implement Logger with LoggerMetadata in fastify application.

In the next article, I'm going to implement a GraphQL server with dataloader using the tools we introduced.

Step-by-step guide to implementing scoped-like dependencies using AsyncLocalStorage with fastify | Pure DI in TypeScript Node.js

Vadim Orekhov — Thu, 19 Jan 2023 04:45:38 +0000

In the previous article, I wrote about implementing Dependency Injection using the Registry approach.
Today, I'm going to focus on the problem of how to deal with scoped-like dependencies within a static application state.

The Problem

Let's say we want to add a new feature to the previous sample app - RequestId.

RequestId represents an identifier that identifies HTTP requests a user made. The value can be also passed as part of the HTTP request headers:

GET /orders/123/receipt HTTP/1.1
Host: localhost:3000
Request-Id: 3558f928-e87b-4240-ac56-b2e4106a6da8

If the Request-Id is not passed as part of HTTP request headers, it must be generated internally.

AsyncLocalStorage

This is the example where AsyncLocalStorage fits perfectly. AsyncLocalStorage is used to associate a state and propagate it throughout callbacks and promise chains.

From the official docs:

import http from "node:http";
import { AsyncLocalStorage } from "node:async_hooks";

const asyncLocalStorage = new AsyncLocalStorage();

function logWithId(msg) {
  const id = asyncLocalStorage.getStore();
  console.log(`${id !== undefined ? id : "-"}:`, msg);
}

let idSeq = 0;
http
  .createServer((req, res) => {
    asyncLocalStorage.run(idSeq++, () => {
      logWithId("start");
      // Imagine any chain of async operations here
      setImmediate(() => {
        logWithId("finish");
        res.end();
      });
    });
  })
  .listen(8080);

http.get("http://localhost:8080");
http.get("http://localhost:8080");
// Prints:
//   0: start
//   1: start
//   0: finish
//   1: finish

Let's implement a similar idea for the previous sample app.

First of all, let's define the interfaces for the feature:

// get-request-id.ts
type RequestId = string;

type GetRequestId = () => RequestId | undefined; // <-- can be undefined if called outside of actual HTTP request

// stub-order-service.ts
class StubOrderService {
  constructor(private readonly getRequestId: GetRequestId) {}

  findOrderById: FindOrderById = (orderId) => {
    const requestId = this.getRequestId();

    console.log(
      `calling findOrderById with orderId: ${orderId}, requestId: ${requestId}`
    );

    return Promise.resolve({
      id: orderId,
    });
  };
}

// registry/stub-order-service.ts
function stubOrderService() {
  return ({ getRequestId }: { getRequestId: GetRequestId }) => {
    const { findOrderById } = new StubOrderService(getRequestId);

    return {
      findOrderById,
    };
  };
}

Now, we need to implement RequestIdStore service:

// request-id-store.ts
import { AsyncLocalStorage } from "node:async_hooks";

class RequestIdStore {
  private readonly requestIdAls = new AsyncLocalStorage<RequestId>();

  getRequestId: GetRequestId = () => {
    return this.requestIdAls.getStore();
  };
}

// registry/request-id-store.ts
function requestIdStore() {
  return () => {
    const { getRequestId } = new RequestIdStore();

    return {
      getRequestId,
    };
  };
}

RequestIdProvider has 1 function now: it can fetch RequestId from AsyncLocalStorage. The magic comes from the AsyncLocalStorage, which will propagate the state throughout callbacks and promise chains.

Now let's define a new function type to set the state: RunWithRequestId.

type RunWithRequestId = <R>(
  requestId: RequestId,
  callback: (...args: unknown[]) => R
) => R;

And add the implementation of RunWithRequestId to our RequestIdStore.

// request-id-store.ts
class RequestIdStore {
  // ...

  runWithRequestId: RunWithRequestId = (requestId, callback) => {
    return this.invocationInfoAls.run(requestId, callback);
  };
}

// registry/request-id-store.ts
function requestIdStore() {
  return () => {
    const { getRequestId, runWithRequestId } = new RequestIdStore();

    return {
      getRequestId,
      runWithRequestId,
    };
  };
}

Essentially, we just incapsulating AsyncLocalStorage into our RequestIdStore.

We also should update our createAppRegistry function:

export function createAppRegistry() {
  return new RegistryComposer()
    .add(requestIdStore())
    .add(stubOrderService())
    .add(stubOrderReceiptGenerator())
    .add(fastifyServer())
    .compose();
}

Cool, let's run the app and see the output:

Request:

GET /orders/123/receipt HTTP/1.1
Host: localhost:3000
Request-Id: 3558f928-e87b-4240-ac56-b2e4106a6da8

Output:

INFO: calling findOrderById with orderId: 123, requestId: undefined

As we can see, the requestId is undefined now, since we never called our RunWithRequestId function.

So, because we have fastify app, we can add a new middleware plugin then and call RunWithRequestId there. It will be the perfect place since we also need to populate the RequestId according to the requirements above.

// run-with-request-id-plugin.ts
import * as uuid from "uuid";
import fp from "fastify-plugin";

const REQUEST_ID_HEADER_NAME = "Request-Id";

export function runWithRequestIdPlugin(deps: {
  runWithRequestId: RunWithRequestId;
}): FastifyPluginCallback {
  const plugin: FastifyPluginCallback = (fastify, _, next) => {
    fastify.addHook("onRequest", (request, _reply, callback) => {
      const requestId =
        request.headers[REQUEST_ID_HEADER_NAME]?.toString() ?? uuid.v4();

      deps.runWithRequestId(requestId, callback);
    });

    next();
  };

  return fp(plugin); // we need fp here to make our plugin to be global
}

Note: You can read more about fastify-plugin here.

Finally, changing the fastify-server registry file:

// registry/fastify-server.ts
export function fastifyServer() {
  return (
    deps: Parameters<typeof runWithRequestIdPlugin>[0] &
      Parameters<typeof ordersRoutes>[0]
  ) => {
    const server = fastify({});

    server.register(runWithRequestIdPlugin(deps));
    server.register(ordersRoutes(deps));

    return {
      fastifyServer: server,
    };
  };
}

If we run the app again, we will see the following output:

Request:

GET /orders/123/receipt HTTP/1.1
Host: localhost:3000
Request-Id: 3558f928-e87b-4240-ac56-b2e4106a6da8

Output:

INFO: calling findOrderById with orderId: 123, requestId: 3558f928-e87b-4240-ac56-b2e4106a6da8

Request without Request-ID header:

GET /orders/123/receipt HTTP/1.1
Host: localhost:3000

Output:

INFO: calling findOrderById with orderId: 123, requestId: <random-guid>

Full example source code can be found here

Conclusion

In this tutorial, we learned how to implement Scoped-like dependencies such as RequestId using AsyncLocalStorage in fastify application.
To implement the same approach in Express.js or ApolloServer, simply implement the middleware. The rest of the code will stay the same.
In the next article, I'm going to show how to implement a Logger with metadata using AsyncLocalStorage.

Typesafe, (almost) Zero Cost Dependency Injection in TypeScript | Pure DI in TypeScript Node.js

Vadim Orekhov — Mon, 09 Jan 2023 15:04:11 +0000

Introduction

In this set of articles, I'm going to share my own experience with implementing and using Typesafe Dependency Injection with Registry in TypeScript Node.js backend applications.

So, let's get started with it.

P.S. you can read more about Dependency Inversion vs. Inversion of Control vs. Dependency Injection here and here.

Some Ways of Dependency Injection in TypeScript

The are basically 3 different ways to perform Dependency Injection in TypeScript:

Higher-order function Arguments Injection
Class Constructor Injection
Class Property Injection (will not be covered here since it causes the Temporal Coupling code smell)

Higher-order function

Example:

export function createOrderReceiptGenerator(orderService: OrderService) {
  return {
    generate(orderId: ID) {
      const order = orderService.findById(orderId);

      return orderService.generate(order);
    },
  };
}

Static linking example:

export function main() {
  const orderService = createOrderService();
  const orderReceiptGenerator = createOrderReceiptGenerator(orderService);

  const reciept = await orderReceiptGenerator.generate();
}

Class Constructor Injection

Generally the same idea, but instead of closure, the context is handled by the JavaScript class feature.

export class OrderReceiptGenerator {
  constructor(private readonly orderService: OrderService) {}

  public generate(orderId: ID) {
    const order = this.orderService.findById(orderId);

    return this.orderService.generate(order);
  }
}

Static linking example (aka. Pure DI):

export function main() {
  const orderService = new DefaultOrderService();
  const orderReceiptGenerator = new DefaultOrderReceiptGenerator(orderService);

  const reciept = await orderReceiptGenerator.generate();
}

IoC Container

IoC Container - is a service locator where you can register services by a token and later resolve them by the token:

interface Container {
  register(token: unknown, config: RegistrationConfig): this;
  resolve<T>(token: unknown): T; // throws wnen one of the token in the chain cannot be resolved
}

One of the nice features of IoC containers is that you can define lifetimes for your services.
We usually have the settings for the dependency Lifetime as part of RegistrationConfig.
Well-known lifetimes:

Transient - New instance every time
Scoped - Instance per (HTTP request)/(another invocation)
Singleton - Instance per application lifetime

With Decorators

This is the most common way to perform Dependency Injection in Typescript.

Unlike Java and C#, when TypeScript is transpiled to JavaScript the type information gets lost, making a TypeScript interface become nothing in JS. Because of this, it's not possible to use the interface itself as a token in the IoC Container. Decorators come in handy here to configure the service metadata in the Container.

There are a bunch of libraries that use decorators:

Example of using inversify decorators:

// order-service.ts
const OrderService = "OrderService";

export interface OrderService {
  findOrderById(orderId: ID): Promise<Order>;
  generateReceipt(order: Order): Promise<Receipt>;
  // ... others
}

// order-receipt-generator.ts
import { inject } from "inversify"; // <-- extra external dependency

export class OrderReceiptGenerator {
  constructor(
    @inject(OrderService) private readonly orderService: OrderService
  ) {}

  // generate receipt
}

Dynamic linking example:

export function main() {
  const container = new Container();

  container
    .bind<OrderService>(OrderService)
    .to(DefaultOrderService)
    .inSingletonScope();

  container
    .bind<OrderReceiptGenerator>(OrderReceiptGenerator)
    .toSelf()
    .inTransientScope();

  // ...later...

  const orderReceiptGenerator = container.resolve(OrderReceiptGenerator);

  const reciept = await orderReceiptGenerator.generate();
}

Unfortunately, the approach with decorators has some issues:

The decorator is still an experimental feature in TypeScript and it's not implemented in JavaScript. However, they are on stage 3 now.
Using the decorators requires importing the reflect-metadata package
The decorators have performance overhead
The decorators make constructors more verbose and less readable
The decorators make a coupling between the business code and the IoC library
Very hard to override the token in inject since the metadata is bonded with the parent class itself

It's worth saying that problems 4-6 have workarounds but they are often not pretty.

Without Decorators

You might also find some libraries that don't depend on decorators, like:

DI-compiler

Pros:
- Typesafe at transpile time
- Requires no extra dependencies on business code
Cons:
- Requires extra transpile step
- Not typesafe at dev time

typed-inject

Pros:
- Typesafe at dev time and transpile time
- Requires no extra dependencies on business code
Cons:
- Requires adding specific public static inject construction to class
- Works only with Literal Types tokens

Disadvantages

Overall, using the IoC Container is nice and fun, but it also has some disadvantages:

Usually not typesafe, aka might lead to runtime errors if a desired token is not defined in the container
Hard to know the dependency lifetime when injecting it
Injecting short-lifetime dependency into long-lifetime service (for ex. Transient dependency into Singleton service) might lead to unpredicted behavior
Runtime performance overhead
IoC Container is Service Locator which is considered to be an anti-pattern when used directly

Should we hold and think a little?

Seems like at this point we have a lot of potential issues with the IoC Container approach. At the same time, the Class Constructor Injection seemed very clean but the static linking configuration is hard and messy. How can we achieve the configuration simplicity of the IoC Container with dev-time type safety?

Removing Excess

Before we go to the solution, let's talk about the lifetimes.

Previously, I've mentioned 3 lifetimes: Transient, Scoped, and Singleton, but do we really need them given the disadvantages we have using them all?
If we simplify everything to Singleton this might solve most of the problems. So, here is what we can do then:

Use Factory when Transient dependency is necessary
Replace Scoped dependency with a scope provider

Use Factory when Transient dependency is necessary

Transient dependencies are tricky. They only work properly when the whole chain of resolution is Transient, otherwise, it might lead to unexpected problems.
So my solution here would be to use a factory when the new instance is required.

Replace Scoped dependency with a scope provider

The one example of using Scoped dependency that comes to my mind, it's HTTP request level caching for libs like dataloader.

This problem seems tough initially, but fortunately, we can actually solve this easily by using Node.js async_hooks feature.
I will provide the solution in the next article.

At this point all our dependencies in the container become Singleton and we can basically replace the container with a single application state object and create it at application startup time (like with did with static linking).

Registry

This approach is inspired by the article and I call it Registry.

Let's start with the example of REST APIs built over fastify:

// orders-routes.ts
export function ordersRoutes(deps: {
  orderReceiptGenerator: OrderReceiptGenerator;
}): FastifyPluginCallback {
  return (fastify, _, next) => {
    fastify.get("/orders/:orderId/receipt", async (request, reply) => {
      const { orderId } = request.params as {
        orderId: string;
      };

      const receipt = await deps.orderReceiptGenerator.generateReceipt(orderId);

      if (!receipt) {
        return reply.status(404).send();
      }

      return reply.send(receipt);
    });

    next();
  };
}

// create-app-registry.ts
export function createAppRegistry() {
  const orderService = new DefaultOrderService();
  const orderReceiptGenerator = new DefaultOrderReceiptGenerator(orderService);

  // will automatically infer the types and fail at transpile type if services are missing or invalid.
  return {
    orderService,
    orderReceiptGenerator,
  };
}

// index.ts

async function main() {
  const registry = createAppRegistry();

  const server = Fastify({});
  server.register(ordersRoutes(registry));

  try {
    await server.listen({ port: PORT });

    console.log("listening on port", PORT);
  } catch (err) {
    server.log.error(err);
    process.exit(1);
  }
}

main();

Note that I pass the whole registry object into ordersRoutes, while ordersRoutes itself depends only on a slice of services to avoid unnecessary coupling:

export function ordersRoutes(deps: {
  orderReceiptGenerator: OrderReceiptGenerator;
}): FastifyPluginCallback {
  ...

Here we have the zero-cost type safety, with no runtime overhead.

However, this approach has one issue. The dependency graph might grow very fast and the registry composing might become painful.

RegistryComposer

To solve the problem we can use the following simple RegistryComposer class:

export class RegistryComposer<TNeeds extends object = object> {
  private readonly creators: CreateServices<TNeeds, object>[] = [];

  add<TServices extends object>(
    createServices: CreateServices<TNeeds, TServices>
  ): RegistryComposer<Combine<TNeeds, TServices>> {
    this.creators.push(createServices);

    return this as any;
  }

  compose(): Readonly<TNeeds> {
    return Object.freeze(
      this.creators.reduce((state, createServices) => {
        return Object.assign(state, createServices(state));
      }, {} as any)
    );
  }
}

type CreateServices<TNeeds, TServices extends object> = (
  needs: TNeeds
) => TServices;

type Combine<TSource extends object, TWith extends object> = Norm<
  Omit<TSource, keyof TWith> & TWith
>;

type Norm<T> = T extends object
  ? {
      [P in keyof T]: T[P];
    }
  : never;

Note: You can find complete source code here.

The RegistryComposer provides the ability to chain state mutation. Every new call in the chain knows about the previous state modifications.
The CreateServices function type is a mapper function to create a new Registry state. The needs argument defines what services the registration depends on, and the function returns new services as a Record.

Note: The Combine type is a helper to override field types when a field with the same name added.

Note: The Norm type is a helper to remove & (intersections) from resulting TypeScript hints.

Calling compose finally composes the registry object:

// create-app-registry.ts
export function createAppRegistry() {
  return new RegistryComposer()
    .add(() => {
      orderService: new DefaultOrderService();
    })
    .add(
      // knowns that the state already contains orderService
      ({ orderService }) => ({
        orderReceiptGenerator: new DefaultOrderReceiptGenerator(orderService),
      })
    )
    .compose();
}

Let's refactor the code to make it prettier:

// create-app-registry.ts
export function createAppRegistry() {
  return new RegistryComposer()
    .add(orderService())
    .add(orderReceiptGenerator())
    .compose();
}

function orderService() {
  return () => {
    const orderService = new DefaultOrderService();

    return {
      orderService,
    };
  };
}

function orderReceiptGenerator{
  return (needs: { orderService: OrderService }) => {
    const orderReceiptGenerator = new DefaultOrderReceiptGenerator(
      needs.orderService
    );

    return {
      orderReceiptGenerator,
    };
  };
}

Looks much better now, we should also move the functions into their files and write tests.

Why almost zero cost?

Obviously, we sacrifice the cold-start performance a little to have the RegistryComposer and nice-looking add functions.

Function Injection

Very common the services tend to grow much if not paid attention (not following the Single Responsibility Principle).

// order-service.ts

export interface OrderService {
  findOrderById(orderId: ID): Promise<Order>;
  addProductToOrder(productId: ID): Promise<void>;
  findByProduct(productId: ID): Promise<readonly Order[]>;
  findByUser(userId: ID): Promise<readonly Order[]>;
  findByCategoryType(categoryType: string): Promise<readonly Order[]>;
  generateReceipt(order: Order): Promise<Receipt>;
  generateStats(): Promise<OrdersStats>;
  // ... others
}

Client code:

// order-receipt-generator.ts

export class OrderReceiptGenerator {
  constructor(private readonly orderService: OrderService) {}

  // generate receipt
}

To fix the issue, as a first step, we can just break up the OrderService interface into smaller interfaces.

// order-finder-service.ts

export interface OrderService {
  findByProduct(productId: ID): Promise<readonly Order[]>;
  findByUser(userId: ID): Promise<readonly Order[]>;
  findByCategoryType(categoryType: string): Promise<readonly Order[]>;
}

// order-receipt-service.ts

export interface OrderRecipeService {
  generateReceipt(order: Order): Promise<Receipt>;
}

// ... etc

The first doubt comes here with the naming, how should we name the interfaces now properly to emphasize the grouping?
Alternatively, we might also move every method into its own interface like:

// find-orders-by-product-service.ts

export interface FindOrdersByProductService {
  findByProduct(productId: ID): Promise<readonly Order[]>;
}

// find-orders-by-user-service.ts

export interface FindOrdersByUserService {
  findByUser(userId: ID): Promise<readonly Order[]>;
}

// ... etc

Hmm, seems very verbose now...

What if we could break up the service interface completely to remove the coupling?

Hopefully, unlike languages like C#, TypeScript is functional, meaning we can simply break up the interface to function types, so OrderService becomes:

Note: In C# we can use delegate for it.

// find-order-by-id.ts

export type FindOrderById = (orderId: ID) => Promise<Order>;

// ... others...

// generate-report.ts

export type GenerateReceipt = (order: Order) => Promise<Receipt>;

Looks much cleaner now. Besides, it makes the API simpler, it also makes the API client constructor more understandable:

// order-receipt-generator.ts

export class OrderReceiptGenerator {
  constructor(
    private readonly findOrderById: FindOrderById,
    private readonly generateReceipt: GenerateReceipt
  ) {}

  public generate(orderId: ID) {
    const order = this.findOrderById(orderId);

    return this.generateReceipt(order);
  }
}

Additionally, it solves another problem with understanding of OrderReceiptGenerator. In the classical (service injection) approach, it's not possible to know what methods of OrderService are going to be called in OrderReceiptGenerator without looking into each method code. However, with the functional injection approach, we can just check the OrderReceiptGenerator constructor dependencies to easily grasp.

Additionally, we can now see if OrderReceiptGenerator class becomes too complex - when it has too many dependencies.

Adding function to the Registry

To add a function to the Registry we can use the following code snippet

// stub-find-order-by-id.ts

export class StubFindOrderById {
  findOrderById: FindOrderById = (id) => {
    return Promise.resolve({
      id,
    });
  };
}

// registry/stub-find-order-by-id.ts

export function stubFindOrderById() {
  return () => {
    const { findOrderById } = new StubFindOrderById();

    return {
      findOrderById,
    };
  };
}

We can go even further now, and move Fastify server creation to the RegistryComposer as well:

// fastify-server.ts
export function fastifyServer() {
  return (deps: Parameters<typeof ordersRoutes>[0]) => {
    const server = fastify({});

    server.register(ordersRoutes(deps));

    return {
      fastifyServer: server,
    };
  };
}

// create-app-registry.ts
export function createAppRegistry() {
  return new RegistryComposer()
    .add(orderService())
    .add(orderReceiptGenerator())
    .add(fastifyServer())
    .compose();
}

// index.ts
async function main() {
  const { fastifyServer } = createAppRegistry();

  try {
    await fastifyServer.listen({ port: PORT });

    console.log("listening on port", PORT);
  } catch (err) {
    fastifyServer.log.error(err);
    process.exit(1);
  }
}

main();

Conclusion

In this article, we learned how to use Dependency Injection with Registry on TypeScript.
The approach we implemented has the following characteristics:

typesafe, meaning all the dependencies are resolved at developing/transpile time
no framework/library dependencies to implement the injection (Pure DI)
Easy to know the dependency lifetime since all dependencies are "Singleton" like in Registry
Easy to create multiple instances of the same service with different token
Easy to chain dependencies with the same token (for ex. for implementing middleware pattern)
Zero-cost overhead (almost)

In the following articles, I'm going to cover the topics of scoped-like dependencies, logging, configuration, benchmarks, and using the registry within hexagonal/clean architecture projects.

Sample code can be found in the repository.