.NET on AWS – Data Persistence using RDS

Introduction

In previous Post on this topic, we started by publishing a .NET Core API to AWS Lambda function.

Today, we will extend the API and add more functionality to it (database operations) and then redeploy it to AWS Lambda and see how it goes.

Database Setup

We’ll be using Postgres database (AWS RDS Service) for data persistence. I’ve written few posts on this topic, which you check and these will provide you all the background information you need to work with PostgreSQL database in .NET Core:

• AWS Relational Database Service (RDS) – PostgreSQL in Cloud
• Fun with SQL using Postgres and Azure Data Studio
• Fasten your Data Layer with Dapper (A .NET Micro ORM)

Also, I will be using Dapper as an ORM, but feel free to use EntityFramework if you want to.

So, I have setup a PostgreSQL (RDS) database and created products and users tables as shown below:

As you can see that I’ve also populated some initial data in the database.

.NET Core API with RDS Database

On the .NET Core Application side, I have added two new projects (.NET Standard class libraries) and installed the Dapper NuGet package to dempApp.Data project as shown below:

demoApp.Data project will also house the Repositories, which will be injected and used in the controller.

We could have added all these items in the API project, but having separate projects (libraries) will help us with separation of concern and easy to manage complexity when application grows.

Dependency Injection

In Startup.cs file, repositories are registered to Dependency injection framework and these will be injected to controller automatically via constructor injection:

Web API Controller (Products)

Following is a very simple ProductsController which uses the ProductsRepository to read data from RDS database and it this to the calling client:

We can run the application locally and can test if controller returns the data as expected:

UsersController and Repository

Similar to Products, I’ve also added UserRespository and UsersController to manage Users. However, this time we are adding more Actions (CRUD operations) to this controller:

Once again, we can test the application locally and following picture shows that users data is also retrieved successfully.

Now, if we want, we can test all the actions/methods locally as needed and once done, we can publish the application to AWS from visual studio:

Publish the App

Following screen shows the publish operation from visual studio. Please check previous post if you need more information about these steps:

Once, our application is published, we can test and see that the endpoints are working as expected:

Testing Products Controller

Testing Users Controller

Adding a New User

New user is added successfully:

You can test all other operations such as update, delete etc:

At this point, we have some simple endpoints which provides data retrieval and persistence. You can download the source code from this git repository.

CloudWatch Logs

CloudWatch is an AWS Service, which watches over what you are doing in cloud. When we deployed our API to AWS Lambda, it also setup CloudWatch logging for us and we can simply use it.

The following picture shows the Log group, which is related to the our .NET Core Web API:

We can click the Log group name and it will show us log streams and we can check these logs to see how our application is performing:

Here are the API operations I performed:

1. TokenController (Get)
2. TokenController (Get)
3. ProductsController (Get)
4. UsersController (Get)
5. UserController (Post)
6. UsersController (Get)

TokenController.Get (1st call)

TokenController.Get (2nd call)

ProductsController.Get (3rd call)

UsersController.Get (4th call)

UsersController.Add (5th call)

UsersController.Get (6th call)

CloudWatch has many great features. It provides you different matrices. You can setup detailed monitoring of your workloads. It is also a good tool for debugging, investigation and troubleshooting purposes. We will cover more of CloudWatch in later posts. For now, you can get yourself familiarize with it and see how API requests are doing in terms of memory usage, performance etc.

Summary

In this post, we extended our .NET Core API to work with PostgresSQL database (RDS). We created few controllers, repositories and DI setup to work with databases and this part is still in a blissful ignorance of underlying platform and our .NET API doesn’t require significant changes when we published it to AWS.

We’ll cover more use cases and example of Running .NET on AWS in upcoming posts. Let me know if you have some questions or comments. Till next time, Happy Coding.