SAM/Lambda: better support for API-based lambdas (APIGateway)

[JadenSimon]

Parent issue to track features or improvements regarding API-based lambdas.

Proposed new features:

• interactive mode

  • 1840

  • Start a server without a payload
  • Toolkit attaches a debugger whenever SAM CLI executes a function
  • Persist the server until the user closes out the session
• Support more options (port, logging, host, 'warm containers', etc.)

  • 2446

  • Toolkit may need to explicitly handle these options to work correctly
• A 'workbench' UI for sending payloads to the local API (to pair with interactive mode)
  • Could either be a notebook or tacked onto the SAM config webview
• More API Gateway resources in templates (e.g. V2)

  • 1489

  • AWS::Serverless::HttpApi
• "long lived" mode: #2535

General improvements and bug fixes:

• Uniform timeouts
  • Toolkit currently polls for a set amount of time to wait for the server to start
• Better discoverability
  • It's not obvious how to configure things for anything more complex than a 'HelloWorld' project
• Better logging during executions (less noise)
• Fail faster
  • Improve the experience by finding common issues with configurations (wrong path, wrong method, etc.)
• Less restrictions on payloads: #2478

[justinmk3]

Uniform timeouts

We could have very large timeouts if the Toolkit correctly handled VSCode debugger "Stop" button (assuming VSCode gives us a way to do this). Or as a workaround we could present a progress status w/ "Cancel" button.

[JadenSimon]

Yeah, many of the timeouts (in the run/debug flow) seem to be more like workarounds rather than features. We still want to know if a process is hanging, but I think it's best if we give the user the final choice in cancelling an operation. The automatic cancellation has caused a lot of issues.

[bryantqo]

I would also like to see being able to "attach" to an externally running instance of start-api i.e. in a terminal window I run sam local start-api -p 1234 -d 1235 and then be able to attach to that process on port 1235 without needing to define a payload. The debugging session would then remain "open" for all requests coming in. Additionally the ability for it to continue without a debugger attached is crucial. To that effect I would love it if:

1. For invokeTarget.type = "api" a nvokeTarget.logicalId would not be required
2. The debugging session to be smart enough to know how, based on the resulting function called, to properly connect to the correct source
3. Remove the api definition from being required
4. Do not automatically break on the entrypoint
5. Able to attach to an already running start-api

[justinmk3]

@bryantqo I added some notes to #2535 to try to capture your idea.