Skip to main content

Dependency Container

In this document, you’ll learn what the dependency container is and how you can use it in Medusa.

Introduction

What is Dependency Injection

Dependency Injection is the act of delivering the required resources to a class. These resources are the class’s dependencies. This is usually done by passing (or injecting) the dependencies in the constructor of the class.

Generally, all resources are registered in a container. Then, whenever a class depends on one of these resources, the system retrieves the resources from the container and injects them into the class’s constructor.

Medusa’s Dependency Container

Medusa uses a dependency container to register essential resources of your backend. You can then access these resources in classes and endpoints using the dependency container.

For example, if you create a custom service, you can access any other service registered in Medusa in your service’s constructor. That includes Medusa’s core services, services defined in plugins, or other services that you create on your backend.

You can load more than services in your Medusa backend. You can load the Entity Manager, logger instance, and much more.

MedusaContainer

To manage dependency injections, Medusa uses Awilix. Awilix is an NPM package that implements dependency injection in Node.js projects.

When you run the Medusa backend, a container of the type MedusaContainer is created. This type extends the AwilixContainer object.

The backend then registers all important resources in the container, which makes them accessible in classes and endpoints.


Registered Resources

The Medusa backend scans the core Medusa package, plugins, and your files in the dist directory and registers the following resources:

Many resources are registered under their camel-case name. These resources are formatted by taking the name of the file, transforming it to camel case, then appending the folder name to the name. So, the services/product.ts service is registered as productService.

Resource

Description

Registration Name

Configurations

The configurations that are exported from medusa-config.js.

configModule

Services

Services that extend the TransactionBaseService class.

Each service is registered under its camel-case name. For example, the ProductService is registered as productService.

Entity Manager

An instance of Typeorm’s Entity Manager.

manager

Logger

An instance of Medusa CLI’s logger. You can use it to log messages to the terminal.

logger

Single Payment Provider

An instance of every payment provider that extends the AbstractPaymentService class.

Every payment provider is registered under two names:

  • Its camel-case name. For example, the StripeProviderService is registered as stripeProviderService.
  • pp_ followed by its identifier. For example, the StripeProviderService is registered as pp_stripe.

All Payment Providers

An array of all payment providers that extend the AbstractPaymentService class.

paymentProviders

Single Fulfillment Provider

An instance of every fulfillment provider that extends the FulfillmentService class.

Every fulfillment provider is registered under two names:

  • Its camel-case name. For example, the WebshipperFulfillmentService is registered as webshipperFulfillmentService.
  • fp_ followed by its identifier. For example, the WebshipperFulfillmentService is registered as fp_webshipper.

All Fulfillment Providers

An array of all fulfillment providers that extend the FulfillmentService class.

fulfillmentProviders

Single Notification Provider

An instance of every notification provider that extends the AbstractNotificationService or the BaseNotificationService classes.

Every notification provider is registered under two names:

  • Its camel-case name. For example, the SendGridService is registered as sendGridService.
  • noti_ followed by its identifier. For example, the SendGridService is registered as noti_sendgrid.

All Notification Providers

An array of all notification providers that extend the AbstractNotificationService or the BaseNotificationService classes.

notificationProviders

File Service

An instance of the class that extends the FileService class, if any.

The file service is registered under two names:

  • Its camel-case name. For example, the MinioService is registered as minioService.
  • fileService

Search Service

An instance of the class that extends the AbstractSearchService or the SearchService classes, if any.

The search service is registered under two names:

  • Its camel-case name. For example, the AlgoliaService is registered as algoliaService.
  • searchService

Single Tax Provider

An instance of every tax provider that extends the AbstractTaxService class.

The tax provider is registered under two names:

  • Its camel-case name.
  • tp_ followed by its identifier.

All Tax Providers

An array of every tax provider that extends the AbstractTaxService class.

taxProviders

Oauth Services

An instance of every service that extends the OauthService class.

Each Oauth Service is registered under its camel-case name followed by Oauth.

Feature Flag Router

An instance of the FlagRouter. This can be used to list feature flags, set a feature flag’s value, or check if they’re enabled.

featureFlagRouter

Redis

An instance of the Redis client. If Redis is not configured, a fake Redis client is registered.

redisClient

Single Entity

An instance of every entity.

Each entity is registered under its camel-case name followed by Model. For example, the CustomerGroup entity is stored under customerGroupModel.

All Entities

An array of all database entities that is passed to Typeorm when connecting to the database.

db_entities

Repositories

An instance of each repository.

Each repository is registered under its camel-case name. For example, CustomerGroupRepository is stored under customerGroupRepository.

Single Batch Job Strategy

An instance of every class extending the AbstractBatchJobStrategy class.

Each batch job strategy is registered under three names:

  • Its camel-case name. For example, ProductImportStrategy is registered as productImportStrategy.
  • batch_ followed by its identifier. For example, the ProductImportStrategy is registered under batch_product-import-strategy.
  • batchType_ followed by its batch job type. For example, the ProductImportStrategy is registered under batchType_product-import.

All Batch Job Strategies

An array of all classes extending the AbstractBatchJobStrategy abstract class.

batchJobStrategies

Tax Calculation Strategy

An instance of the class implementing the ITaxCalculationStrategy interface.

taxCalculationStrategy

Cart Completion Strategy

An instance of the class extending the AbstractCartCompletionStrategy class.

cartCompletionStrategy

Price Selection Strategy

An instance of the class implementing the IPriceSelectionStrategy interface.

priceSelectionStrategy

Strategies

An instance of strategies that aren’t of the specific types mentioned above and that are under the strategies directory.

Its camel-case name.


Loading Resources

This section covers how to load resources that the Medusa backend registers when it starts running.

In Endpoints

To load resources, such as services, in endpoints, use the req.scope.resolve function. The function receives the registration name of the resource as a parameter.

For example:

const logger = req.scope.resolve("logger")

Please note that in endpoints some resources, such as repositories, are not available.

In Classes

In classes such as services, strategies, or subscribers, you can load resources in the constructor function. The constructor receives an object of dependencies as a first parameter. Each dependency in the object should use the registration name of the resource that should be injected to the class.

For example:

import { OrderService } from "@medusajs/medusa"

class OrderSubscriber {
protected orderService: OrderService

constructor({ orderService }) {
this.orderService = orderService
}
}

See Also