Thanks everybody! Code available, here; still need...
# multi-language-hackathon
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 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
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
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
. 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
for realtime/caching image/video cropping, thumbnails, etc. • Add an "Express" server wrapper to the
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]
🎉 5
Thanks for being our early adopter and going through it 🙂
🙂 1
I’ve noticed the “check in the generated code” too but I think it’s somewhat intentional. We have some large codebases that are auto-generated at Pulumi that served as an inspiration for the structure.
It turns out keeping the generated code can be useful for diff and troubleshooting, as well as code search.
It should be however super clear which code is generated… We need to improve there.
👍 1