AWS has introduced a new “Application Builder” within its toolkit extension for Visual Studio Code (VS Code), the idea being to simplify getting started with building and debugging applications for its Lambda serverless offering.

The new integration promises “easy access buttons for one-click build, deploy-to-cloud, local or remote invoke, and integration with the AWS Infrastructure Composer.”

Getting started with the Application Builder requires several steps, the first of which is to install VS Code and the massive AWS Toolkit extension, which has more than 2.5 million downloads and is updated frequently (five updates last month, for example). Use of the Toolkit requires sign-in with a suitable account and authentication method. We used an AWS IAM (Identity and Access Management) account.

The latest version now provides an Application Builder section when the extension is selected in the VS Code explorer. Developers can choose Walkthrough, to be guided through creating a new application, or links to existing applications.

Once Walkthrough is selected, there are three further setup tasks to check. These are the AWS CLI (Command Line Interface), the SAM (Serverless Application Model) CLI, and Docker. The Lambda functions will run locally in a Docker container.

The next step is to choose an application template. We tried Application Builder on an M1 Mac, and chose a C# Hello World SAM application for a quick test, but others on offer include a REST API, a file processing application triggered by S3 events, and for advanced use cases, the AWS visual Infrastructure Composer.

It is the often the case that features presented by vendors as straightforward turn out to have unexpected complications. In this example, the first issue we hit was a message “Error: Running AWS SAM projects locally requires Docker. Have you got it installed and running?” This was odd because the docker daemon was running and the docker command line was working. The issue is discussed here and dates back two years. It arises when Docker is installed via Docker Desktop; there are several possible fixes of which the easiest is a setting in Docker Desktop to “allow the default Docker socket to be used.” A further oddity is that this was already checked; we tried unchecking, restarting Docker, then checking and again restarting the daemon, and it then worked.

The sample application includes a Lambda function and also a test project. It should be possible to debug the Lambda function, by going to the AWS Toolkit explorer, right-clicking the function, and choosing Local invoke and debug configuration. This opens a panel where a default debug config can be loaded and then invoked. We did this, the function ran in a container, but a breakpoint in the code was not hit. There was also a message: “the vsdbg debugger does not currently support the arm64 architecture.” 

This is another curious thing: the docs reference this message and point to a dotnet GitHub issue for further details. But the issue is closed with the message that “O#/C#/Dev Kit all now support linux ARM.” Note that we were able to debug the function by debugging the generated test, but in this case it does not run in a container.

Not having time to dig deeper, we tried again with a new Python 3.12 application with identical functionality, and it launched the container and worked first time.

AWS has its own walkthrough of the new features, with additional steps for deployment and remote invocation and logging.

Despite some snags, the Application Builder for serverless applications looks useful though it is more of a getting started tool and developers will soon need to dive into the Lambda documentation.