A more complex use case.

[drusellers]

Assuming my project needs more than one endpoint. How does crowbar handle that? Do I use a workspace with N subcrates each building a liblambda? Any guidance on this is much appreciated.

[iliana]

Had a quick look at the code, I don't think it supports this right now, but I don't think it'd be too difficult to support it either -- at line 292, "handler" could possibly be an optional string passed into the macro.

[drusellers]

Right on. I'm just trying to noodle out how I would build out an AWS Lambda application and being able to have one crate hold multiple handlers seems a bit nicer than a workspace full of crates. But I'm just learning Lambda so I wasn't sure.

[iliana]

You're definitely right, if only because your zip file would be a lot smaller :)

Since all the handlers need to be contained in one of the cpython macros, it's not as simple as just having multiple lambda! macro invocations in your crate.

I've been thinking about this as the layout of the macro, sorta similar to match. I haven't implemented it and I'm not yet certain it's possible.

lambda! {
    "handler" => |(event, context)| Value::String("it's a handler"),
    "other_handler" => |(event, context)| Value::String("it's an other handler"),
};

(with the lambda!(f) handler expanding to this layout so we don't break existing code.)

[drusellers]

Out of pure ignorance, is there a reason that you can't use attributes to make this happen? Rocket uses this approach which I enjoy quite a bit.

#[lambda]
pub fn name (event: Event, context: Context) -> Result<()> {
// do stuff
}

[iliana]

I'll see if that's possible in stable / Macros 1.1 -- the thing I worry about is that I think all the module exports have to be inside a py_module_initializer! macro.

I'll play around with it when I get a chance and see if we can do something clever. (Implementation suggestions are also welcome.)

[sunjay]

How about just having the first parameter in lambda! be the name of the handler? I would prefer that over the match syntax you suggested. :)

[iliana]

@sunjay Take a look at the macro definition — all of the function names in the module need to be within the py_module_initializer! macro which makes having separate macros for separate handlers pretty much impossible (unless there's some trick I'm not aware of with macros).

(This is assuming you want more than one handler in the same module.)

[sunjay]

@ilianaw Yes that makes sense. Thanks!

[iliana]

This should be fixed by #9 when it lands.

[iliana]

Fixed in fcbdffd