sdk: OnDeploy is able to manage resources more efficiently

Feature Spec

In previous versions of Wing, the OnDeploy mechanism created 5 underlying resources for each OnDeploy resource. These are:

• IAM resources
• Lambda function
• S3 object

This design was inefficient, especially in scenarios where high-level constructs shared the same codebase. There was no means to reuse existing cloud resources, leading to a rapid increment in resource count.

With Wing's recent update, there is now a way to manage resources more efficiently using OnDeploy. Users can explicitly define a function and pass it as a handler to the OnDeploy resource. This function can be parameterized, ensuring that defining new resources doesn't result in a proportional increase in the count of underlying cloud resources.

bring cloud;

struct MyPayload {
  from: str;
  to: str;
}

let fn = new cloud.Function(inflight (event) => {
  let payload = event.payload // Need a way to type as MyPayload
});

new cloud.OnDeploy(fn, {
  payload: { // Need a way to type as MyPayload
    from: "/"
    to: "https://www.example.com"
  }
});

Use Cases

Here's a Wing Class utilizing the OnDeploy resource to implement a post deployment check (smoke test).

bring cloud;
bring http;
bring "@cdktf/provider-dnsimple" as dnsimple;

struct ExpectRedirectProps {
  from: str;
  to: str;
}

class ExpectRedirect {
  init(resource: dnsimple.zoneRecord.ZoneRecord, props: ExpectRedirectProps) {
    let path = props.from;
    let location = props.to;
    let domain = "${resource.name}.${resource.zoneName}";
    new cloud.OnDeploy(inflight() => {
      let url = "https://${domain}${path}";
      // this follows the redirect automatically
      let result = http.get(url);
      try {
        assert(result.status == 200);
      } catch e {
        throw("Expected ${url} to redirect to ${location} with final status of 200, but got ${result.url} with status ${result.status} - ${e}");
      }

      try {
        assert(result.url == location);
      } catch e {
        throw("Expected ${url} to redirect to ${location}, but got ${result.url} - ${e}");
      }
    }, {
      executeAfter: [resource],
      timeout: 10s,
    });
  }
}

This class can be used like this

//...

let docsRecord = new dnsimple.zoneRecord.ZoneRecord(
  name: docsSubDomain,
  type: "CNAME",
  value: docsDistribution.domainName,
  zoneName: zoneName,
  ttl: 60
)

new smokeTest.ExpectRedirect(docsRecord, {
  from: "/",
  to: "https://www.winglang.io/docs/",
}) as "smoke.docs.one";

new smokeTest.ExpectRedirect(docsRecord, {
  from: "/?bar=baz",
  to: "https://www.winglang.io/docs/?bar=baz",
}) as "smoke.docs.two";

Right now, each definition will create 5 new resources, which will add up and might exceed the main resource count by a lot

Implementation Notes

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/lambda_invocation takes a payload attribute which we should be able to use.
• doesn't look like that the awscdk / cfn version is accepting a custom payload https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.triggers.Trigger.html
• doesn't look like gcp / azure tf providers are supporting invoking functions at all

One idea @Chriscbr had: perhaps it's possible to detect identical handler code and do the optimization behind the scenes

Component

SDK

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

Start with the cloud.OnDeploy SDK entry point and the provider behavior described for Terraform's AWS lambda_invocation data source, AWS CDK, GCP, and Azure. Determine how an explicitly supplied cloud.Function handler and payload should be represented across supported providers. Done means repeated OnDeploy resources can reuse the handler without creating proportional underlying resources, with provider limitations accounted for.