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.
In this post, we’ll take a look at AWS Lambda support, including credential and region management.
In this series:
- Introducing the AWS Toolkit for Rider
- Creating, debugging and deploying AWS Lamdba from Rider (this post)
- ECS Cloud Debugging in Rider
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.
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.
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.)
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.
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.
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.
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.
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!
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.
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!
Subscribe to a monthly digest curated from the .NET Tools blog:
