Thanks everybody! Code available, here; still needs clean up, some permisisons work, and improved names: Three components for AWS: 1. Cron/Scheduled lambda function 2. Cloudfront + S3 3. Lambda Backed REST Proxy API https://github.com/ajhool/pulumi-aws-apigateway-lambda Feedback: Overall, worked amazingly well -- naturally skeptical of heavily autogenerated code, but experienced no problems related to the autogen engine, which is really incredible. 1. Building the multi-lang components required a few steps. It would be very helpful if I could alter lib code and run

pulumi up

to test the multi-lang library without (manually) building the SDKs. Would help to iterate quickly and isolate issues related to

schema.json

2. In the beginning, it wasn't clear to me which files I should edit and which files I shouldn't edit. Working it out from the boilerplate and experimentation wasn't ~ that ~ hard but it took some time to be confident. If possible autogen code should be gitignorable and ideally placed in folders that (1) are clearly marked and (2) contain zero files that should be edited by the user. Now that I've worked with it for a few days, I see that generated / editable folders & files already are fairly well separated, but in the beginning it felt like there was a lot to learn; possibly due mainly to the search+replace journey. 3. Single command for multi-lang build & deploy. 4. Schema for resource arguments - For "CloudfrontS3", it would be nice to have opinionated defaults for the Cloudfront distribution but also to expose the

CloudfrontArgs

from Typescript. AFAIK the pulumi-resource-aws schema [1] contains definitions for resources (eg. Cloudfront) but not definitions for resource inputs (eg. CloudfrontArgs). I was able to find those types in typescripts but didn't use them because it would have been a lot to work into the schema -- types + nested types. Also, the pulumi-resource-aws schema wasn't mentioned in the boilerplate repo. 5. eslint was finicky in VSCode for me and I was frequently unable to see types in

examples/simple/index.ts

. This might be due to how

yarn link

works. There were a few build/link issues like this that were difficult to troubleshoot and made it difficult to know what code was deploying Possible next steps for the code: • Combine all components into an API + Scheduled Tasks + Static content Cloudfront + S3 service • Make Cloudfront + S3 a more sophisticated media stack with an MediaHandler Function to the cloudfront distribution as a

lambda@edge

for realtime/caching image/video cropping, thumbnails, etc. • Add an "Express" server wrapper to the

ApiLambda

so that express users can deploy a stateless Express server to lambda by pointing it to existing express code. RDS compatibility can take some work, though. Also true for other popular frameworks like Django. Other thoughts: • The majority of the core code that I need to write for the components was very similar to the code that I had written when using pulumi to deploy infrastructure, so it mostly felt familiar except for the schema. [1] https://github.com/pulumi/pulumi-aws/blob/master/provider/cmd/pulumi-resource-aws/schema.json

Thanks for being our early adopter and going through it 🙂

We can start by adding this file everywhere https://github.com/pulumi/pulumi-azure-native/blob/master/.gitattributes