my two cents, i prefer having the functions separated as it makes debugging/operations in the case of monitoring, finding errors in logs, etc significantly clearer. ie. if this is useful for some contexts/users it would be good to clarify the use case/benefit, and additionally make it an optional/explicit opt in.

@kapilt, the beauty of this is that nothing forces you to use the same entry point for multiple event types. But if you want to share an entry point across event types, with this you can.

Actually, by default the CloudFormation code emitted will still produce dedicated entry points, even though app.app can now handle them all. As such for existing configurations absolutely nothing would change.

that sounds interesting. do you have an example of what it looks like to use this feature? ie what changes for an app to designate that single function/designation endpoint. i see user_handler being weaved in unconditionally through the registrations, its a little unclear what populates that..

it looks sounds like the intent is is to allow something like this to work?

@app.sqs('/')
@app.schedule('rate (1 day)')
def do_work(event, context):
   return {'hello': 'world'}

I think I didn't explain this very well. :)

Generally, when I say "entry point" I'm referring to what's specified in the AWS Lambda Function as the "handler". In the HTTP / API Gateway case, that's app.app (which effectively calls chalice.app.Chalice.__call__, which then calls the right function in app according to its matching @app.route decorator). In case of other events, it's app.<name-of-function>, where <name-of-function> is whatever the name of the thusly decorated function is. With Chalice as of right now, this means each instance of the Lambda function configured in AWS can handle only one type of event, because the handler configured in AWS for each instance determines what type of event this instance can handle.

Now what my proposed change does is that you can have a single instance of the Lambda function configured with a handler of app.app that can handle all events that the functions defined in the app module can potentially handle, i.e., not just HTTP / API Gateway events but also all other event types supported by Chalice, provided there are functions defined in app and accordingly decorated using the usual Chalice @app decorators. You no longer absolutely need to have one instance per event type configured in AWS. Chalice will then receive all events through chalice.app.Chalice.__call__ and dispatch them to the appropriate, accordingly decorated functions in the app module.

For code in the app module absolutely nothing changes. You would not decorate the same function twice.

Does this make sense?