pulumi/docs/architecture/mlcs.md

(mlcs)=

Multi-language components (MLCs)

Authors of Pulumi programs can use component resources to logically group related resources together. For instance, a TypeScript program might specify a component that combines AWS and PostgreSQL providers to abstract the management of an RDS database and logical databases within it:

import * as aws from "@pulumi/aws"
import * as postgresql from "@pulumi/postgresql"

class Database extends pulumi.ComponentResource {
  constructor(name: string, args: DatabaseArgs, opts?: pulumi.ComponentResourceOptions) {
    super("my:database:Database", name, args, opts)

    const rds = new aws.rds.Instance("my-rds", { ... }, { parent: this })
    const pg = new postgresql.Database("my-db", { ... }, { parent: this })

    ...
  }
}

This component can then be used just like any other Pulumi resource:

const db = new Database("my-db", { ... })

...if the program is written in the same language as the component (in this case, TypeScript). In some cases however it would be great if components could be reused in multiple languages, since components provide a natural means to abstract and reuse infrastructure.

Enter multi-language components (MLCs). MLCs are components which can be written in one language and used in another (or rather, any other). Under the hood, MLCs are implemented as just another method: . The engine automatically calls Construct when it sees a request to create an MLC.¹ Indeed, since providers and gRPC calls are the key to making custom resources consumable in any language, exposing components through the same interface is a natural extension of the Pulumi model.

Just as the body of a component resource is largely concerned with instantiating other resources, so is the implementation of Construct for an MLC. Whereas a custom resource's method can be expected to make a "raw" call to some underlying cloud provider API (for instance), is generally only concerned with registering child resources and their desired state. For this reason, includes a monitorEndpoint so that the MLC can itself make calls back to the deployment's resource monitor to register these child resources.

---

1. See resource registration for more information. ↩︎