FeaturesMiddleware

Using Middleware for Dependency Injection

Inngest Functions running in the same application often need to share common clients instances such as database clients or third-party libraries.

The following is an example of adding a OpenAI client to all Inngest functions, allowing them immediate access without needing to create the client themselves.

We can use the dependencyInjectionMiddleware to add arguments to a function's input.

Check out the TypeScript example for a customized middleware.

import { dependencyInjectionMiddleware } from "inngest";
import OpenAI from 'openai';

const openai = new OpenAI();

const inngest = new Inngest({
  id: 'my-app',
  middleware: [
    dependencyInjectionMiddleware({ openai }),
  ],
});

Our Inngest Functions can now access the OpenAI client through the context:

inngest.createFunction(
 { name: "user-create" },
 { event: "app/user.create" },
 async ({ openai }) => {
   const chatCompletion = await openai.chat.completions.create({
     messages: [{ role: "user", content: "Say this is a test" }],
     model: "gpt-3.5-turbo",
   });

   // ...
 },
);

💡 Types are inferred from middleware outputs, so your Inngest functions will see an appropriately-typed openai property in their input.

Explore other examples in the TypeScript SDK Middleware examples page.

Advanced mutation

When the middleware runs, the types and data within the passed ctx are merged on top of the default provided by the library. This means that you can use a few tricks to overwrite data and types safely and more accurately.

For example, here we use a const assertion to infer the literal value of our foo example above.

// In middleware
dependencyInjectionMiddleware({
  foo: "bar",
} as const)

// In a function
async ({ event, foo }) => {
  //             ^? (parameter) foo: "bar"
}

Ordering middleware and types

Middleware runs in the order specified when registering it (see Middleware - Lifecycle - Registering and order), which affects typing too.

When inferring a mutated input or output, the SDK will apply changes from each middleware in sequence, just as it will at runtime. This means that for two middlewares that add a foo value to input arguments, the last one to run will be what it seen both in types and at runtime.