cargo deploy to deploy several functions at once

[fancywriter]

Would be nice to have the feature to deploy several functions at once (as it is done in this example https://github.com/softprops/serverless-aws-rust-multi ). Also would be nice to have ability to put some sort of prefix/suffix to function names.

I have tried with serverless plugin first, but looks abandoned, doesn't work - tries to compile my code with ancient version of Rust and fails. cargo lambda at least compiles and builds fine. Also deploy of just one function works fine. However, scaling it to several functions becomes boilerplate.

Would be nice to have some sort of descriptor as part of build file...

What do you think? Perhaps I can try to contribute when I have some free time.

[calavera]

that would be definitely a nice feature. I'm not sure how it'd work from the top of my mind. Feel free to put something together, we can iterate on how it works.

[calavera]

however, it might be better to put a template/example together on how to do that with the AWS CDK, since it should be able to manage state better than just one command.

[fancywriter]

Yes, good point, I didn't really tried approach with AWS SAM - probably worth trying and make cargo to complement this, no to replace what is already there.

[calavera]

Yeah. I tried to integrate cargo-lambda with SAM, and I bumped into an issue on Windows, you can read more in #77.

This CDK construct for Rust functions use cargo-lambda already, and it works really well: https://github.com/rnag/rust.aws-cdk-lambda

My idea was to create a template that could allow people to do something like cargo lambda new --tempate cdk-template and they'd get a project setup with a cdk stack for multiple functions. The --template flag is already there, but the logic to process template might need adjustments.

[chadbrewbaker]

I would use a Makefile for this and make an example of one lambda that calls another? Also need to support localhost testing of chained lambdas.

[fancywriter]

@chadbrewbaker what have I did for now and works fine for small projects, but probably something better could be done for bigger. I am using serverless framework and created subdirectory in my project rust (you can pick better name) with the following structure.

rust/
├── func1
│   ├── Cargo.toml
│   └── src
│       └── main.rs
├── func2
│   ├── Cargo.toml
│   └── src
│       └── main.rs
├── Cargo.lock
├── Cargo.toml
└── common
    ├── Cargo.toml
    └── src
        └── lib.rs

Content of rust/Cargo.toml:

[workspace]
members = ["func1", "func2", "common"]

You can create as many functions func1, func2, ... as you want. And I put common reused code in subproject common (again, you may have more then just one).

All is built with cargo lambda build --arm64 --release, after that in each directory I have the binary file rust/target/func1/bootstrap. It's always called bootstrap, I am packing it as it is into zip file:

zip -j target/lambda/func1.zip target/lambda/func1/bootstrap
zip -j target/lambda/func2.zip target/lambda/func2/bootstrap

And for the function definition (serverless.yml) I added the following for each function:

handler: provided
runtime: provided.alt2
package:
  artifact: rust/target/lambda/func1.zip

Feel free to use such script or adapt to your Makefile.

As for calling "one lambda from another", not sure what you mean - for sure you can make it with AWS SDK API, but I guess you would prefer to share the code in the library and reuse in different lambdas - it will slightly bigger binaries, but much better performance.

[calavera]

thanks for the write up @fancywriter! I'm going to close this issue since as you mention, a higher level abstraction is better suited for this.

As a note to your comment, if you add --output-format zip to cargo lambda build, you can skip the additional zipping. The zipped functions will be in rust/target/lambda/func1/bootstrap.zip

[fancywriter]

The issue is that --output-format zip works only for one main source... it didn't work when I have multilevel project as far as I remember... or the filename was wrong.

I am out of ideas for now (and busy with other things), but If I come up with better idea, I will share it in pull request, sure.