Provide a way to expose the real aws-sdk simply through the pulumi API at runtime

[CyrusNajmabadi]

Ready to review. This allows clients in downstream libraries to write the following in their lambdas:

import * as aws from "@pulumi/aws";
// ...

/* inside a lambda now: */
const client = new aws.runtime.DynamoDB.DocumentClient(/*opt-args*/);

[CyrusNajmabadi]

Working on a PR showing how this looks to consume downstream.

[CyrusNajmabadi]

Note: this current approach doesn't really work downstream (unless we make some cahnges). The effective problem is around closure serialization.

Consider how this is intended to be used from a downstream package. We would expect someone do the following inside a serialized-lambda:

const client = new aws.dynamodb.runtime.DocumentClient(); However, critically, we don't want to actually capture 'aws' as a module (it's enormous, and is already set to be excluded due to being a pulumi package). What we really want is that 'aws' is captured here as an object like:

with ({ aws: { dynamodb: { runtime: require("awssdk").dynamodb } } })

There are definite paths forward. But we have to be careful here in how we do things.

Tagging @lukehoban for visibility.

[CyrusNajmabadi]

note: this gives us a reasonable shaped API that a downstream consumer can use. However, there are severe closure-serialization complications in play (see main comments), which would have to be addressed before this coudl actually realistically be consumed.

[CyrusNajmabadi]

Note: this means that if a person requests a different sdk version, they'll get wrong TS typings. However, that's a known limitation of the awssdk. They even call it out here: https://github.com/aws/aws-sdk-js#known-limitations

There are a few known limitations with the bundled TypeScript definitions at this time:
Service client typings reflect the latest apiVersion, regardless of which apiVersion is specified when creating a client.

[CyrusNajmabadi]

Note: i put everything in a single file for the following reasons:

1. it gave us a centralized location to update whenever we need to make a change.
2. it's actually nigh-impossible to expose these 'runtime' properties from teh sub-module themselves. The reason for this is due to how typescript exports get rewritten. Specifically, ts will rewrite exports as:

function __export(m) {
    for (var p in m) if (!exports.hasOwnProperty(p)) exports[p] = m[p];
}
// Export members:
__export(require("./dynamodbMixins"));

So even if we tried to do the trick where the property is a 'getter', during re-export the getter will be called and thus we would end up trying to capture the awssdk submodule itself, instead of caturing the getter.

[CyrusNajmabadi]

@lukehoban Can you takea look when you get a chance. This approach works, but i'm curious how you feel about it. You can see how it can be used downstream with: pulumi/pulumi-cloud#645

[CyrusNajmabadi]

another option would be to just expose 'runtime' off of the root pulumi/aws module. 'runtime' would simply give you back require("aws-sdk"). So on the consumption side in pulumi cloud you'd say something like new aws.runtime.DynamoDB.DocumentClient() instead of new aws.dynamodb.runtime.DocumentClient(). I tend to actually think the former is a bit nicer as it's just a single entrypoint into the aws-sdk, and hten you have the entire normal surface area available to you. Thoughts @lukehoban ?

[CyrusNajmabadi]

I actually went with this path.

[CyrusNajmabadi]

I'm going to move forward with this. This is small enough that if we don't want this we can easily roll things back.

[lukehoban]

Thought I had hit send on this yesterday - but looks like I never submitted the review.

I like going with this simpler approach for now. But I do wonder if sdk is a better name given what common usage looks like.

[lukehoban]

Should we call it aws.sdk since it gets an instance of aws-sdk? It reads a little funny in usage to call this runtime.

[CyrusNajmabadi]

i definitely thought about that. But found it a bit strange to use the term 'sdk' inside an 'sdk' :) But if you do like that better, i think i'm totally ok with it. It also doesn't really need to be called 'runtime' since it is totally usable at deployment time as well.