Dependency Container and Injection

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

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 the backend. You can then access these resources in classes and API Routes 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 API Routes.

---

Registered Resources

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

Tip

The Lifetime column indicates the lifetime of a service. Other resources that aren't services don't have a lifetime, which is indicated with the - in the column. You can learn about what a lifetime is in the Create a Service documentation.

Resource	Description	Registration Name	Lifetime
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.	Core services by default have the SINGLETON lifetime. However, some have a different lifetime which is indicated in this table. Custom services, including services in plugins, by default have the SCOPED lifetime, unless defined differently within the custom service.
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 Processor	An instance of every payment processor that extends the AbstractPaymentService or the AbstractPaymentProcessor classes.	Every payment processor is registered under two names: Its camel-case name of the processor. For example, the StripeProviderService is registered as stripeProviderService. pp_ followed by its identifier. For example, the StripeProviderService is registered as pp_stripe.	By default, it's SINGLETON unless defined differently within the payment processor service.
All Payment Processors	An array of all payment processor that extend the AbstractPaymentService or AbstractPaymentProcessor class.	paymentProviders	paymentProviders is TRANSIENT, and each item in it is SINGLETON.
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.	By default, it's SINGLETON unless defined differently within the fulfillment provider service.
All Fulfillment Providers	An array of all fulfillment providers that extend the FulfillmentService class.	fulfillmentProviders	fulfillmentProviders is TRANSIENT, and each item in it is SINGLETON.
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.	By default, it's SINGLETON unless defined differently within the notification provider service.
All Notification Providers	An array of all notification providers that extend the AbstractNotificationService or the BaseNotificationService classes.	notificationProviders	notificationProviders is TRANSIENT, and each item in it is SINGLETON.
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	By default, it's SINGLETON unless defined differently within the file service.
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	By default, it's SINGLETON unless defined differently within the search service.
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.	By default, it's SINGLETON unless defined differently within the tax provider service.
All Tax Providers	An array of every tax provider that extends the AbstractTaxService class.	taxProviders	taxProviders is TRANSIENT, and each item in it is SINGLETON.
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.	By default, it's SINGLETON unless defined differently within the Oauth service.
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.	-

---

Resolve Resources

This section covers how to resolve resources from the dependency container to use them in API Routes and classes in general.

In API Routes

To resolve resources, such as services, in API Routes, use the MedusaRequest object's scope.resolve method. The method receives the registration name of the resource as a parameter.

For example:

const productService: ProductService = req.scope.resolve(
  "productService"
)

Please note that in API Routes some resources, such as repositories, aren't available. Refer to the repositories documentation to learn how you can load them.

In Subscribers

To resolve resources, such as services, in subscriber handler functions, use the container property of the handler function's parameter. The container has a method resolve which accepts the registration name of a resource as a parameter.

For example:

import { 
  ProductService,
  type SubscriberConfig, 
  type SubscriberArgs,
} from "@medusajs/medusa"

export default async function productUpdateHandler({ 
  data, eventName, container, pluginOptions, 
}: SubscriberArgs<Record<string, string>>) {
  const productService: ProductService = container.resolve(
    "productService"
  )

  // ...
}

// ...

In Classes

In classes such as services or strategies, you can load resources in the constructor function using dependency injection. 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

• Create services
• Create subscribers