Working with AWS Lambda in Rider

Let’s continue our series on the new AWS Toolkit for Rider. As we saw last time, the AWS Toolkit is an open source plugin from AWS that makes it easier to work with .NET applications and AWS. It has several really useful features – credential and region management, AWS Lambda support and Cloud Debugging of ECS services.

Working with AWS Lambda in Rider

In this post, we’ll take a look at AWS Lambda support, including credential and region management.

In this series:

Working with AWS Lambda

The AWS Toolkit provides a number of features for working with AWS Lambda. Let’s start with a very helpful project template that creates a Hello World sample application that makes a very good starting point, although of course it’s possible to create a simple application using the AWS SDK NuGet packages.

AWS project template dialog

If you create the sample application, it’s worth pointing out a couple of things. Firstly, there’s a test project with a nice example of how to write a unit test for a Lambda handler, that works just like normal unit testing in Rider, and secondly, make sure you look at the template.yaml file in the Solution Items folder. This is the AWS CloudFormation configuration, which AWS uses as a blueprint for building your AWS resources. If you open this file, you’ll see that each resource gets a gutter icon, which you can use to locally run or debug the Lambda.

template.yaml showing run and debug gutter icon

The plugin will also add a gutter icon to the handler method in the C# file. And again, you can use this to locally run or debug the Lambda, as well as deploy it. (If you don’t see the icon, make sure it’s enabled in the settings, under Tools | AWS.)

Function.cs showing run and debug gutter icon

The project template will automatically create a run configuration to locally run and debug the Lambda, but you can easily create them manually by clicking the “plus” icon and selecting AWS Lambda. Configuring the run configuration is easy if you’ve already got a template.yaml file – simply select the named resource from the drop down. If not, then you can configure it manually, and Rider will offer completion for the handler name to make sure you get it right.

Handler name completion in run configuration dialog

You can also create remote run configurations here, but there’s an easier way which we’ll look at later.

There are a few things required before you can start running your Lambda. Firstly, we need to specify some credentials and select our region. The easiest way to do this is with the status bar widget. If we’ve already entered credentials with aws configure, we can select the profile here. If not, there’s a link to edit the file, and the plugin will update the list automatically. We can easily change the region from the list too.

Credential and region management status bar widget

Secondly, we need to specify the input that we’ll pass to our Lambda. We can enter some JSON directly in the run configuration dialog, with a small library of templates to help out with the format. Or we can point to a file, such as the events/events.json file from the project template.

Finally, we’re ready to run! Click the run button and the plugin will use the SAM CLI to build and then invoke the Lambda. This is done inside a Docker container, so the very first run might take a little while as the image is downloaded and the container is created. Once built, the Lambda is invoked, and the output is shown in the Build window.

Run tool window showing Lambda output

So running is great, but what about debugging? Well, that’s easy too! Set a breakpoint, click the debug button and the local run configuration is invoked, with debugger attached. Once debugging, all the normal Rider debugger features you’d expect are available, inside your Lambda handler, running inside the Docker container.

Locally debugging a lambda

So now we can build, test and debug our Lambda handler locally, what about deploying it?

There are a couple of ways of doing this. We can right click on the template.yaml  file and select Deploy Serverless Application. This will use the CloudFormation template to deploy to a CloudFormation Stack – either a new one, or updating an existing deployment. We must specify the S3 bucket we’re going to use to host the deployment artifacts – and we can create it straight from the dialog too!

Deploy serverless application dialog

Alternatively, we can use the AWS Explorer tool window, which lists the CloudFormation Stacks, ECS Clusters and Lambdas visible to our connection profile. We can use the Create new AWS Lambda item in the Lambda context menu to open a dialog that allows more manual configuration of the deployment – name, description, handler (again with completion) memory limits, timeouts and so on.

Create new Lambda dialog

Once we’ve got the Lambda deployed, the context menu offers useful features – jump to the source of the handler, update configuration or the code in the S3 bucket, delete the Lambda, and of course, we can also invoke the Lambda remotely. This creates a new, temporary run configuration – simply provide some new input as a file or text, and the invoked Lambda output will be shown in the Build tool window.

Put together, we’ve got a comprehensive set of tools for working with AWS Lambda – you can create, locally run and debug, deploy and remotely run a Lambda, all without leaving Rider.

Next time, we’ll take a look at Cloud Debugging of ECS services. Until then, install the AWS Toolkit for Rider by searching for “aws” in the Marketplace tab of the Plugins settings page, and let us know how you get on!

image description