Does `cargo-lambda` care about working directory?

[moranbw]

Say I have a project setup like this

• my_project
  • Cargo.toml
  • function_package
  • other_package

Cargo.toml looks like this:

[workspace]
members = ["function_package", "other_package"]

function_package is my actual function with lambda_runtime and lambda_http, etc. If I run cargo lambda watch from the function_package directory, cargo-lambda still finds other_function and tries to serve it:

ERROR available_functions={"function_package", "other_package"} detail="the default function route is disabled, use /lambda-url/:function_name to trigger a function call"

I would like to be able to call my function from routes like http://localhost:9000/route in development, as my frontend code has paths like /route referenced in HTML. I shouldn't have to make some sort of frontend exception "if dev" to add the /lambda-url/function_package onto all my URLs...

What I am trying to achieve is essentially what was seemingly implemented here: https://github.com/cargo-lambda/cargo-lambda/pull/398. However I don't think I am able to get this "default fallback" behavior, since the command is finding other_package, so my project is assumed to be multi-function.

I saw in other issues that I should be able to call something like cargo lambda watch --package function_package, but this does not seem to have the desired effect (if any effect, at all).

It is very possible that I am just missing something, apologies if so. Thanks for the response and the work on this useful tool.

[calavera]

Cargo Lambda's router is not as fully featured as the router you'd put in front of your AWS Lambda in production, like APIGW, so you cannot reference paths in either function directly because there is no mapping to know which function you want to invoke with you call /route.

What do you use in production to route to specific functions? This could be a new feature, but I'd like to think what's the best way to configure this for users like you.

[moranbw]

So I am just using a single function, which is using axum as the "app" to route to different things, but all self-contained.

I am just remapping my routes in dev and production with a small slice of code, so not a huge deal.

I was more surprised that when running cargo lambda watch from function_package directory, it for some reason thinks other_package is also something it should care about as an available_function, even though it is not a function. But perhaps this is more a matter of how the Cargo workspace works more than anything.

[calavera]

But perhaps this is more a matter of how the Cargo workspace works more than anything

Oh yeah, it's probably because other_package was detected as another binary package in the workspace. I'll think about how to improve all this. I'm currently working on some updates for the watch subcommand.

[calavera]

I just realized that we had a partial solution to this. You can use the flag --package to only watch one binary package in your workspace. However, the router had a bug that would prevent it from making the function accessible in the root path. I implemented a fix in #728 for this.

With that fix, if you have more than one binary packages in your workspace, you can use the --package flag to only watch for changes in your lambda function, and the function will be available in http://localhost:9000 because you're only watching one function.