Unit Coding

Build a Todo application with Blazor and C#

Oscar Montenegro — Mon, 31 Mar 2025 16:27:51 GMT

"Hi there! Today, we’re going to build a to-do application—but with a twist. Unlike the typical to-do apps you might find in countless tutorials, this one will feature a sleek interface, smooth animations, and one or two more additional features beyond a regular to-do application.

Having said that I have to mention that this application does not intend to be flawless or a production ready product, but a nice looking and fun to use project for you to get started if you desire to learn blazor or maybe you already know but you like coding fun stuff, also the application design is not mine while I coded the app entirely from the markup, the styling and the C# code I got the design from Figma while looking for an amazing interface and I found it, so all credit goes to its author “itcenter uchquduq”. Ready to get started? Let’s dive in and bring this project to life!"

Give the project a start on Github

If you come across an issue, or while coding along with the article, something doesn’t look like it should, I recommend you to take a look at the code on Github to make sure your code is similar to mine. Also please if you enjoy coding this app give the project a start on Github to know that you liked it and create more projects like this one.

GitHub - Osempu/TodoApplication: A beautiful looking to-do application made with Blazor and C#

A beautiful looking to-do application made with Blazor and C# - Osempu/TodoApplication

GitHubOsempu

What You’ll Learn

Build a Blazor WebAssembly App: Start from scratch and structure components like a pro.
Craft Reusable UIs: Design components like TodoHeader and TodoComponent with event handling and data binding.
Persist Data with local storage: Save tasks and theme preferences so nothing gets lost.
Style with Flair: Implement a responsive dark/light theme using CSS variables and Line Awesome icons.
Animate with CSS: Add slick transitions for adding/removing tasks (because details matter!).
Filter Tasks Dynamically: Toggle between “All,” “Active,” and “Completed” tasks with real-time updates.

Create a new Blazor application

First, let’s start creating a new dotnet Blazor application using the dotnet cli with the following command.

dotnet new blazorwasm -o TodoApplication

This will create a new Blazor WebAssembly application with some boilerplate code that we will get rid of to start our application from scratch.

Get into your new project folder and open Visual Studio code with the following commands (you can use Visual Studio if you prefer; it will work as well)

cd TodoApplication

code . -r

Now, let’s proceed to start removing some of the boilerplate codes so we can start working on our application. Go ahead and delete the Counter and Weather pages under the Pages folder. Now remove the NavMenu.razor component and NavMenu.razor.css from the Layout folder and in the MainLayout.razor component, remove the sidebar so the code looks like this.

@inherits LayoutComponentBase

    
        
            @Body

 
 /*remove the styling for the article element*/
  .top-row, article {
      padding-left: 2rem !important;
      padding-right: 1.5rem !important;
  }

This will remove the sidebar and the top navbar with the About link so we can have a nice white canvas to start designing. Now, your application should look something like this. Nothing but the welcome text.

Let’s begin with the simplest implementation

We want to start by quickly implementing the simplest solution for the todo application; for that, we will create all the code in the home.razor file, and once done, we will move forward to create the components and add some complexity.

Remove Bootstrap and default styling

Let’s begin by removing the reference to the bootstrap library in the index.html file and in the app.css file, we will remove the undesired padding in the .content class, and we will also remove the margin and padding to the HTML and body elements.

/*app.css*/

/*Lets reset the styling for theese elements*/
html, body {
    ...
    margin: 0px;
    padding: 0px;
    box-sizing: border-box;
}

/*Remove this class to avoid clashing with our own content implementation*/
.content {
    padding-top: 1.1rem;
}

Create a Todo model

Now, let’s move on to create our to-do model that will hold the to-do name and whether it is done or not, so let’s add some default values for each of the properties.

namespace TodoApplication.Models;

public class Todo
{
    public string Title { get; set; } = string.Empty;
    public bool IsDone { get; set; } = false;
}

This will be our main class, which will be used through our application.

Adding just the very basics

For our first version, we will not be creating any component or adding any styling to the application; we will only rely on the HTML elements and some C# code.

/*Home.razor*/
Todo Application


	
		
	    
	        TODO
	    

		
		    
		
		    @foreach(var todo in todos) {
		        
		            
		                 
		                @todo.Title
		            
		            x
		        
		    }

We can see that the application is divided into three sections.

The header, which will contain the application name
The form by means of which we will create the tasks consists of a text input that we will bind its value to a string called todoTitle that will be the title for newly created tasks. Also, this input has a bind:event on the oninput event to make sure we get the latest value inserted in the input, otherwise, we will always get the last value, and the first input will always be a blank string, and we don’t want that to happen. Lastly, the onkeydown event will trigger the function AddTodo that will check if the pressed key is the Enter key and then will create the new task.
Finally, the tasks list(the code within the foreach loop) will contain every task created with a checkbox bound to the IsDone property of the task. The label will display the Todo title, and finally, we have a button to remove the selected task.

For the C# code, we have the following:

@code {
	private List todos = new List();
	private string todoTitle = string.Empty;
	private void AddTodo(KeyboardEventArgs e) {
	    if (e.Key == "Enter" && !string.IsNullOrWhiteSpace(todoTitle)) {
	        var newTodo = new Todo() { Title = todoTitle };
	        todos.Add(newTodo);
	        todoTitle = string.Empty;
	    }
	}
	
	private void RemoveTodo(Todo todo) {
	    todos.Remove(todo);
	}
}

We have a list of Todo elements being this the todo list, we have a string value for the input that will create the new task. Then we have the AddTodo function that, as we mentioned before, passes the KeyboardEventArgs as a parameter, and inside, we check if the pressed key is the Enter key, and if it is, it will create a new Todo using the value from the todoTitle variable and will remove the value from todoTitle variable to reset the input element. Lastly, the RemoveTodo function, as the name suggests, removes the selected task. This code can be in the same Home.razor file for now right below the markup.

With this, we have our application working, we can create a task, mark it as completed, and remove it from the list. Now, we will take it to the next level, adding styling and some more features.

Leveling up our application

Now, it’s time to enhance our to-do application by creating components, adding awesome styling, and adding the necessary code.

First, let’s create the header component containing the application title, an icon to toggle the theme, and the form to input the todo title.

Creating the Header component

Start by abstracting the markup and code from the header into its own component, so start creating a folder named Components , and there you will be storing every new component that will be needed. Now, create a new component named TodoHeader.razor Here, you will move the corresponding markup and code to work as intended, but before adding any code, let’s write down what will be the responsibilities of the header component.

The header component will:

Display the application title
Display an icon to indicate whether the application is in dark or light mode.
Emit an event to toggle between light or dark mode
Display an image for dark mode and another one for light mode

So having said that, let’s move to the new header component, and also let’s add the new code for the features listed above.

/*TodoHeader.razor*/
@using Blazored.LocalStorage
@inject ILocalStorageService localStorage


    @AppTitle
    


@code {
    [Parameter]
    public string AppTitle { get; set; } = string.Empty;
    [Parameter]
    public EventCallback ToggleState { get; set; }
    [Parameter]
    public string LightIcon { get; set; } = string.Empty;
    [Parameter]
    public string DarkIcon { get; set; } = string.Empty;
    private bool isDarkMode = false;
    private string icon = string.Empty;

    protected override async Task OnInitializedAsync() {
        isDarkMode = await localStorage.GetItemAsync("IsDarkModeEnabled");
        icon = isDarkMode ? LightIcon : DarkIcon;
    }

    private async Task Toggle() {
        isDarkMode = !isDarkMode;
        await localStorage.SetItemAsync("IsDarkModeEnabled", isDarkMode);
        icon = isDarkMode ? LightIcon : DarkIcon;
        await ToggleState.InvokeAsync(isDarkMode);    }
}

Let’s start breaking down the code from top to bottom. First, you will see a reference to a library named Blazored.LocalStorage , which will help you manage the local storage in your application, allowing you to store the state of your theme application even after reloading it. We will also use it to store our tasks. Below, we are injecting the local storage service and naming it localStorage . This will allow you to use the service in your component.

Below is all the markup needed for the header component, there’s a wrapper container with a class named header, and inside of it is an h1 tag that’s holding the application title in a property, and below is the theme icon which will work as a toggle button to change between light and dark mode.

Then, at the top of the code section, we have some properties. The first one is the application title, followed by the ToggleState event callback that will be invoked when clicking on the toggle theme icon. The DarkIcon and LightIcon will be used to specify the icon used for the dark and light theme, as the properties before this will be passed as parameters so they can be configured when calling the header component. The isDarkMode variable will be used to check if the dark mode is active or not, and similarly, the icon variable will be used to get and set the current icon in the header.

We call the onInitializedAsync so that when the component is initialized, it checks for the IsDarkModeEnabled value in the local storage to set that in the isDarkMode variable. Based on that, it will set whether the icon displayed should be a light or dark icon. Lastly, the Toggle function will set the isDarkMode to the opposite value, then store that in the local storage, change the icon based on the variable, and invoke the ToggleState event callback, passing back the negated isDarkMode value.

Style for the header component

/*TodoHeader.razor.css*/
.header {
    display: flex;
    align-items: center;
    justify-content: space-between;
    width: 100%;
}

i.la-sun, i.la-moon {
    font-size: 3rem;
    color: #fff;
}

i.la-sun:hover, i.la-moon:hover {
    color: #ccc;
    cursor: pointer;
}

.app-title {
    font-size: 3rem;
    margin: 20px;
    margin-left: 0px;
    color: #FFF;
    text-align: left;
    user-select: none;
    letter-spacing: 1rem;
}

Create a new file at the same level as the header component file and name it TodoHeader.razor.css in this file, we will define the styling for this component.

Adding more styling to the `app.css` file

The following styling should be added in the app.css file to apply some global stylings to your application, I recommend you remove what you have in the file and add the styles below to avoid confusion. You will notice there are references to two images in the :root and .dark classes, those images can be downloaded from the repository of this project on my GitHub page, or you can use your own.

html, body {
    font-family: 'Roboto', Helvetica, Arial, sans-serif;
    margin: 0px;
    padding: 0px;
}

h1:focus {
    outline: none;
}

:root {
    /*Default Light Theme*/
    --primary-color: #fff;
    --secondary-color: #fafafa;
    --text-color: #000;
    --border-color: #eee;
    --accent-color:  linear-gradient(190deg, rgba(85, 150, 255, 0.8) 0%, rgba(172, 45, 235, 0.8) 100%);
    --bground-img: url('../img/bground.jpg');
    --accent-secondary-color: #f0f7f4;
    transition: background 0.3s;
}

.dark-theme {
    --primary-color: #25273d;
    --secondary-color: #171823;
    --text-color: #fff;
    --border-color: #5a5757;
    --bground-img: url('../img/bground-dark.jpg');
    --accent-color:  linear-gradient(190deg, rgba(80, 255, 100, 0.8) 0%, rgba(50, 150, 255, 0.8) 100%);
    --accent-secondary-color: #494C6B;
    transition: background 0.3s;
}

#blazor-error-ui {
    background: lightyellow;
    bottom: 0;
    box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
    display: none;
    left: 0;
    padding: 0.6rem 1.25rem 0.7rem 1.25rem;
    position: fixed;
    width: 100%;
    z-index: 1000;
}

#blazor-error-ui .dismiss {
    cursor: pointer;
    position: absolute;
    right: 0.75rem;
    top: 0.5rem;
}

.blazor-error-boundary {
    background: url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iNTYiIGhlaWdodD0iNDkiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIG92ZXJmbG93PSJoaWRkZW4iPjxkZWZzPjxjbGlwUGF0aCBpZD0iY2xpcDAiPjxyZWN0IHg9IjIzNSIgeT0iNTEiIHdpZHRoPSI1NiIgaGVpZ2h0PSI0OSIvPjwvY2xpcFBhdGg+PC9kZWZzPjxnIGNsaXAtcGF0aD0idXJsKCNjbGlwMCkiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMzUgLTUxKSI+PHBhdGggZD0iTTI2My41MDYgNTFDMjY0LjcxNyA1MSAyNjUuODEzIDUxLjQ4MzcgMjY2LjYwNiA1Mi4yNjU4TDI2Ny4wNTIgNTIuNzk4NyAyNjcuNTM5IDUzLjYyODMgMjkwLjE4NSA5Mi4xODMxIDI5MC41NDUgOTIuNzk1IDI5MC42NTYgOTIuOTk2QzI5MC44NzcgOTMuNTEzIDI5MSA5NC4wODE1IDI5MSA5NC42NzgyIDI5MSA5Ny4wNjUxIDI4OS4wMzggOTkgMjg2LjYxNyA5OUwyNDAuMzgzIDk5QzIzNy45NjMgOTkgMjM2IDk3LjA2NTEgMjM2IDk0LjY3ODIgMjM2IDk0LjM3OTkgMjM2LjAzMSA5NC4wODg2IDIzNi4wODkgOTMuODA3MkwyMzYuMzM4IDkzLjAxNjIgMjM2Ljg1OCA5Mi4xMzE0IDI1OS40NzMgNTMuNjI5NCAyNTkuOTYxIDUyLjc5ODUgMjYwLjQwNyA1Mi4yNjU4QzI2MS4yIDUxLjQ4MzcgMjYyLjI5NiA1MSAyNjMuNTA2IDUxWk0yNjMuNTg2IDY2LjAxODNDMjYwLjczNyA2Ni4wMTgzIDI1OS4zMTMgNjcuMTI0NSAyNTkuMzEzIDY5LjMzNyAyNTkuMzEzIDY5LjYxMDIgMjU5LjMzMiA2OS44NjA4IDI1OS4zNzEgNzAuMDg4N0wyNjEuNzk1IDg0LjAxNjEgMjY1LjM4IDg0LjAxNjEgMjY3LjgyMSA2OS43NDc1QzI2Ny44NiA2OS43MzA5IDI2Ny44NzkgNjkuNTg3NyAyNjcuODc5IDY5LjMxNzkgMjY3Ljg3OSA2Ny4xMTgyIDI2Ni40NDggNjYuMDE4MyAyNjMuNTg2IDY2LjAxODNaTTI2My41NzYgODYuMDU0N0MyNjEuMDQ5IDg2LjA1NDcgMjU5Ljc4NiA4Ny4zMDA1IDI1OS43ODYgODkuNzkyMSAyNTkuNzg2IDkyLjI4MzcgMjYxLjA0OSA5My41Mjk1IDI2My41NzYgOTMuNTI5NSAyNjYuMTE2IDkzLjUyOTUgMjY3LjM4NyA5Mi4yODM3IDI2Ny4zODcgODkuNzkyMSAyNjcuMzg3IDg3LjMwMDUgMjY2LjExNiA4Ni4wNTQ3IDI2My41NzYgODYuMDU0N1oiIGZpbGw9IiNGRkU1MDAiIGZpbGwtcnVsZT0iZXZlbm9kZCIvPjwvZz48L3N2Zz4=) no-repeat 1rem/1.8rem, #b32121;
    padding: 1rem 1rem 1rem 3.7rem;
    color: white;
}

.blazor-error-boundary::after {
    content: "An error has occurred."
}

.loading-progress {
    position: relative;
    display: block;
    width: 8rem;
    height: 8rem;
    margin: 20vh auto 1rem auto;
}

.loading-progress circle {
    fill: none;
    stroke: #e0e0e0;
    stroke-width: 0.6rem;
    transform-origin: 50% 50%;
    transform: rotate(-90deg);
}

.loading-progress circle:last-child {
    stroke: #1b6ec2;
    stroke-dasharray: calc(3.141 * var(--blazor-load-percentage, 0%) * 0.8), 500%;
    transition: stroke-dasharray 0.05s ease-in-out;
}

.loading-progress-text {
    position: absolute;
    text-align: center;
    font-weight: bold;
    inset: calc(20vh + 3.25rem) 0 auto 0.2rem;
}

.loading-progress-text:after {
    content: var(--blazor-load-percentage-text, "Loading");
}

Calling the header component from the home page

Now, you can remove the old markup to display the app title and call the header component instead. You will have to pass the name of the application to the AppTitle parameter as well for the icons and for the ToggleState event callback,k you will pass the function that will be called when this event is triggered.

The OnInitializedAsync function was added to look for the stored appTheme value in the local storage. If it does not exist, then the default value will be an empty string. The ToggleTheme function receives a bool as a parameter, as you can see in the TodoHeader component, we are not passing any argument, so where is this value coming from? Well, it turns out that the ToggleState event callback is of type bool, and when you invoke it in the header component, you pass back that bool value when calling this line of code in the Toggle function await ToggleState.InvokeAsync(!isDarkMode) So that’s where that value is coming from, and what this function does is that it sets the app theme to dark-theme or to blank string depending on the flag it receives and then stores that value in the local storage. Now, this was,y you can have your component in place and ready to work, but before that let’s add some more styling to the application also you need to install some libraries to make everything work.

/*Home.razor*/
 /*Dont forget to add this class to get the theme toggle working*/
    
        
            
        
	    
   ...
   
   @code {
   ...
      private string appTheme = string.Empty;

	  protected async override Task OnInitializedAsync() {
      //Get Theme values from Local Storage
      appTheme = await localStorage.GetItemAsync("appTheme") ?? "";
    }
    ...
    private async Task ToggleTheme(bool isDarkTheme) {
      appTheme = isDarkTheme ? "dark-theme" : "";
      await localStorage.SetItemAsync("appTheme", appTheme);
    }
    ...
  }

Styles for the home page

There's not much to say here; just adjusting the header layout and adding color to the background.

/*Home.razor.css*/
* {
    box-sizing: border-box;
}

.app-container {
    position: relative;
    background-color: var(--secondary-color);
    height: 100vh;
}

.hero {
    display: block;
    position: absolute;
    height: 40vh;
    background: var(--accent-color), var(--bground-img);
    background-size: cover;
    background-position: center 40%;
    mix-blend-mode: normal;
    width: 100%;
    min-width: 500px;
    transition: all .3s ease;
}

.footer {
    position: relative;
    display: block;
    height: 40vh;
    width: 100%;
}

.container {
    flex-direction: column;
    align-items: center;
    position: relative;
    margin: 50px auto;
    display: flex;
    width: 40%;
    transition: 
    width 0.5s ease, 
    height 0.5s ease, 
    font-size 0.5s ease, 
    transform 0.5s ease;
}

.remove-icon:hover {
    cursor: pointer;
}

.body-container {
    width: 100%;
}

@media only screen and (max-width: 1200px) {
    .container {
        width: 60%;
        transition: all .3s linear;
    }
}

@media only screen and (max-width: 720px) {
    .container {
        width: 80%;
        transition: all .3s linear;
    }
}

Using Line Awesome icons

To be able to use the sun and moon icons in our application, we will be using the Line Awesome icons library, which is free, and you can start using it by loading it from CDN, as shown below. Go to your index.html file and place this link above the head tag.

...
	link rel= "stylesheet" href= "

...

Install `Blazored.LocalStorage` NuGet package

To have the local storage working in our application, we will use a third-party library, which you can install using the command below.

dotnet add package Blazored.LocalStorage

Then, go to your Program.cs file and register your service there.

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
builder.Services.AddBlazoredLocalStorage(); //This is where you should place it.

await builder.Build().RunAsync();

And add the Blazored.LocalStorage reference in the Home page and TodoHeader component like shown below.

/*Add these two lines to both Home.razor and TodoHeader.razor*/
@using Blazored.LocalStorage
@inject ILocalStorageService localStorage

Now you can run your application, and it should look something like this.

Styling the todo input

Let’s make the to-do input element bigger and adjust it to the layout. Add the code below to the Home.razor.css and then take a look at the changes.

/*Home.razor.css*/
/* Todo Text Input */
input[type="text"] {
    padding-top: 15px;
    padding-bottom: 15px;
    padding-left: 30px;
    padding-right: 30px;
    margin-bottom: 20px;
    border-radius: 4px;
    width: 100%;
    border: none;
    font-size: 1.2rem;
    color: var(--text-color);
    background-color: var(--primary-color);
}

input::placeholder {
    font-size: 1.2rem;
}

Now it looks incredible and gives the application a fresh and professional look by making the font and the placeholder bigger as well as adjusting the size of the container.

For the todo form we will not be making it a component as the functionality is not that much so creating a component just for the sake of doing it would be an overkill so having said this, let’s move on.

Adding the tasks container and todo component

In the components folder, add the new TodoComponent and its styling sheet TodoComponent.razor.css.

/*TodoComponent.razor*/
@using TodoApplication.Models


    
        
        
            
        
        @Todo.Title
    
    
        
    


@code {
    [Parameter]
    public Todo Todo {get; set;} = new();
    [Parameter]
    public EventCallback OnRemoveTodo{get; set;}
    [Parameter]
    public EventCallback OnCheckTodo {get; set;}
    [Parameter]
    public string RemoveAnimation {get; set;} = string.Empty;
    private string StrikeoutClass => Todo.IsDone ? "strikeout-gradient" : "";
    

    private void CheckTask() {
        this.Todo.IsDone = !this.Todo.IsDone;
        OnCheckTodo.InvokeAsync();
    }

    private async Task RemoveTodo() {
        this.RemoveAnimation = "remove-task";
        await Task.Delay(300);
        await OnRemoveTodo.InvokeAsync(this.Todo);
    }
}

The markup is pretty straightforward: a wrapper with three classes to outline the container, add an animation when adding a new task, and an animation for when that task is removed. Within this wrapper, we have the checkbox bound to the Todo.IsDone property. Next to it, we have the label with a div to display the custom check. There is a span for the to-do title with a class to add a strikeout style to the text when the task is marked as done, and we also pass a function to the onclick event to mark the task as done when clicking on the label and an i tag to display the cross to remove the task so we also pass a function to the onclick event.

For the component code, we define a todo object that you can pass as a parameter, the todo unique identifier as a parameter, and two event callbacks: one for removing the current todo and the other to be fired up after checking the task as done. The StrikeoutClass function toggles the class to add the strikeout style based on the current todo IsDone value. The CheckTask function toggles the current todo IsDone value and the RemoveTodo function triggers the remove-task animation by adding the class to the component, waits 300 milliseconds, and invokes RemoveTodoCallback passing back the current task to be removed.

The styles are somewhat complex and I will not act like I understand all of this code, I took most of it from uiverse which is an incredible website where you can get inspiration from tons of designs made by other talented developers and reuse the code adjusting it to your needs as I did for the checkbox.

/*TodoComponent.razor.css*/
.checkbox-wrapper {
    display: flex;
    align-items: center;
    border-bottom: 0.5px solid var(--border-color);
    background-color: var(--primary-color);
    transition: transform 0.3s ease, opacity 0.3s ease;
  }

  .task-container {
    flex: 0 0 85%;
    display: flex;
    align-items: center;
    padding: 20px;
    cursor: pointer;
  }
  
  .checkbox-wrapper:hover .la-times {
    visibility: visible;
  }
  
  .checkbox-wrapper input[type="checkbox"] {
    display: none;
  }
  
  .checkbox-wrapper label {
    --size: 30px;
    --shadow: calc(var(--size) * .07) calc(var(--size) * .1);
    position: relative;
    display: block;
    width: var(--size);
    height: var(--size);
    background-color: #4158D0;
    background-image: var(--accent-color);
    border-radius: 50%;
    cursor: pointer;
    overflow: hidden;
    z-index: 1;
  }
  
  .checkbox-wrapper label:before {
    content: "";
    position: absolute;
    top: 50%;
    right: 0;
    left: 0;
    width: calc(var(--size) * .7);
    height: calc(var(--size) * .7);
    margin: 0 auto;
    background-color: #fff;
    transform: translateY(-50%);
    border-radius: 50%;
    box-shadow: inset 0 var(--shadow) #ffbeb8;
    transition: 0.2s ease width, 0.2s ease height;
  }
  
  .checkbox-wrapper label:hover:before {
    width: calc(var(--size) * .55);
    height: calc(var(--size) * .55);
    box-shadow: inset 0 var(--shadow) #ff9d96;
  }
  
  .checkbox-wrapper label:active {
    transform: scale(0.9);
  }
  
  .checkbox-wrapper .tick-mark {
    position: absolute;
    top: -1px;
    right: 0;
    left: calc(var(--size) * -.05);
    width: calc(var(--size) * .6);
    height: calc(var(--size) * .6);
    margin: 0 auto;
    margin-left: calc(var(--size) * .14);
    transform: rotateZ(-40deg);
  }
  
  .checkbox-wrapper .tick-mark:before,
    .checkbox-wrapper .tick-mark:after {
    content: "";
    position: absolute;
    background-color: #fff;
    border-radius: 2px;
    opacity: 0;
    transition: 0.2s ease transform, 0.2s ease opacity;
  }
  
  .checkbox-wrapper .tick-mark:before {
    left: 0;
    bottom: 0;
    width: calc(var(--size) * .1);
    height: calc(var(--size) * .3);
    box-shadow: -2px 0 5px rgba(0, 0, 0, 0.23);
    transform: translateY(calc(var(--size) * -.68));
  }
  
  .checkbox-wrapper .tick-mark:after {
    left: 0;
    bottom: 0;
    width: 100%;
    height: calc(var(--size) * .1);
    box-shadow: 0 3px 5px rgba(0, 0, 0, 0.23);
    transform: translateX(calc(var(--size) * .78));
  }
  
  .checkbox-wrapper input[type="checkbox"]:checked + label {
    background-color: #4158D0;
    background-image: var(--accent-color);
  
  }
  
  .checkbox-wrapper input[type="checkbox"]:checked + label:before {
    width: 0;
    height: 0;
  }
  
  .checkbox-wrapper input[type="checkbox"]:checked + label .tick-mark:before,
    .checkbox-wrapper input[type="checkbox"]:checked + label .tick-mark:after {
    transform: translate(0);
    opacity: 1;
  }
  
  .task-title {
    margin-left: 10px;
    font-size: 1rem;
    color: var(--text-color);
    cursor: pointer;
  }

  .icon-container {
    flex-grow: 1;
  }
  
  .la-times {
    margin-left: auto;
    cursor: pointer;
    color: var(--text-color);
    font-size: 1.5rem;
    visibility: hidden;
  }
  
  .la-times:hover {
    background-color: rgba(240, 240, 240, 0.8);
    padding: 2px;
    border-radius: 50%;
    color: #0a0a0a
  }
  
  .strikeout-gradient {
    background-image: var(--accent-color);
    -webkit-background-clip: text;
    background-clip: text;
    -webkit-text-fill-color: transparent; /* Makes the gradient visible */
    position: relative; /* Enables positioning of the pseudo-element */
  }
  
  .strikeout-gradient::after {
    content: ''; /* Required for pseudo-element */
    position: absolute;
    left: 0;
    right: 0;
    top: 50%; /* Positions the line in the middle of the text */
    height: 2px; /* Adjust for thickness of the line */
    background-color: rgba(0, 0, 0, 0.5); /* A semi-transparent black or any desired color */
    transform: translateY(-50%); /* Centers the line perfectly */
  }
  
  /* Add Animation */
  .add-task {
    animation: grow 0.3s ease backwards;
  }
  
  /* Keyframes for grow (adding a task) */
  @keyframes grow {
    0% {
        opacity: 0;
        transform: scale(0.5);
    }
    100% {
        opacity: 1;
        transform: scale(1);
    }
  }
  
  /* Remove Animation */
  .remove-task {
    animation: shrink 0.3s ease forwards;
    opacity: 0;
  }
  
  /* Keyframes for shrink (removing a task) */
  @keyframes shrink {
    0% {
        opacity: 1;
        transform: scale(1);
    }
    100% {
        opacity: 0;
        transform: scale(0.5);
    }
  }

Now place your TodoComponent inside the foreach loop at the home page to display all the tasks in the list and pass the values for all its parameters as shown below. Also, add the following style rules to your Home.razor.css style sheet above the media queries section. As you may have noticed, we are still not passing a handler to the OnCheckTodo event, we will do that in a moment.



    

     
          @if(!todos.Any()) 
          {
               
                   Start adding some tasks! ✅
               
           } 
           else
           {
                @foreach (var todo in todos)
                {
                    
                }
           }

/*Home.razor.css*/
.todos-container {
    background-color: #fff;
    box-shadow: 0 6px 12px rgba(0, 0, 0, 0.15), 0 2px 4px rgba(0, 0, 0, 0.12);
    border-top-left-radius: 5px;
    border-top-right-radius: 5px;
    overflow-x: hidden;
    background-color: var(--primary-color);
    overflow-y: scroll;
    height: auto;
    max-height: 400px;
}

.no-tasks-text {
    padding: 5px;
    text-align: center;
    color: #8f8f8f;
    font-weight: 500;
}

::-webkit-scrollbar {
    width: 6px;
}

::-webkit-scrollbar:horizontal {
    height: 6px;
}

::-webkit-scrollbar-track {
    background: transparent;
}
 
::-webkit-scrollbar-thumb {
    border-radius: 10px;
    background-color: #aaa;
    opacity: 0;
    transition: opacity 0.3 ease;
}

Your to-do app is looking more and more stunning as you continue adding more stuff.

Storing tasks in local storage

The next step is to save the list of tasks to local storage so you don’t lose your tasks every time the application is refreshed or closed. You have to modify 3 methods on the home page and create another one to be used in the TodoComponent.

   /*Home.razor*/
     // Add the update todo handler

    ...
    protected async override Task OnInitializedAsync() {
        //Get Theme values from Local Storage
        appTheme = await localStorage.GetItemAsync("appTheme") ?? "";
        
        // Getting the todos from local storage when initializing the application
        todos = await localStorage.GetItemAsync>("todos") ?? Enumerable.Empty().ToList();
    }

    private async Task AddTodo(KeyboardEventArgs e) {
        if (e.Key == "Enter") {
            var newTodo = new Todo() { Title = todoTitle };
            todos.Add(newTodo);
            //Updated the todos in the local storage after adding a todo
            await localStorage.SetItemAsync("todos", todos);
            todoTitle = string.Empty;
        }
    }

    // This method will be used in the Todo component in a moment
    private async Task UpdateTodoList() {
        await localStorage.SetItemAsync("todos", todos);
    }
    
    private async Task RemoveTodo(Todo todo) {
        todos.Remove(todo);
        // Update todos in the loca storage after removing a todo
        await localStorage.SetItemAsync("todos", todos);
    }

With this, you update the tasks list every time you add a new task or remove and get the saved tasks list from the local storage when the application is refreshed and the UpdateTodoList method will be passed as a handler to the OnRemoveTodo event in the TodoComponent to update the list after marking a task as done.

Adding the tasks filter

You have come to the last section of this article, Here, you will add a task filter to display how many tasks remain, filter by some criteria, and remove completed tasks. For this, you have to create the TodoFilter component.

/*TodoFilter.razor*/

     @ItemsLeft items left

    
        
            @foreach(var filter in FilterOptions)
            {
                
                    
                        
                    
                    @filter.Value
                
            }
        
    

    Clear Completed


@code {
    [Parameter]
    public int ItemsLeft { get; set; }
    [Parameter]
    public Dictionary FilterOptions { get; set; } = new();
    [Parameter]
    public EventCallback ClearCompleted { get; set; }
    [Parameter]
    public EventCallback FilterBy { get; set;}
    private string selectedOption = "all";

    private void ClearCompletedTasks() {
        selectedOption = "all";
        ClearCompleted.InvokeAsync();
    }

    private void FilterTasksBy(string taskStatus) {
        selectedOption = taskStatus;
        FilterBy.InvokeAsync(taskStatus);
    }
}

This component consists of a span displaying the number of tasks left, a set of InputRadio elements that will filter the tasks by their status and a button to clear all completed tasks from the list. You must pass the number of tasks left, the filtering options, and the handlers for FilterBy and ClearCompleted events as parameters for this component. The clearCompletedTasks method will reset the selected filter option to all and then invoke the clearCompleted event, the FilterTasksBy method does something similar as it sets the selectedOption to the filter option selected and then invoke the FilterBy event passing back the task status.

For the styling, we are just using flexbox to get everything horizontally aligned and hiding the radio input to only show its label, and applying style if the input is checked.

/*TodoFilter.razor.css*/
.filter-container {
    display: flex;
    align-items: center;
    justify-content: space-between;
    width: 100%;
    padding: 20px;
    box-sizing: border-box;
    background-color: var(--primary-color);
    box-shadow: 0 6px 12px rgba(0, 0, 0, 0.15), 0 2px 4px rgba(0, 0, 0, 0.12);
    border-bottom-left-radius: 5px;
    border-bottom-right-radius: 5px;
    overflow-x: hidden;
}

 span {
    font-size: 10pt;
    color: #afafaf;
    font-weight: bold;
}

span:hover:not(:first-child) {
    cursor: pointer;
    font-size: 10pt;
    color: #6f6f6f;
    font-weight: bold;
}

.radio-group {
    display: flex;
    gap: 3px;
    justify-items: center;
}

.radio-group label{
  padding: 2px 4px;
  cursor: pointer;
  font-size: 10pt;
  font-weight: bold;
  color: #afafaf;
  transition: transform 0.3s ease, background-color 0.3s ease, color 0.3s ease;
}

.radio-group label:has(input:checked) {
  color: #5596FF;
  transform: scale(1.09);
}

.radio-mask {
  display: none;
}

Let’s move ahead and use our new component in our app!

/*Home.razor*/
...

...

@code {
    // This dictionary will hold the list of filters
    public Dictionary filterOptions = new();

    protected async override Task OnInitializedAsync() {
        /*Code ommited for brevity*/
        
        //Add the filters instead of hardcoding them in the component
        filterOptions.Add("all", "All");
        filterOptions.Add("active", "Active");
        filterOptions.Add("completed", "Completed");
    }

    // Return the filtered list after selecting the desired filter option
    private async Task FilterTodoList(string filterOption)
    {
        todos = await localStorage.GetItemAsync>("todos") ?? Enumerable.Empty().ToList();

         todos = filterOption switch
        {
            "active" =>  todos.Where(x => !x.IsDone).ToList(),
            "completed" => todos.Where(x => x.IsDone).ToList(),
            _ =>  await localStorage.GetItemAsync>("todos") ?? Enumerable.Empty().ToList()
        };
    }
    
    // Clear all the tasks that are marked as done
    private async Task ClearCompletedTasks() {
        todos = await localStorage.GetItemAsync>("todos") ?? Enumerable.Empty().ToList();
        todos = todos.Where(x => !x.IsDone).ToList();
        await localStorage.SetItemAsync("todos", todos);
    }
}

Place the TodoFilter component below the tasks container and pass the parameters listed previously, you have to create a dictionary to hold the filter values along with the text that will be displayed in the component, then add the filter options inside the OnInitialized method to make sure the filter is not empty when running the application. The FilterTodoList method gets the tasks list from the local storage and then filters the list based on the status of the task and the ClearlCompletedTasks also gets the stored tasks from the local storage and then removes the ones that have been marked as done.

Your Todo app is now complete!

Your application is now complete and ready to streamline your tasks! You can seamlessly add, remove, filter, and clear completed items or switch to dark mode for a visually comfortable experience. I hope you’ve found the process as rewarding as I did—while perfection wasn’t the goal, creating something functional and enjoyable while learning Blazor certainly was.

If you’d like to see more articles like this or have ideas to enhance future tutorials, feel free to share your thoughts. Thank you for joining me on this journey, and I look forward to connecting again soon!

Optimizing Your .NET Application Development with NDepend

Oscar Montenegro — Mon, 26 Jun 2023 17:29:32 GMT

Lately I’ve been absent taking some time to rest and finishing some delayed work. But I’ve also been trying a new tool these days on my side projects, you already know what tool I’m talking about by the title of the article so yeah NDepend it’s a pretty cool tool for code analysis for projects where many devs are involved all of them applying their code conventions and committing changes every day, we know that code can become unmanageable pretty quick as we make changes for bugfixes of new features being added continuously. Also for projects with many dependencies, NDepend shines as it tracks all these dependencies and provides us with a meaningful dependencies map but more of that in just a bit.

Overview

NDepend is a static code analysis tool, that allows developers to manage code base quality through an array of metrics, visualizations, and rules. It helps identify bugs and vulnerabilities while ensuring your code complies with industry standards and best practices. Compatible with .NET and .NET Core applications, it simplifies the way you approach complex code bases, giving you more control and visibility.

NDepend manages the entire solution providing metrics, code review, graphs, and more for all your code within your solution. You can find it available for Visual Studio 2010 - 2022 so in terms of VS version NDepent got you covered.

Code Review

The Code Review feature is one of the central functionalities provided by NDepend. Designed with a focus on improving code quality, it leverages static code analysis to systematically examine your code base.

This feature generates a detailed report on the potential issues within the code, identifying bugs, vulnerabilities, and areas where coding standards or best practices are not being adhered to. It provides insights into areas that require improvement, thereby allowing developers to fix issues before they escalate into bigger problems.

After installing the NDepend extension on VS2022 I searched for the Blog API project that we have been working on all this time and initialized the analysis on it.

I was presented with these different options and I must confess that I was eager to test every one of them. So I clicked on the dashboard option and I was amazed at how much information they set up for you and the level of analysis this tool can handle.

You can see NDepend shows us the number of code lines our project contains, and how many do not belong to our code, this means code that belongs to external assemblies. Also, we can see the technical debt we have in our project as a percentage which I think is one of the most appealing graphics. Finally, on the right side, you can see the rules violations, quality gates, and existing issues in our code and you can define your own custom rules to make sure your code is enforcing the best practices.

Code Diff

The Code Diff feature in NDepend allows you to compare different versions of your code base, identifying changes, updates, or regressions. This is especially helpful in tracking the progress of refactoring, identifying risky code changes, or confirming if new versions are improving the code base quality.

With the diff tool, we can search by element, assembly, namespace, type, method, and so on. We can search for recent changes, removed lines, updated code, and wide criteria to look for code changes.

Trendings

Monitoring trends is a pivotal aspect of maintaining code quality, and NDepend shines brightly in this arena. With its Trending feature, NDepend monitors various metrics over time, providing valuable insights into the evolution of your code base. You can easily visualize and analyze these trends to assess your development strategies' effectiveness.

You know how sometimes you wish you could see how your code has changed over time? Like, has it gotten better or worse? Are certain bugs popping up more often? That's exactly what the Trendings feature does.

Trendings in NDepend are like a record of how you tend to code. It keeps an eye on various metrics over time and helps you understand how your code base is evolving. It's like a progress report that shows you the ups and downs of your code quality over different periods.

Imagine that you've been working on refactoring some parts of your code, and you want to see if it's making a positive difference. The Trendings feature could show you if your changes have reduced code complexity or increased code coverage over time.

Dependencies Graph

This is one of my favorite tools and the reason which I know NDepend, a couple of years ago I was working on a legacy project that was like 20 years old so I had like a ton of dependencies some of which I had no access or I didn’t even have knowledge about and NDepend helped me to create a dependencies graph and finally be able to at least understand what was going on with that project. I shared a snapshot of the graph with my coworkers that had much more time working with that solution and even they were surprised by all the dependencies they didn’t know were there.

In the case of the graph shown below this is an example of a dependencies graph generated from our BlogAPI project which is not that complex and has been coded all this time by only one developer so here you will not see something that complicated. Regardless of that it does not means that we are not getting any value from this feature for our project, this is very useful and I’m pretty sure it will come in handy in the future as we continue to develop our API.

This feature gives you a visual map of your code, showing how different parts are linked or 'dependent' on each other. It's like Google Maps but for your code. And just like you can see different routes and connections on a city map, the Dependencies Graph lets you see the intricate web of connections in your code.

This is super useful when you're trying to understand your code structure, especially if it's a large or complex code base. The graph can show you if there are any weird or unexpected connections in your code, which could be a sign that something's off. It can also help you figure out the best way to refactor or restructure your code.

Plus, the visual nature of the Dependencies Graph makes it easier to grasp and communicate these dependencies to others on your team. It's a way of turning complicated code connections into something you can see and understand.

Dependency Matrix

NDepend’s Dependency Matrix provides another way to analyze dependencies. It presents a matrix view of dependencies between elements in your code. With this feature, spotting and managing circular dependencies becomes effortless, ultimately leading to a cleaner, more efficient code base.

It lays out your code in a grid, with rows and columns representing different code elements. Where a row and a column intersect, you can see if and how those two elements are dependent on each other. For example, if class A uses class B, the intersection of A's row and B's column will show this.

The Dependency Matrix also helps you get a handle on the overall structure and organization of your code. You can quickly see which parts of your code are heavily interconnected and which parts are more isolated.

Below you can see an example of how this feature would look like, the image was taken from the NDepend docs.

Metrics View

The Metrics View presents a kind of heatmap or a colored treemap, where each little block represents a piece of your code, like a class or a method. The size of the block shows the size of the code it represents, and its color indicates some specific characteristic you're interested in, like complexity or test coverage.

This lets you see at a glance what's going on with your code. You can instantly spot parts of your code that are large (the big blocks) or super complex (the blocks with darker colors). This is super useful because these areas are usually where bugs love to hide and where future issues may crop up.

The cool thing is that you can customize what characteristic the colors represent based on what you care about most. For example, if you're focused on making sure your code is well-tested, you could set up the colors to represent test coverage. That way, any parts of your code that don't have enough tests will stand out like a sore thumb.

Conclusion

From my perspective, NDepend is a good fit for almost every serious project as it will continue to grow and be supported by more than one developer in most cases so having all these features in hand with a single tool is a great help and can provide early relief to future problems on dependencies, bugs, code not following the best practices and being able to specify your own rules and metrics to make sure all your code is consistent with your code style.

If you want to know more about NDepend and try it by yourself and see if it fits your needs head to https://www.ndepend.com/ and take the 14 days trial and use it on your side projects to have the chance to experience all the benefits it provides.

Implementing CORS in ASP.NET Core Web API: Enabling Secure Cross-Origin Resource Sharing

Oscar Montenegro — Tue, 13 Jun 2023 04:29:10 GMT

In the world of web development, ensuring secure communication between different origins is crucial. Cross-Origin Resource Sharing (CORS) comes to the rescue by allowing controlled access to resources on different domains. In this article, we'll delve into the realm of CORS, exploring its purpose and benefits. We'll also guide you through the implementation of CORS in an ASP NET Core Web API, ensuring secure cross-origin interactions.

What is CORS?

CORS is a feature implemented by web browsers to control how web applications on different domains interact with each other.

Imagine you have a website on one domain, and you want to access some resources (like data or images) from another website on a different domain. By default, web browsers are a bit cautious about this because they want to protect you from potential security risks. That's where CORS comes in.

CORS allows web servers to specify who can access their resources and under what conditions. It acts as a communication channel between the web browser and the server, making sure that it's safe for your website to access resources from another domain.

Now, it's important to note that CORS is not a complete security solution on its own. It's more like a helpful tool that works alongside other security measures. CORS focuses on managing cross-origin requests, which are requests made from one domain to another. It helps prevent certain types of attacks that could exploit the same-origin policy, a security feature in browsers.

However, CORS doesn't handle all aspects of security. It doesn't provide end-to-end security for data transfer or protect against all possible threats. For a robust security setup, you need to combine CORS with other practices like proper authentication and authorization, input validation, encryption, and following secure coding practices.

Think of CORS as a friendly bouncer at a party who checks your invitation before allowing you in. It helps control access to resources between different domains, but you still need to make sure you have other security measures in place to throw a safe and secure party.

So, remember, while CORS is a helpful feature, it's not the whole security package. It's part of a bigger picture, and by combining it with other security practices, you can ensure the overall safety of your web application.

Why Should I Use CORS?

CORS is essential when you want to allow clients from different domains to access and interact with resources on your web API. By enabling CORS, you can securely expose selected resources to trusted origins, facilitating seamless data exchange between client applications and your API. CORS helps prevent unauthorized cross-origin requests while promoting collaboration and interoperability among web applications.

Enabling a CORS in your Web App

To add CORS to your web application you have to call the AddCors method in the services container and define a CORS policy. In the code example below a default policy is added and is set to allow any method and any header from the defined source https://www.example.com in this case, this means that your web application will not allow it to be consumed from any other source.

builder.Services.AddCors(options => 
{
    options.AddDefaultPolicy(builder =>
    {
        builder.WithOrigins("")
                .AllowAnyMethod()
                .AllowAnyHeader();
    });
});

Now the last piece of the puzzle is to set your app to use CORS in the middleware pipeline as shown below. An important tip is that you must call UseCors after UseRouting and before the UseAuthorization method to work properly.

app.UseHttpsRedirection();

app.UseCors();

app.UseAuthorization();

app.UseResponseCaching();

app.MapControllers();

app.Run();

Default Policies

A default policy is like the one defined above, you have to define the default policy within the AddCors method and set the origins, methods, and headers allowed. Then this policy will be applied globally to your application as the name says it’s the default policy for your web app.

builder.Services.AddCors(options => 
{
    options.AddDefaultPolicy(builder =>
    {
        builder.WithOrigins("")
                .AllowAnyMethod()
                .AllowAnyHeader();
    });
});

Named Policies

Another way to define a CORS policy is through named policies which will not be applied globally to your web app instead you have to enable it using attributes but we will see that in just a bit. The way to define a named policy is pretty similar to a default policy but here you have to call the AddPolicy method instead of the AddDefaultPolicy.

builder.Services.AddCors(options =>
{
		options.AddPolicy("MyNamedPolicy",policy =>
		    {
		        policy.WithOrigins("",
		                            "");
		        policy.AllowAnyMethod();
		        policy.AllowAnyHeader();
		    });
});

Enable CORS using attributes

If instead of enforcing CORS for all your application you just want it on a set of specific endpoints or a controller then you can achieve this using the attribute [UseCors]. You can use this attribute on top of your controller or action and a default CORS policy will be implemented but the preferred way is to use the attribute and pass the Policy Name property to implement that CORS policy. And this is the way to implement named policies as they are not implemented globally or by default as the default policy.

[HttpGet]
[EnableCors(PolicyName = "MyNamedPolicy")]
public async Task GetPost([FromQuery] QueryParameters parameters)
{
	...
}

This will implement the named policy MyNamedPolicy in the GetPost action. And you might suspect it but in case you don’t, you can implement different CORS policies for different actions and controllers.

Enable CORS for Subdomains

If you want to enable CORS in all the subdomains from a source you have to call the SetIsOriginAllowedToAllowWildcardSubdomains() method.

Taken from Microsoft Documentation: “SetIsOriginAllowedToAllowWildcardSubdomains: Sets the IsOriginAllowed property of the policy to be a function that allows origins to match a configured wildcard domain when evaluating if the origin is allowed.”

Below is an example of how you would have to implement it.

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowSubdomainsPolicy",
        policy =>
        {
            policy.WithOrigins("https://*.example.com")
                .SetIsOriginAllowedToAllowWildcardSubdomains();
        });
});

Specify methods on your CORS policy

So far we have been using the AllowAnyMethod policy but it won’t make much sense to allow external sources to have access to all the method types all the time. For example, imagine you developed a web API and you want full access to your sources so you use the AllowAnyMethod but for external sources, you want to restrict access to PUT and DELETE methods.

builder.Services.AddCors(options => 
{
    options.AddPolicy("MyDomainsPolicy",policy =>
    {
        policy.WithOrigins("",
                            "");
        policy.AllowAnyMethod();
        policy.AllowAnyHeader();
    });

    options.AddPolicy("PublicPolicy",policy =>
    {
        policy.AllowAnyOrigin();
        policy.WithMethods("GET", "POST");
        policy.AllowAnyHeader();
    });
});

Set allowed Request Headers

As with methods you can set what headers your application will accept

options.AddPolicy("PublicPolicy",policy =>
    {
        policy.AllowAnyOrigin();
        policy.WithMethods("GET", "POST", "PUT");
        policy.WithHeaders(HeaderNames.Accept, HeaderNames.CacheControl);
    });

Set Exposed Headers

The browser by default will not expose all response headers. So to make other headers available you should use the WithExposedHeaders method.

options.AddPolicy("PublicPolicy",policy =>
    {
        policy.AllowAnyOrigin()
              .WithMethods("GET", "POST", "PUT")
              .WithHeaders(HeaderNames.Accept, HeaderNames.CacheControl)
              .WithExposedHeaders("x-custom-header");

    });

The only response headers that are available by default are the next:

Cache-Control
Content-Language
Content-Type
Expires
Last-Modified
Pragma

Disable CORS

Finally, if you want to disable CORS from a controller or an action you can use the [DisableCors] attribute to achieve it.

[HttpPost]
[DisableCors]
public async Task CreatePost(AddPostDTO addPostDTO)
{
	...
}

It is important to say that DisableCors will not disable CORS that have been enabled using endpoint routing. An example of CORS enabled with endpoint routing is provided below taken from the Microsoft Documentation.

app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("/echo",
        context => context.Response.WriteAsync("echo"))
        .RequireCors(MyAllowSpecificOrigins);

    endpoints.MapControllers()
             .RequireCors(MyAllowSpecificOrigins);

    endpoints.MapGet("/echo2",
        context => context.Response.WriteAsync("echo2"));

    endpoints.MapRazorPages();
});

Conclusion

Enabling CORS in your ASP.NET Core Web API is a crucial step to ensure secure cross-origin resource sharing. By implementing CORS, you can control and allow access to resources from trusted origins, promoting collaboration and interoperability. Understanding the benefits and drawbacks of CORS will help you make informed decisions while building secure and scalable web applications. Implement CORS in your ASP.NET Core Web API using the provided steps

Follow me for Developer Tips and Clean Code Tips

From tomorrow I will start sharing advice for software developers from the experiences I’ve lived working in big enterprises as a freelancer, also I will share useful code snippets that can help you write cleaner and more maintainable code for your job or side projects. All this will be on my Twitter page so go and start following me so you don’t miss a single tip @OscarOsempu. We are almost reaching 15k monthly views on Unit Coding, Thanks for being along with me on this exciting journey, to be honest, it was harder than I thought it would be but I’ve learned a lot from this experience and I’m still developing consistency as I can say it’s something I’ve never been good at, but your comments and feedback have been there to make me push forward and always bring you some quality content while enjoying the ride, what can I say? I’m very blessed to have a community like this, thanks for everything!

A Comprehensive Guide to Caching Strategies in Web API Development

Oscar Montenegro — Thu, 08 Jun 2023 19:29:16 GMT

Welcome to another exciting chapter in this series on Web API Development! If you've ever wondered how to make your API lightning-fast and more efficient, caching is one of those steps to take in the right direction to achieve it. In the last chapter, I showed you how to implement HATEOAS in your Web API, it had a great impact when I shared it online as many experienced developers shared their experiences with this component since it has some pros and cons as with everything in life but if you want to take a look at it I will leave the link to the post below. Ok so without further ado let's get into today's post.

Implementing HATEOAS in your ASP NET Core web API: Enhancing API Discoverability and Navigability

Unit CodingOscar Montenegro

What is Caching ?

Caching is like having secret storage where you can temporarily store frequently accessed data. Instead of going through the whole process of generating a response from scratch every time, you can retrieve it directly from the cache. It's like having a shortcut to lightning-fast responses!

In the context of Web API, caching involves storing API responses, either partially or in their entirety, so that subsequent requests for the same data can be served directly from the cache. This reduces the need for expensive computations or database queries, resulting in improved response times and better performance.

Benefits of Caching

Caching offers several compelling benefits for your Web API:

1. Lightning-Fast Response Times

By serving responses from the cache, you can skip the time-consuming steps of processing and generating a fresh response. This significantly reduces the overall response time, leading to a smoother and more responsive user experience.

2. Reduced Server Load

Caching helps offload the work from your server by minimizing the number of requests that need to hit your API endpoints. When a request can be fulfilled from the cache, it eliminates the need for processing and querying the underlying data source. This, in turn, reduces the server load, allowing it to handle more concurrent requests and improving the overall scalability of your API.

3. Improved Scalability

With caching in place, your Web API becomes more scalable. By reducing the load on your server, caching enables your application to handle increased traffic and accommodate a larger user base without compromising performance. It helps you make the most of your server's resources and ensure a consistent experience for your users, even during peak usage periods.

Types of Caching

There are different types of caching that you can implement in your Web API:

1. In-Memory Caching

In-memory caching stores the cached data in the memory of your application. It offers lightning-fast access to the cached data but is limited to a single server instance. This type of caching is suitable for scenarios where the cached data is not critical and can be easily recreated if lost.

2. Distributed Caching

Distributed caching involves storing the cached data in a shared cache that can be accessed by multiple server instances or even across different machines. This allows for better scalability and resilience, as multiple servers can share the same cache. Distributed caching is commonly used in scenarios where high availability and reliability are required.

3. Client-Side Caching

Client-side caching involves storing the cached data on the client side, typically in the web browser. This is achieved by setting appropriate caching headers in the API responses. Client-side caching can significantly reduce the number of requests made to the server, as the client can use the cached data for subsequent requests. It improves the overall performance and responsiveness of your API.

What is Response Caching?

Response caching is a technique that allows you to store the response of an API endpoint and serve it directly from the cache for subsequent requests. Instead of re-computing the response or hitting the database every time, you can leverage response caching to retrieve the data from a cache store. This significantly improves response times, reduces server load, and enhances the overall scalability of your Web API. This is the technique we will be using in this tutorial.

The Response Cache Attribute

In ASP.NET Core Web API, response caching is made easy with the [ResponseCache] attribute. By applying this attribute to your controller or action methods, you can control how the response is cached. The [ResponseCache] attribute provides various options to customize caching behavior, such as cache duration, location, and more.

For example, you can specify the cache duration using the Duration property, like this:

[HttpGet]
[ResponseCache(Duration = 60)] // Cache the response for 60 seconds
public IActionResult Get()
{
    // Your code here
}

The Response Cache Parameters

In ASP.NET Core, the [ResponseCache] attribute gives you different options to control how your API responses are cached. Let's take a look at these options in a beginner-friendly way:

Duration: This parameter lets you specify how long the response should be cached. You can set it to a specific number of seconds using the Duration property. For example, if you set [ResponseCache(Duration = 60)], the response will be cached for 60 seconds before it needs to be refreshed.
Location: This parameter determines where the response can be cached. You have three options:

ResponseCacheLocation.Any: The response can be cached by both client-side browsers and proxy servers.
ResponseCacheLocation.Client: The response can be cached by client-side browsers only.
ResponseCacheLocation.None: The response should not be cached at all.

VaryByHeader: Sometimes, you want to cache responses separately based on specific request headers. This parameter allows you to specify the headers that should be considered when deciding if a cached response can be served. For example, if you set [ResponseCache(VaryByHeader = "User-Agent")], the response will be cached separately for different user agents.
VaryByQueryKeys: Similar to VaryByHeader, this parameter helps you cache responses separately based on specific query string parameters. You can specify the query parameters that should be considered when deciding if a cached response can be served. For example, if you set [ResponseCache(VaryByQueryKeys = new[] { "page", "pageSize" })], the response will be cached separately for different values of the page and pageSize query parameters.
NoStore: This parameter determines whether the response should be stored in the cache at all. Setting NoStore to true ensures that the response is not cached.

These response cache parameters give you control over how your API responses are cached. By using them, you can specify the caching duration, where the response can be cached, and even cache responses differently based on headers or query parameters. It's a powerful way to optimize your API's performance and reduce server load.

Response Caching Middleware

ASP NET Core also provides a built-in response caching middleware that you can add to your API pipeline. The response caching middleware intercepts incoming requests and checks if a cached response exists. If a cached response is found, it's served directly, bypassing the entire request pipeline. This saves processing time and improves the API's responsiveness.

To enable response caching middleware, you can add the following code to your Program.cs file:

builder.Services.AddControllers();
builder.Services.AddResponseCaching();
...
app.MapControllers();
app.UseResponseCaching();

app.Run();

Cache Profiles

Cache profiles allow you to define caching behavior in a centralized and reusable manner. Instead of repeating the same caching settings for multiple actions, you can define a cache profile and apply it across different endpoints. This promotes consistency and simplifies cache management.

To configure cache profiles, you can add the following code to your Program.cs file:

builder.Services.AddControllers(options =>
{
    options.CacheProfiles.Add("DefaultCache",
	      new CacheProfile()
	      {
	          Duration = 60,
	          Location =  ResponseCacheLocation.Any,
              VaryByQueryKeys = new[] { "page", "pageSize" } 
              // Vary the cache by these query parameters
	      });
	});

In the code snippet above, we've defined a cache profile named "DefaultCache" It has a duration of 60 seconds, meaning that the response will be cached for that period. We've also allowed caching from any location, which means both client-side browsers and proxy servers can cache the response. Additionally, we've specified that the cache should vary based on the "page" and "pageSize" query parameters. Feel free to adjust these settings based on your specific needs.

Once the cache profile is defined, you can apply it to your API endpoints. Let's say you have a controller with an action method you want to cache. Simply add the [ResponseCache] attribute to that action method and specify the cache profile name:

[HttpGet]
[ResponseCache(CacheProfileName = "DefaultCache")]
public IActionResult GetData(int page, int pageSize)
{
    // Your code here
}

By setting CacheProfileName to "DefaultCache," you're instructing ASP.NET Core to apply the caching settings defined in the "DefaultCache" cache profile to this specific action method. You can reuse the same cache profile across multiple endpoints to maintain consistent caching behavior.

Using cache profiles in ASP.NET Core 7 simplifies the management of caching settings, making it easier to update or modify caching behavior in the future. It centralizes your caching rules, improving code readability and maintainability.

Defining Cache Profiles in the appsettings.json file

To define a cache profile in the appsettings.json file and use it in your ASP.NET Core application, follow these steps:

Open your appsettings.json file and add a new section for cache profiles. Here's an example of how it might look:

{
  "CacheProfiles": {
    "DefaultCache": {
      "Duration": 60,
      "Location": "Any",
      "VaryByQueryKeys": [ "page", "pageSize" ]
    },
    "CustomProfile": {
      "Duration": 120,
      "Location": "Client",
      "VaryByHeader": [ "User-Agent" ]
    }
  }
}

JSON

In your Program.cs file, register your cache profiles defined in the appsettings.json file as shown below:

builder.Services.AddControllers(options =>
{
    var cacheProfiles = builder.Configuration
            .GetSection("CacheProfiles")
            .GetChildren();

    foreach (var cacheProfile in cacheProfiles)
    {
        options.CacheProfiles
        .Add(cacheProfile.Key, 
        cacheProfile.Get());
    }
});

Now, you can use the cache profiles in your API endpoints. For example, let's assume you have an action method in your controller that you want to cache using the "DefaultCache" cache profile. Add the [ResponseCache] attribute and specify the cache profile name:

[HttpGet]
[ResponseCache(CacheProfileName = "DefaultCache")]
public IActionResult GetData(int page, int pageSize)
{
    // Your code here
}

By setting CacheProfileName to "DefaultCache," the caching settings defined in the "DefaultCache" cache profile will be applied to this action method.

That's it! You've defined cache profiles in the appsettings.json file and used them in your ASP.NET Core application. This approach allows you to configure cache profiles externally, making it easier to modify caching behavior without modifying code.

Get the code repo from GitHub

If you want to follow along get the code from GitHub and make sure you get the code from the HATEOAS branch which contains the code changes up to this tutorial.

Implementing Response Caching in your Web API

First, add the response caching in the services container and the response cache middleware so the code in the Program file should look like this:

builder.Services.AddResponseCaching();
builder.Services.AddControllers()
                .AddNewtonsoftJson(options =>
                {
                    options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
                    options.SerializerSettings.NullValueHandling = NullValueHandling.Ignore;
                });
...
app.UseResponseCaching();

app.MapControllers();

app.Run();

You can add the response caching above or below the controllers and the response caching should be above the MapControllers().

Add a Response Cache attribute to the Get Endpoints

[HttpGet]
[ResponseCache(Duration = 60, Location = ResponseCacheLocation.Any, VaryByQueryKeys = new []{"*"})]
public async Task GetPost([FromQuery] QueryParameters parameters)
{
	...
}

[HttpGet("{id:int}")]
[PostExists]
[ResponseCache(Duration = 60, VaryByQueryKeys = new []{"*"})]
public async Task GetPost(int id)
{
	...
}

For the GetPost endpoint, a duration of 60 seconds is set for the response lifetime, the location for the response cache is set to any, which means that both the server and the client will cache the response and lastly, there is a VaryByQuerykeys parameter that we set to update the cache every time that a query string is changed as this method uses pagination, sorting and filtering there will be many cases where the query strings change.

For the GetPost(id) method a duration of 60 seconds is set as well and the VaryByQueryKeys parameter is initialized as we did for the GetPost method.

Testing your application

Now you are ready to test your application, using a tool like Postman make a call to any of these endpoints and check the response headers, there you will see the Cache-Control header which contains the max-age value that indicates how long the cached response will last in this case it is 60 seconds for any of the endpoints. If this is the first time you call the endpoint you will only be able to see the Cache-Control header but if you call the same endpoint again there will be another header named Age this header contains the age in seconds of the cached response as you are getting the same response if you did not change any query string parameter then you should be getting a cached response this means a previously stored response to save some resources on your application.

Conclusion

Caching is a powerful technique that can greatly enhance the performance and scalability of your Web API. By leveraging caching, you can achieve lightning-fast response times, reduce server load, and improve the overall user experience. Whether you choose in-memory caching, distributed caching, or client-side caching depends on your specific requirements and the nature of your application.

So, don't wait any longer! Implement caching in your Web API and witness the transformation in performance. Your users will thank you for the lightning-fast responses and smooth user experience.

Happy caching!

This week I worked on some stuff in the blog for example now you can share this article on your favorite social media platform. Also as we achieved more than 10K views this month I’m planning on the future of this blog as well with the YouTube channel I want to start more series and create resources that help you on your learning Journey but I will talk about that later. Thanks for everything I hope you have an amazing day!

Implementing HATEOAS in your ASP NET Core web API: Enhancing API Discoverability and Navigability

Oscar Montenegro — Thu, 01 Jun 2023 16:51:03 GMT

As developers, we strive to build robust and user-friendly web APIs that provide a seamless experience for clients. One powerful approach to achieve this is by implementing HATEOAS (Hypermedia as the Engine of Application State) in our ASP.NET Core Web APIs as this provides a handful of benefits for the client that you will see in just a bit. In the last post, we talked about exposing related entities with Entity Framework Core in our web API and how to avoid some known problems with nested entities so I will leave you the link for that post below. Now let’s get into today’s topic, implementing HATEOAS.

Unit CodingOscar Montenegro

Overview of HATEOAS and its Significance in web APIs

HATEOAS is an architectural principle that emphasizes the use of hypermedia links to drive the interaction between clients and APIs. It enables us to create self-describing APIs where clients can dynamically discover available resources and navigate through them using standardized links. By providing hypermedia-driven responses, we enhance the discoverability and navigability of our APIs, making them more intuitive and easier to consume.

Benefits of using HATEOAS in ASP NET Core Web APIs

Implementing HATEOAS in our ASP NET Core Web APIs brings several benefits that greatly improve the user experience and API design:

Improved Discoverability: HATEOAS enables the automatic discovery of resources and endpoints within an API. By including hypermedia links in API responses, clients can dynamically navigate through the available resources without the need for prior knowledge of the API structure. This improves the discoverability of the API and reduces the learning curve for developers integrating with it.
Enhanced Navigability: With HATEOAS, clients can seamlessly navigate through related resources by following hypermedia links. This eliminates the need for hard-coded dependencies on specific endpoints and allows for flexible exploration of the API. Clients can traverse from one resource to another, making the API more dynamic and adaptable to changes over time.
Flexible API Evolution: HATEOAS promotes a decoupled architecture between clients and servers. By using hypermedia links to represent relationships between resources, the API design becomes more flexible and allows for gradual changes without breaking existing client applications. It enables versioning and evolution of the API without requiring clients to update their code every time the API changes.
Simplified Integration: HATEOAS reduces the complexity of integrating with an API by providing a standardized way to interact with resources. Clients can rely on the hypermedia links to understand the available actions and the next steps to take. This simplifies the integration process and promotes interoperability between different clients and servers.
Improved User Experience: By leveraging HATEOAS, we can create more intuitive and user-friendly APIs. Clients can follow a consistent navigation pattern based on the hypermedia links provided in the responses. This reduces the cognitive load on developers and makes it easier to understand and interact with the API, resulting in a better user experience.

Definition and core principles of HATEOAS

HATEOAS revolves around the concept of including hypermedia links in API responses. These links provide additional information and context to clients, allowing them to navigate through the API and discover related resources. By adhering to the core principles of HATEOAS, we create APIs that are self-describing, decoupled, and highly adaptable.

How HATEOAS enhances the discoverability and navigability of APIs

One of the key advantages of HATEOAS is its ability to enhance the discoverability of APIs. By including hypermedia links in our responses, we guide clients to explore available resources, eliminating the need for prior knowledge of the API structure. This makes our APIs more intuitive and reduces the learning curve for developers who integrate with our API.

Moreover, HATEOAS promotes navigability within the API. Clients can effortlessly traverse through related resources by following the hypermedia links, creating a dynamic and flexible experience. This eliminates the hard-coded dependencies on specific endpoints and allows for seamless API evolution and versioning.

Role of hypermedia in HATEOAS

Hypermedia plays a central role in HATEOAS by providing the means to represent and navigate resources. Hypermedia formats such as HAL (Hypertext Application Language) and JSON-LD (JSON Linked Data) provide standardized ways to include links and other metadata in API responses. By leveraging these hypermedia formats, we can ensure consistency and interoperability across different clients and APIs.

Hypermedia links can be used to indicate available actions, suggest related resources, or provide contextual information. They enable clients to follow a uniform navigation pattern, reducing the coupling between client and server and promoting a more flexible and adaptive API design.

Get the code from GitHub

Before starting to code I recommend if you want to follow along then go and grab the code from the GitHub repository and make sure you get the code from the “RelatedEntities” branch.

GitHub - Osempu/BlogAPI at RelatedEntities

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Install the RiskFirst.Hateoas nuget package

To implement HATEOAS in your project first you will need to install the RiskFirst nuget package using the following dotnet cli command.

dotnet add package RiskFirst.Hateoas

Add a Hateoas Response Model

Now add a new kind of response model for your main entity in this case the Post model that will be called PostHateoasResponse.

public class PostHateoasResponse : ILinkContainer
{
    public PostResponseDTO Data;
    private Dictionary links;

    [JsonPropertyName("links")]
    public Dictionary Links 
    { 
        get => links ?? (links = new Dictionary());
        set => links = value;
    }

    public void AddLink(string id, Link link)
    {
        Links.Add(id, link);
    }
}

This class represent the HATEOAS response for the post model and is implementing the ILinkContainer interface exposed by the RiskFirst.Hateoas package. The response model contains a Dictionary that contains the URLs to the methods (GET, POST, DELETE, PUT, PATCH). The AddLink method will just add new links to the links dictionary.

Implementing HATEOAS in a new Controller

To implement HATEOAS you can do it in your main controller but in this case we will create a new PostsController where you will be able to get the HATEOAS responses.

[ApiController]
[Route("api/hateoas/posts")]
public class PostsHateoasController : ControllerBase
{
    private readonly ILinksService linksService;
    private readonly IPostRepository postRepository;
    private readonly IMapper mapper;

    public PostsHateoasController(ILinksService linksService, IPostRepository postRepository, IMapper mapper)
    {
        this.linksService = linksService;
        this.postRepository = postRepository;
        this.mapper = mapper;
    }

    [HttpGet(Name = nameof(Get))]
    public async Task Get([FromQuery] QueryParameters parameters)
    {
        var posts = await postRepository.GetPostAsync(parameters);
        var postsDto = mapper.Map>(posts);

        var hateoasResults = new List();

        foreach (var post in postsDto)
        {
            var hateoasResult = new PostHateoasResponse { Data = post};
            await linksService.AddLinksAsync(hateoasResult);
            hateoasResults.Add(hateoasResult);
        }

        return Ok(hateoasResults);
    }

    [HttpGet("{id:int}", Name = nameof(GetById))]
    public async Task GetById(int id)
    {
        var post = await postRepository.GetPostAsync(id);
        var postDto = mapper.Map(post);

        var hateoasResult = new PostHateoasResponse{Data = postDto};
        await linksService.AddLinksAsync(hateoasResult);

        return Ok(hateoasResult);
    }

    [HttpPost(Name = nameof(Post))]
    public async Task Post(AddPostDTO addPostDTO)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }

        var newPost = mapper.Map(addPostDTO);
        newPost.CreatedDate = DateTime.Now;
        await postRepository.AddAsync(newPost);
        return CreatedAtAction(nameof(Get), new { id = newPost.Id }, null);
    }

    [HttpPut("{id:int}", Name = nameof(Edit))]
    public async Task Edit(int id, [FromBody] EditPostDTO editPostDto)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }

        var post = mapper.Map(editPostDto);

        post.LastUpdated = DateTime.Now;
        await postRepository.EditAsync(post);
	      return NoContent();
    }

    [HttpDelete("{id:int}", Name = nameof(Delete))]
    public async Task Delete(int id)
    {
        await postRepository.DeleteAsync(id);
        return NoContent();
    }

    [HttpPatch("{id:int}", Name = nameof(Patch))]
    public async Task Patch(int id, [FromBody] JsonPatchDocument doc)
    {
        var post = await postRepository.GetPostAsync(id);

        doc.ApplyTo(post);
        await postRepository.EditAsync(post);

        return NoContent();
    }
}

First, define the route attribute as [Route("api/hateoas/posts")] then in the constructor add a dependency to the ILinksService interface to create the links. Above every controller in the method attribute, you will have to add the name of the method to be able to call it from the services contained in the program class later. All the methods remain the same but for the Get methods for example in the Get method a list of PostHateoasResponse is created to populate it with a foreach loop that takes every PostResponseDto and creates the links for every method and finally adds that response to the List and return that list. For the GetById method, it’s the same process but no foreach loop is needed as you will only create the links for a single resource and then return it.

Register the Links Service in the program class

Finally to set up the HATEOAS implementation you will have to register the LinksService in the services container as shown below.

builder.Services.AddLinks(config =>
{
    config.AddPolicy(policy =>
    {
        policy
            .RequireRoutedLink(nameof(PostsHateoasController.Get), nameof(PostsHateoasController.Get))
            .RequireRoutedLink(nameof(PostsHateoasController.GetById), nameof(PostsHateoasController.GetById), _ => new {id = _.Data.Id})
            .RequireRoutedLink(nameof(PostsHateoasController.Edit), nameof(PostsHateoasController.Edit), x => new {id = x.Data.Id})
            .RequireRoutedLink(nameof(PostsHateoasController.Delete), nameof(PostsHateoasController.Delete), x => new {id = x.Data.Id})
            .RequireRoutedLink(nameof(PostsHateoasController.Patch), nameof(PostsHateoasController.Patch), x => new {id = x.Data.Id});
    });
});

Here you need to call a RequiredRoutedLink for every endpoint in your controller in this case we are supporting GET, GET(id), POST, PUT, DELETE & PATCH.

Test your web API and inspect the new Response

Now you are ready to go and take your API for a test and you will be able to see the changes right away on the Get and Get(id) methods as these are the only two methods that actually return something different to a NoContent response as the other three methods.

Get Post HATEOAS Response

Here you can appreciate the response for a single post, the Get all posts will return a much much larger response and to save some space I will not post an example as you can figure out how it will look or you can run your own test.

{
  "data": {
    "id": 13,
    "title": "Github Basics",
    "body": "New Body",
    "createdDate": "0001-01-01T00:00:00",
    "author": {
      "id": 5,
      "name": "Oscar Montenegro"
    },
    "tags": [
      {
        "id": 1,
        "name": "My first Tag",
        "description": "This is the first Tag"
      },
      {
        "id": 2,
        "name": "Programming",
        "description": "Topics related to programming"
      },
      {
        "id": 4,
        "name": "DevOps",
        "description": "Learn the latest DevOps trends and news"
      }
    ]
  },
  "links": {
    "Get": {
      "rel": "PostsHateoas/Get",
      "href": "",
      "method": "GET"
    },
    "GetById": {
      "rel": "PostsHateoas/GetById",
      "href": "",
      "method": "GET"
    },
    "Edit": {
      "rel": "PostsHateoas/Edit",
      "href": "",
      "method": "PUT"
    },
    "Delete": {
      "rel": "PostsHateoas/Delete",
      "href": "",
      "method": "DELETE"
    },
    "Patch": {
      "rel": "PostsHateoas/Patch",
      "href": "",
      "method": "PATCH"
    }
  }
}

Conclusion

Implementing HATEOAS in our ASP NET Core Web APIs unlocks a wealth of benefits, including improved discoverability, enhanced navigability, and a more intuitive client experience. By embracing the principles of HATEOAS and leveraging hypermedia links, we empower clients to dynamically explore and interact with our APIs.

As you continue to develop your ASP NET Core Web APIs, consider incorporating HATEOAS to create more robust and user-friendly interfaces. By embracing this architectural principle, you'll be able to build APIs that provide seamless navigation, decoupled interactions, and a more adaptable design.

Almost Hitting 5K monthly views

Unit Coding

Learn software development creating fun & amazing projects and get professional developers advice on life and work.

Unit Coding

I can’t hide my happiness as this has been an amazing week full of work, reaching milestones, and planning new content for your guys I enjoy to be constantly learning something new to share with this beautiful community. I can’t help but thank you all for your support this helps me to create even more amazing and quality content for you as I know you have been enjoying reading this series and we are reaching the end of it, I’m so excited to create a grand finale and to continue with more great content. Please help me sharing this on your networks and with other fellow developers that are still learning or that have time developing but that you think they will get value from reading this articles. Thank you guys for everything, have a great day and happy coding!

Exposing Related Entities in your Web API

Oscar Montenegro — Wed, 31 May 2023 16:30:43 GMT

When working on building a powerful API you will find yourself dealing with resources and more resources and these “resources” have “relations” between them and this is powerful as we can leverage the power of relational data to create amazing ways of displaying information or use it. But if you don’t really understand how to define this relationship as I showed you in my last article about Relationships in Entity Framework Core or you don’t know how to make them work together as you will see later in this post, then it can be a nightmare to work with primary keys, constraints, LINQ, etc. 😰

Relationships in Entity Framework Core

Unit CodingOscar Montenegro

So for that reason, it’s a necessary skill to know how to expose and represent the related entities from your web API resources. This article will teach you how to achieve that while building meaningful endpoints to get the required resources.

Related entities refer to interconnected entities or objects within a data model. In the context of databases and ORMs (Object-Relational Mapping) like Entity Framework Core, related entities represent the associations and relationships between different tables or entities in a database schema.

These relationships come in different flavors, such as one-to-one, one-to-many, or many-to-many. They basically tell us how the pieces fit together. For example, in a blog application, a post may have one author (one-to-one), or an author can have multiple posts (one-to-many). These relationships bring structure and meaning to our data.

Understanding these relationships is like unlocking the secrets of your data model. It allows you to create more complex and intertwined models, giving you the power to fetch and manipulate related data effortlessly. You can easily access information from different entities, perform queries, and build powerful applications.

To sum it up, related entities are the links between data pieces in your database. They give your data model its structure and define how the different parts work together. With a good grasp of these relationships, you can navigate through your data, create efficient queries, and build amazing applications.

Exposing related entities in ASP.NET Core Web API involves making those connections accessible and retrievable to clients who interact with your API. By exposing related entities, you allow clients to access and manipulate interconnected data in a meaningful way.

There are several approaches you can take to achieve this:

Nested Serialization: One way is to include related entities as nested objects within the JSON response. For example, when retrieving a blog post, you can also include the author information as part of the response, making it easy for clients to access both the post and its author in a single request.
Expandable Endpoints: Another approach is to provide expandable endpoints, where clients can specify which related entities they want to include in the response. This gives clients more control over the data they receive, reducing unnecessary data transfer and improving performance.
Hypermedia Links: Hypermedia-driven APIs use links to represent relationships between entities. By including links in your API responses, clients can navigate through related entities by following these links. This approach provides a more dynamic and flexible way to expose related entities.
Custom Endpoints: Depending on your application's requirements, you can create custom endpoints specifically designed to retrieve related entities. For example, you might have an endpoint that returns all the comments associated with a blog post or all the products in a specific category.

When exposing related entities, it's essential to consider factors like performance, data size, and security. You want to strike a balance between providing enough related data for clients to work with and avoiding excessive data transfer that could impact performance.

In this article, we will end up using a mix of those approaches to return the client all the resources needed.

Get the code from GitHub

As always before we get into the code if you want to follow along with this tutorial make sure you get the code from the GitHub repository and double-check that you are getting the code from the “EfCoreRelationship” branch.

GitHub - Osempu/BlogAPI at EfCoreRelationships

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Updating the PostRepository class

The PostRepository class has been retrieving the posts from the database but it lacks power as it is not returning the author for every repository only the authorId and neither is returning the tags that the Post has so for that reason we will extend the functionality of the repository class updating its methods and adding two new methods.

IRepository class updated

public interface IPostRepository 
{
    Task> GetPostAsync(QueryParameters parameters);
    Task GetPostAsync(int id);
    Task> GetPostByAuthorId(int id);
    Task> GetPostByTagId(int id);
    Task AddAsync(Post post);
    Task EditAsync(Post post);
    Task DeleteAsync(int id);
}

As you can see there are two new methods GetPostByAuthorId and GetPostByTagId this is to retrieve all the posts from the user and all the posts related to a specific tag which is the normal filter functionality of any existing blog.

PostRepository Class

public async Task> GetPostAsync(QueryParameters parameters)
{
		//Code ommited for brevity
    var pagedPosts = await allPosts
            .Skip((parameters.PageNumber - 1) * parameters.PageSize)
            .Take(parameters.PageSize)
            .Include(x => x.Author)
            .Include(x => x.Tags)
            .ToListAsync();

    return pagedPosts;
}

public async Task GetPostAsync(int id)
{
    var post = await context.Posts.AsNoTracking()
                                    .Where(x => x.Id == id)
                                    .Include(x => x.Author)
                                    .Include(x => x.Tags)
                                    .FirstOrDefaultAsync();
    return post;
}

public async Task> GetPostByAuthorId(int id)
{
    var posts = await context.Posts.AsNoTracking()
                                    .Where(x => x.AuthorId == id)
                                    .Include(x => x.Author)
                                    .Include(x => x.Tags)
                                    .ToListAsync();
    return posts;
}

public async Task> GetPostByTagId(int id)
{
    var posts = await context.Posts.AsNoTracking()
                                    .Include(x => x.Author)
                                    .Include(x => x.Tags)
                                    .Where(x => x.Tags.Any(t => t.Id == id))
                                    .ToListAsync();

    return posts;
}

The first method is the GetPostAsync that we created to retrieve a paginated response for all the posts. Here your work is to include the author of the post and the related tags for every post. So in the final query before calling the ToListAsync you will add two calls to the Include method one for the author and the second for the tags, this way your post response will now include those data sets.

The next method is the GetPostByAuthorId method which will return all the posts belonging to a single author. First, you filter the post from the author with the corresponding Id and then again you call two Include methods to add the author and tag data to the response.

Finally, the GetPostByTagId is similar to the GetPostByAuthorId but you will notice that first there are the two calls to the Include method and then a filter using where to filter by the specified Tag. This must be done this way because the Post ⇒ Tag relation is a many-to-many relationship therefore there is not a single tag to filter from as with the Author but a set of tags and we need to select the one we desire to filter for.

Foreseeing Self-Reference Loop from Property Error

Now you would likely go to the Post controller and update it to test the new changes right? Well, it’s not that simple because if you go and actually do that then you will get a self-reference error because when you try to get a list of posts you will get the author with it, and then you would get the posts again and you will get it’s author and you kinda see where this is going right? Yep, it’s an infinite loop and you know that programming and infinite loops don’t get along in most of cases so to avoid that you will have to use Dtos to return your resources because something you should not do is to return your data models as they are, it’s always a good practice to create some Dtos to only return the data we want to show and avoid this kind of problems and the second thing you must do in order to avoid an infinite loop in your response is to add some configurations to NewtonsoftJson

.AddNewtonsoftJson(options => options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore);

The above line of code will prevent the reference loop to continue over and over by ignoring the request to be continuously returning the nested JSON.

Adding some new Dtos

public record AuthorOnlyResponseDto(int Id, string Name);
public record TagOnlyResponseDto(int Id, string Name, string Description);

As said earlier you will need to use Dtos to return the resources in this case we are returning the author without the collection of Post and the Tag without the collection of Post as well.

Updating PostResponseDto

public record PostResponseDTO(
  [property: JsonPropertyOrder(1)] int Id,
  [property: JsonPropertyOrder(2)] string Title,
  [property: JsonPropertyOrder(3)] string Body,
  [property: JsonPropertyOrder(4)] DateTime CreatedDate,
  [property: JsonPropertyOrder(5)] AuthorOnlyResponseDto Author,
  [property: JsonPropertyOrder(6)] ICollection Tags);

In this Dto there are some things happening. First, we are adding the JsonPropertyOrder attribute to set the order in which every property will be returned to have a nicely formatted response because otherwise the properties are ordered alphabetically for the Author now we return an AuthorOnlyResponse so we just return the author resource without the nested Post collection and finally, we return a collection of TagOnlyResponseDto to return only the collection of Tag without the nested Post.

Adding the new mapping profiles

Now to have your Dtos working add the corresponding mappings to their profile classes as shown below.

public AuthorProfiles()
{
    CreateMap();
}

public TagProfiles()
{
    CreateMap();
}

Updating the AuthorsController

After the changes in the PostRepository class there is no need to update the PostsController as all we needed in the controller was to return the author and tags related to the post and that is done in the repository class so now you have to update the Authors and Tags controllers to add an endpoint to return all the post under a certain author and the same for the tags.

[ApiController]
[Route("api/authors")]
public class AuthorsController : ControllerBase
{
    private readonly IAuthorRepository repository;
    private readonly IPostRepository postRepository;
    private readonly IMapper mapper;

    public AuthorsController(IAuthorRepository repository, IPostRepository postRepository, IMapper mapper)
    {
        this.repository = repository;
        this.postRepository = postRepository;
        this.mapper = mapper;
    }

		[HttpGet]
	  public async Task GetAuthor()
	  {
	      var authors = await repository.GetAsync();
	      var authorsDto = mapper.Map>(authors);
	      return Ok(authorsDto);
	  }
	
		[HttpGet("{id:int}")]
		public async Task GetAuthor(int id)
		{
		    var author = await repository.GetAsync(id);
		    var authorDto = mapper.Map(author);
		    return Ok(authorDto);
		}
		
		[HttpGet("{id:int}/posts")]
		public async Task GetPostByAuthorId(int id)
		{
		    var posts = await postRepository.GetPostByAuthorId(id);
		    var postDto = mapper.Map>(posts);
		
		    return Ok(postDto);
		}
}

You will need to add a reference to the IPostRepository interface to get the collection of posts from an author. Then on both Get methods you only have to map the response from Author to an AuthorOnlyResponseDto to return only the author resource and not its nested resources.

Finally, you will have to add a new endpoint names GetPostByAuthorId which will retrieve all the posts from a certain author. First, you have to specify the route as {id:int}/posts so the way of calling this endpoint would be like this api/authors/{authoId}/posts and this will give us all the posts from the specified author. The code is pretty much like both previous get methods but instead of using the author repository here, you will need to call the postRepository.GetPostByAuthorId method and after that map the response into a PostResponseDto.

Updating the TagsController

[ApiController]
[Route("api/tags")]
public class TagsController : ControllerBase
{
    private readonly ITagRepository repository;
    private readonly IPostRepository postRepository;
    private readonly IMapper mapper;

    public TagsController(ITagRepository repository, IPostRepository postRepository ,IMapper mapper)
    {
        this.repository = repository;
        this.postRepository = postRepository;
        this.mapper = mapper;
    }

    [HttpGet]
    public async Task GetTag()
    {
        var tags = await repository.GetAsync();
        var tagsDto = mapper.Map>(tags);
        return Ok(tagsDto);
    }

    [HttpGet("{id:int}")]
    public async Task GetTag(int id)
    {
        var tag = await repository.GetAsync(id);
        var tagDto = mapper.Map(tag);
        return Ok(tagDto);
    }

    [HttpGet("{id:int}/posts")]
    public async Task GetPostFromTagId(int id)
    {
        var posts = await postRepository.GetPostByTagId(id);
        var postsDto = mapper.Map>(posts);
        return Ok(postsDto);
    }
}

For the TagsController the thing is pretty much the same, you have to inject the IPostRepository interface and then update the get methods mapping the response to a TagOnlyResponseDto and finally add a new endpoint to get all the Posts under a certain Tag.

Testing the API

Now let’s proceed to test the new endpoints and check out our updated responses.

Getting all the Authors

[
  {
    "id": 4,
    "name": "John Doe"
  },
  {
    "id": 5,
    "name": "Oscar Montenegro"
  },
  {
    "id": 6,
    "name": "Yolanda Montenegro"
  }
]

In the authors controller we are getting only the authors id and name, exposing only the data we ant without exposing the nested collection of post for every author for that we will use the new endpoint.

Getting all the Posts from an Author

[
  {
    "id": 11,
    "title": "Setting up a CI/CD Pipeline",
    "body": "Setup a CI/CD Pipeline using GitHub actions",
    "createdDate": "2023-05-29T13:25:52.0306732",
    "author": {
      "id": 5,
      "name": "Oscar Montenegro"
    },
    "tags": [
      {
        "id": 2,
        "name": "Programming",
        "description": "Topics related to programming"
      }
    ]
  },
  {
    "id": 13,
    "title": "GitHub basics",
    "body": "Check out this amazing series on the GitHub basics to start working on a code repository",
    "createdDate": "2023-05-30T14:25:48.3537618",
    "author": {
      "id": 5,
      "name": "Oscar Montenegro"
    },
    "tags": [
      {
        "id": 1,
        "name": "My first Tag",
        "description": "This is the first Tag"
      },
      {
        "id": 2,
        "name": "Programming",
        "description": "Topics related to programming"
      },
      {
        "id": 4,
        "name": "DevOps",
        "description": "Learn the latest DevOps trends and news"
      }
    ]
  }
]

Here we are getting all the posts for the author with an id of 5 and what makes sense when you get a Post is to get the author from that post and the related tags for that post as well. For that reason, this is the optimal Post response exposing the related and relevant entities. The response is nicely formated presenting the post properties and then exposing the author and finally an array of tags.

Getting all the Tags

[
  {
    "id": 1,
    "name": "My first Tag",
    "description": "This is the first Tag"
  },
  {
    "id": 2,
    "name": "Programming",
    "description": "Topics related to programming"
  },
  {
    "id": 4,
    "name": "DevOps",
    "description": "Learn the latest DevOps trends and news"
  }
]

Now the tags are returning only the properties we want to expose on this endpoint being this the name and the description and the collection of posts related to each tag can be retrieved in a separate endpoint.

[
  {
    "id": 11,
    "title": "Setting up a CI/CD Pipeline",
    "body": "Setup a CI/CD Pipeline using GitHub actions",
    "createdDate": "2023-05-29T13:25:52.0306732",
    "author": {
      "id": 5,
      "name": "Oscar Montenegro"
    },
    "tags": [
      {
        "id": 2,
        "name": "Programming",
        "description": "Topics related to programming"
      }
    ]
  },
  {
    "id": 13,
    "title": "GitHub basics",
    "body": "Check out this amazing series on the GitHub basics to start working on a code repository",
    "createdDate": "2023-05-30T14:25:48.3537618",
    "author": {
      "id": 5,
      "name": "Oscar Montenegro"
    },
    "tags": [
      {
        "id": 1,
        "name": "My first Tag",
        "description": "This is the first Tag"
      },
      {
        "id": 2,
        "name": "Programming",
        "description": "Topics related to programming"
      },
      {
        "id": 4,
        "name": "DevOps",
        "description": "Learn the latest DevOps trends and news"
      }
    ]
  }
]

This response is produced after calling the api/tags/2/posts endpoint which returns all the posts related to the programming tag and as before you can see that the response contains the post properties along with the author of the post and the related tags.

Posts Controller

The response in the posts controller will look the same as before so for that reason I will not post the response to save you from reading the same 😅 but is important to say again that we have formatted the post response just the way we wanted and in a way that makes sense so whenever the client looks for a post or a collection of posts they contain all the needed data to display the post with the author name and the collection of tags for that post.

Conclusion

To wrap it up, exposing related entities in your web API opens up a world of possibilities for working with interconnected data. By making these relationships accessible to clients, you empower them to effortlessly retrieve, modify, and navigate through linked data.

It's crucial to strike a balance between providing enough related data and optimizing performance when designing your API endpoints and responses. Factors like data size, performance impact, and security requirements should be taken into account to ensure a smooth and efficient experience for API users.

As you continue to develop your web API, make use of the strategies and techniques discussed in this article to effectively expose related entities. Remember to align your approach with the specific requirements and objectives of your application.

Armed with the knowledge and understanding of how to expose related entities, you can take your ASP.NET Core Web API to new heights. By implementing the right approach, you'll create an API that offers seamless navigation, robust data retrieval, and efficient manipulation of interconnected data.

We’ve reached 3K views on Unit Coding

I’m so happy to share that the last weekend after posting my article about Entity framework relationships I was expecting to reach 1K monthly views but suddenly when I woke up on Saturday I checked and there were more than 2K views only in one night! Man, I was so happy and today we passed the 3K views. I want to thank all of you guys that have been checking out my content and constantly reading, without you this would have not been possible so this is an achievement for all of us that make part of this community.

Also, I want to share with you that this series has somewhere 10 posts before it comes to an end and I’m already getting ready for all the new series I want to launch for example a series on Web App development with Blazor, ASP NET MVC, LINQ and so many more and after finishing this series on web API development I will announce the launch of a surprise to all of you that have been supporting me all along this amazing journey of becoming a writer it will be free so star posted so you don’t lose it.

There are so many words in my mind that I cannot express and so many things have been happening since the beginning of this journey. I’m on my third month unemployed, it’s been hard and I’m almost running out of money (no joke 😨) but I know I’m not out of options and there are some things that I can do before that happens. Well, I think that I must say goodbye for now because I’m making this longer than it should be 😂 thanks for your kind support and beautiful words, remember to follow me on my blog Unit Coding, and on my YouTube channel under the same name and if you like Twitter you can find me there as @OscarOsempu I’m still trying to get constant at twitting but it’s sometimes hard. Thanks and see you in the next chapter! Happy coding! 👋🏾

Relationships in Entity Framework Core

Oscar Montenegro — Fri, 26 May 2023 23:10:50 GMT

Hello guys, welcome to yet another exciting chapter of this series on developing a web API with ASP NET Core. Today we will move on to an advanced topic “Relationships on entity framework core” We will create more models that are a vital part of a blog, for example, authors and tags and you will learn how they relate to each other and how to configure those relationships using different approaches of entity framework core, also I will leave down a link to the last chapter of this series, it was about “Understanding the filter pipeline” which is something you should understand to leverage the power of action filters in your web apps, and having said this without a further ado let’s get into it.

Understanding The Filter Pipeline In ASP.NET Core

Hey guys I’m so happy to be writing again after a long absence I was sick and also I’m looking for a job so a lot of things are happening right now but the post I have prepared for you today is all worth the wait. In my

Unit CodingOscar Montenegro

What are relationships in Entity Framework Core

In Entity Framework Core, relationships refer to how different database tables or entities are connected or related to each other. Just like in real life, where people, objects, or concepts can have relationships with each other, databases also have relationships between tables.

Think of a relationship as a way to establish a connection between two entities in a database. These entities could represent real-world objects or concepts, such as customers and orders in an e-commerce application. By defining relationships, we can specify how these entities are associated and how they interact with each other.

Entity Framework Core allows us to define and manage different types of relationships between entities, which helps in organizing and retrieving data effectively. These relationships can be one-to-one, one-to-many, or many-to-many, depending on the nature of the data and the requirements of our application.

One-to-One Relationship

In a one-to-one relationship, it's like having a special connection between two things. It means that each record in one table is associated with exactly one record in another table, and vice versa.
Think of it like a person and their passport. Each person has only one passport, and that passport is unique to that person. So, we can say that the person and the passport have a one-to-one relationship.
In database terms, this relationship is useful when we want to split information about an entity into separate tables to maintain cleanliness and avoid duplicating data.

// Entities
public class Person
{
    public int PersonId { get; set; }
    public string Name { get; set; }
    public Passport Passport { get; set; }
}

public class Passport
{
    public int PassportId { get; set; }
    public string City { get; set; }
    public Person Person { get; set; }
}

// Configuration
public class MyContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity()
            .HasOne(p => p.Passport)
            .WithOne(a => a.Person)
            .HasForeignKey(a => a.PassportId);
    }
}

One-to-Many Relationship

A one-to-many relationship is like a parent-child relationship, where one record in a table is associated with multiple records in another table.
For example, think of a bookstore. Each book can have many reviews, but each review is tied to only one book. So, we can say that the relationship between books and reviews is one-to-many.
In database terms, this relationship is useful when we need to represent situations where one entity can have multiple related entities.

// Entities
public class Book
{
    public int BookId { get; set; }
    public string Name { get; set; }
    public ICollection Reviews { get; set; }
}

public class Review
{
    public int ReviewId { get; set; }
    public string Reviewer { get; set; }
    public Book Book { get; set; }
}

// Configuration
public class MyContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity()
            .HasOne(r => r.Book)
            .WithMany(b => b.Reviews)
            .HasForeignKey(r => r.BookId);
    }
}

Many-to-Many Relationship

A many-to-many relationship is like a group of friends. Each person can have many friends, and each friend can have many people they are friends with.
For example, think of students and courses. A student can enroll in multiple courses, and each course can have multiple students. So, we can say that students and courses have a many-to-many relationship.
In database terms, this relationship is implemented using an intermediary table, often called a junction or join table, to connect the entities.

// Entities
public class Student
{
    public int StudentId { get; set; }
    public string Name { get; set; }
    public ICollection Courses { get; set; }
}

public class Course
{
    public int CourseId { get; set; }
    public string Name { get; set; }
    public ICollection Students { get; set; }
}

// Configuration
public class MyContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity()
            .HasMany(s => s.Courses)
            .WithMany(c => c.Students)
            .UsingEntity(j => j.ToTable("StudentCourse"));
    }
}

Configurations in Entity Framework Core

Relationship configurations in Entity Framework Core are a way to define and control how different entities are related to each other in a database. These configurations help establish the rules and behavior of the relationships between entities, such as how they are mapped to database tables, how foreign key constraints are created, and how navigation properties are set up.

Above I listed all the relationships and showed you how to set them up using the fluent API configuration because it’s my favorite way to do it as it keeps my models clean and free of data annotations but it doesn’t have to be the same for you, maybe you do like using data annotations or setup the relationships by convention which by the way is a pretty powerful way to do it too so I will show you how to use these three type of configurations.

To configure these relationships, Entity Framework Core provides different ways to specify the rules. There are three common approaches to relationship configuration.

By Convention

Entity Framework Core has a set of conventions that can automatically configure relationships based on naming conventions and default behaviors. For example, if you have a navigation property named "Address" in the "Person" entity, Entity Framework Core will assume it's a one-to-one relationship and configure it accordingly. This approach is convenient when your code follows the naming conventions expected by Entity Framework Core.

// Entities
public class Person
{
    public int PersonId { get; set; }
    public string Name { get; set; }
    public Address Address { get; set; }
}

public class Address
{
    public int AddressId { get; set; }
    public string City { get; set; }
    public Person Person { get; set; }
}

Data Annotations

Data annotations are attributes that you can apply to your entity classes and properties to specify relationship configurations. For example, you can use the [ForeignKey] attribute to specify the foreign key property or the [InverseProperty] attribute to specify the navigation property for a relationship. Data annotations are helpful when you want to explicitly define the relationships within your entity classes using attributes.

// Entities
public class Person
{
    public int PersonId { get; set; }
    public string Name { get; set; }

    [ForeignKey("Address")]
    public int AddressId { get; set; }
    public Address Address { get; set; }
}

public class Address
{
    [Key, ForeignKey("Person")]
    public int AddressId { get; set; }
    public string City { get; set; }
    public Person Person { get; set; }
}

Entity Framework Core provides several data annotations that you can use to configure entities and their relationships. These data annotations can be applied to entity classes and properties to specify various aspects of the configuration. Here are some commonly used data annotations for entity configuration:

[Key]: Specifies the primary key property of an entity. By default, Entity Framework Core assumes that a property named "Id" or "Id" is the primary key, but you can use this annotation to explicitly designate a property as the primary key.
[ForeignKey]: Specifies the foreign key property in a relationship. This annotation is used to define the foreign key column that relates to another entity.
[Required]: Indicates that a property is required and cannot be null. This annotation ensures that the corresponding column in the database is configured as non-nullable.
[MaxLength]: Sets the maximum length or size for a string or byte array property. It can be used to limit the length of a string column in the database.
[Column]: Specifies the name of the column in the database associated with a property. This annotation allows you to define custom column names.
[Table]: Specifies the table name for an entity in the database. It can be used to override the default table name generated by Entity Framework Core.
[NotMapped]: Excludes a property from being mapped to a column in the database. This annotation is useful when you have properties in your entity that don't have corresponding columns in the database.
[InverseProperty]: Specifies the inverse navigation property for a relationship. It is used when you have multiple navigation properties between two entities and need to specify the inverse relationship explicitly.
[Index]: Indicates that an index should be created on one or more columns in the database. This annotation can improve query performance by optimizing data retrieval.

Fluent API

Fluent API provides a more flexible and explicit way to configure relationships. With the Fluent API, you can use a set of builder methods to define the relationships between entities. This approach gives you fine-grained control over how the relationships are configured and allows you to specify additional options like cascading delete behavior, index creation, or table names.

// Entities
public class Person
{
    public int PersonId { get; set; }
    public string Name { get; set; }
    public Address Address { get; set; }
}

public class Address
{
    public int AddressId { get; set; }
    public string City { get; set; }
    public Person Person { get; set; }
}

// Configuration
public class MyContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity()
            .HasOne(p => p.Address)
            .WithOne(a => a.Person)
            .HasForeignKey(a => a.AddressId);
    }
}

Whether you choose to configure relationships by convention, data annotations, or fluent API depends on your preference and specific requirements. Using any of these approaches, you can define the relationships between entities in a clear and understandable manner, ensuring that your database schema and entity model are aligned and properly represented.

Implementing Entities Relationships in Your Project

Now let’s move on to apply the needed relationships in your web API or any kind of web project. We will use the same project we have been using for so long the “Blog API” which you can clone from GitHub using the link down below, make sure you get the code from the “ActionFilters” branch which contains the code up to this chapter.

GitHub - Osempu/BlogAPI at ActionFilters

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Adding new Models

⚠️ Important Note: I will not show you all the code changes the project suffered at this stage as two new models were added there was a need to create relationships, update old dtos, and add repositories and mapping profiles to say the least. But do not worry you will be able to get the code from GitHub at the end of this article to compare with your changes or to directly go and clone the branch.

Let’s begin by adding two new needed models to create the relationships between them and enrich our project domain layer.

Author Model

Every Post will have an author and every author can have many posts as he wants so the model would end up looking like this, you will add an ICollection which will be the collection navigation property

public class Tag
{
	public int Id { get; set; }
    public string Name { get; set; }

    public ICollection Posts { get; set; }
}

Tag model

Every Post can have multiple tags and every Tag can be applied to any number of posts so this will be a many-to-many relationship. The model will contain some basic properties and again a collection navigation property ICollection.

public class Tag
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }

    public ICollection Posts { get; set; }
}

Updating the Post model

The post model suffered some changes as now we have two other models that interact and have a direct relationship with it so we added a navigation property for the Author of the post and a collection navigation property for the Tags.

public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Body { get; set; }
    public DateTime CreatedDate { get; set; }
    public DateTime LastUpdated { get; set; }

    public int AuthorId { get; set; }
    public Author Author { get; set; }

    public ICollection Tags { get; set; }
}

Important Note: Now that the Author of a post is an entity and not a single string this means that you will have to change the PostDto’s that were created before now instead of specifying the name of the author to add it you will need to specify the id of that author to create a relationship between the post and the author.

Post Dtos updated

public record AddPostDTO(string Title, string Body, int AuthorId);

public record EditPostDTO(int Id, string Title, string Body, int AuthorId);

Configure the Entities Relationships

Now go to your PostConfiguration class and update it adding the relationship with the Tag and Author models, down below you can see how it will end looking using the EF Core Fluent API.

public class PostConfiguration : IEntityTypeConfiguration
  {
      public void Configure(EntityTypeBuilder builder)
      {
          builder.HasOne( p => p.Author)
              .WithMany( a => a.Posts)
              .HasForeignKey( p => p.AuthorId);

          builder.HasMany( p => p.Tags)
              .WithMany( t => t.Posts)
              .UsingEntity( j => j.ToTable("PostTag"));

					//Data seeding ** this is not used for relationship configuration **
          builder.HasData(
              new Post {Id = 1, Author = new Author {Id = 1, Name = "Oscar Montenegro"}, Title = "My first Post", Body = "Hello world, this is my first post"},
              new Post {Id = 2, Author = new Author {Id = 2, Name = "Another Author"}, Title = "My second Post", Body = "Hello world, this is my second post"}
          );
      }
  }

Update your Database

Now that you have all the changes in place the only thing that you need to do is to update your database. For this, I recommend you delete your old database to avoid having problems and to be able to update it seamlessly.

Now perform the next dotnet ef commands to add a new migration and update your database.

dotnet ef migrations add "Added new entities and applied relationships"

dotnet ef database update

Now if you go to your SQL Server Management System you should be able to see your database and if you get into the Database Diagrams folder it will ask you if you want to create a new diagram, say yes and select the tables you want to include and then you should have something like this.

On this DB diagram we can appreciate that indeed every post can have a single author and an author can have many posts (check the key and kind of infinite symbols). And for the Tag ⇒ Post relationship we can see that we have another intermediate table (junction table) that holds both Post and Tag id which makes the many-to-many relationship.

Adding functionality to your new Models

Now comes the hard part, you added the entities relationships and the new models as well but know you need to add their controllers, mapping profiles, Dtos, Repositories, and IRepositories to make sure that you can add, create, read, update,e and delete resources for both the Tag and Author entities.

As I said earlier I won’t be showing the code for all these updates but you can get them here from GitHub.

GitHub - Osempu/BlogAPI at EfCoreRelationships

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Test your application

As always the moment has come to test your application, you could test your API without having the controllers or repositories as you can insert some records directly to SQL Server using the SSMS (SQL Server Management System). But I would not recommend you this as anyways you will need those controllers and repos in the future so why not code them now right? take it as an assignment.

Conclusion

Entity Framework Core is an amazing tool that makes dealing with different types of relationships in your database a breeze. Whether you're working with one-to-one, one-to-many, or many-to-many relationships, Entity Framework Core has got you covered. It even supports self-referencing and required/optional relationships, giving you the flexibility to design your database schema just the way you want. With Entity Framework Core, you can create scalable and maintainable ASP.NET Core applications without breaking a sweat. So, let's dive in and explore the power of Entity Framework Core's relationship capabilities. Get ready to unleash your coding skills and enjoy the journey!

Support me on my Journey as a Writer and Content Creator!

This is the time of the day when I take some time to thank all the amazing people that have supported me and followed this series all along with my other C# projects giving me such energy to continue. But if you are new to my blogs please consider supporting me on my Blog Unit Coding and also on my YouTube channel under the same name where I returned after a long hiatus and plan to continue with the streak, also you can find me on Twitter as @OscarOsempu. Thanks for your time in reading my article I hope you can get tons of value from it and that It solved all your doubts about this amazing topic. Thanks for everything, I’ll see you soon in my next article!

Understanding The Filter Pipeline In ASP.NET Core

Oscar Montenegro — Wed, 24 May 2023 04:31:18 GMT

In my last article, I talked to you guys about how to use the patch request to partially update your web API resources and I put a lot of effort to show you all the types of operations that the patch method supports and how you could use them so I leave a link to that article if you want to check it out. Ok now let's get into today's article.

How to Use Patch Requests to Update Resources in Your REST API

Hello guys, Oscar here with another amazing chapter on REST API Development with ASP NET 7. Today we have an amazing and relevant topic for our APIs to have more power and flexibility at the time of updating our API resources. If you’re familiar with HTTP requests, you’ve probably heard

Unit CodingOscar Montenegro

Actually, when I first learned about action filters I had a hard time understanding them and they did not look appealing or exciting to me so I pushed myself to my limit to bring you something amazing even though I had a hard time enjoying it.

As a developer, you must have heard of the term 'Action Filters' when working with ASP.NET Core. Action filters are an essential part of the framework and can help you add additional functionality to your application. In this blog, we will explore what action filters are and why you should use them.

What is an Action Filter ?

An action filter is a type of filter that allows you to add additional behavior to the MVC framework's action methods. You can use them to execute code before or after an action method is executed, or to modify the results returned by the action method.

Why should I use Action Filters ?

Action filters offer several benefits, including:

Code Reusability: Action filters are reusable components that can be applied to multiple action methods, reducing code duplication and increasing maintainability.
Separation of Concerns: Action filters allow you to separate cross-cutting concerns from the rest of your code. For example, you can use an action filter to handle logging or caching logic, leaving your action methods focused on their specific functionality.
Customization: You can create custom action filters to add functionality that is specific to your application's needs.

Code Example of an Action Filter 🧑🏾‍💻

Let's take a look at an example of an action filter that logs the time it takes to execute an action method.

public class LogActionFilter : IActionFilter
{
    private readonly ILogger _logger;

    public LogActionFilter(ILogger logger)
    {
        _logger = logger;
    }

    public void OnActionExecuting(ActionExecutingContext context)
    {
        _logger.LogInformation($"Executing action {context.ActionDescriptor.DisplayName}.");
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        _logger.LogInformation($"Executed action {context.ActionDescriptor.DisplayName} in {context.HttpContext.Response.Headers["X-Elapsed-Time"]}.");
    }
}

In this example, we created a custom action filter called LogActionFilter that logs the time it takes to execute an action method. The OnActionExecuting method is called before the action method is executed, and the OnActionExecuted method is called after the action method is executed.

To use this action filter, we need to register it in the ConfigureServices method of our startup class:

services.AddScoped();

And then apply it to an action method by adding the [ServiceFilter(typeof(LogActionFilter))] attribute to the action method:

[ServiceFilter(typeof(LogActionFilter))]
public IActionResult Index()
{
    // Do something here
}

Type of Filters

ASP.NET Core has six types of filters: Authorization filters, Resource filters, Action filters, and Exception filters. Let's take a closer look at each type along with a code example for each.

1. Authorization Filters

Authorization filters are used to check if a user is authorized to access a particular resource or page. They are executed before the action method is invoked.

Here's an example of an authorization filter that checks if the user is authenticated:

public class CustomAuthorizationFilter : IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        if (!context.HttpContext.User.Identity.IsAuthenticated)
        {
            // Redirect to login page or return unauthorized response
            context.Result = new RedirectToActionResult("Login", "Account", null);
        }
    }
}

To apply this authorization filter to an action method, you can use the [Authorize] attribute along with the filter:

[Authorize]
[TypeFilter(typeof(CustomAuthorizationFilter))]
public IActionResult SecureAction()
{
    // Code for secure action
}

2. Resource Filters

Resource filters are used to perform tasks that are related to a particular resource. They are executed before and after the action method.

Here's an example of a resource filter that logs the start and end of the action method execution:

public class LoggingResourceFilter : IResourceFilter
{
    private readonly ILogger _logger;

    public LoggingResourceFilter(ILogger logger)
    {
        _logger = logger;
    }

    public void OnResourceExecuting(ResourceExecutingContext context)
    {
        _logger.LogInformation("Executing resource filter - Before action method");
    }

    public void OnResourceExecuted(ResourceExecutedContext context)
    {
        _logger.LogInformation("Executing resource filter - After action method");
    }
}

To apply this resource filter to an action method, you can use the [TypeFilter] attribute:

[TypeFilter(typeof(LoggingResourceFilter))]
public IActionResult MyAction()
{
    // Code for the action method
}

3. Action Filters

Action filters are used to perform tasks that are related to a particular action method. They are executed before and after the action method.

Here's an example of an action filter that logs the time it takes to execute an action method:

public class TimingActionFilter : IActionFilter
{
    private readonly Stopwatch _stopwatch;

    public TimingActionFilter()
    {
        _stopwatch = new Stopwatch();
    }

    public void OnActionExecuting(ActionExecutingContext context)
    {
        _stopwatch.Start();
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        _stopwatch.Stop();
        var elapsedMilliseconds = _stopwatch.ElapsedMilliseconds;
        // Log or use the elapsed time as needed
    }
}

To apply this action filter to an action method, you can use the [ServiceFilter] attribute:

[ServiceFilter(typeof(TimingActionFilter))]
public IActionResult MyAction()
{
    // Code for the action method
}

4. Exception Filters

Exception filters are used to handle exceptions that occur during the execution of an action method. They are executed when an exception is thrown.

Here's an example of an exception filter that handles and logs exceptions:

public class ExceptionLoggingFilter : IExceptionFilter
{
    private readonly ILogger _logger;

    public ExceptionLoggingFilter(ILogger logger)
    {
        _logger = logger;
    }

    public void OnException(ExceptionContext context)
    {
        _logger.LogError(context.Exception, "Exception occurred");
        // Handle the exception or perform any necessary actions
    }
}

To apply this exception filter to an action method, you can use the [TypeFilter] attribute:

[TypeFilter(typeof(ExceptionLoggingFilter))]
public IActionResult MyAction()
{
    // Code for the action method
}

5. Endpoint Filters

Endpoint filters are used to perform actions before and after an endpoint is selected during the routing process. They can be used to modify the selected endpoint or add additional behavior.

Here's an example of an endpoint filter that modifies the endpoint's metadata:

public class CustomEndpointFilter : IEndpointFilter
{
    public void OnEndpointSelected(EndpointSelectedContext context)
    {
        // Modify endpoint metadata or perform additional actions
        var endpoint = context.Endpoint;
        // Modify the endpoint as needed
    }
}

To apply this endpoint filter, you can use the AddEndpointFilter extension method in the ConfigureServices method of your Startup class:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers()
            .AddEndpointFilter();
}

6. Result Filters

Result filters are used to perform actions before and after the execution of an action result. They can modify the result, add headers, or perform additional operations.

Here's an example of a result filter that modifies the result by adding a custom header:

public class CustomResultFilter : IResultFilter
{
    public void OnResultExecuting(ResultExecutingContext context)
    {
        // Modify the result or add headers before the execution
        context.HttpContext.Response.Headers.Add("CustomHeader", "CustomValue");
    }

    public void OnResultExecuted(ResultExecutedContext context)
    {
        // Perform additional actions after the execution
    }
}

To apply this result filter to an action method, you can use the [ServiceFilter] attribute:

[ServiceFilter(typeof(CustomResultFilter))]
public IActionResult MyAction()
{
    // Code for the action method
}

Alternatively, you can apply the result filter globally to all action methods by using the AddMvcOptions method in the ConfigureServices method of your Startup class:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers(options =>
    {
        options.Filters.Add();
    });
}

By utilizing endpoint filters, you can modify endpoint metadata and add behavior during the routing process. Result filters, on the other hand, allow you to modify action results and perform additional actions before and after their execution. These filters provide flexibility and control over the behavior of your ASP.NET Core application.

By utilizing these different types of filters, you can enhance the behavior and functionality of your ASP.NET Core application, adding security checks, logging, exception handling, and resource-related tasks.

Filters Scope

Filters can be applied at different scopes, depending on where you want them to take effect. Let's explore the three main scopes: Global, Controller, and Action.

Global Filters

Global filters are applied to all action methods in your application. They are registered during application startup and provide common functionality or handle cross-cutting concerns throughout your application.

Example:

// Custom global filter implementing IActionFilter
public class GlobalLoggingFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        // Perform actions before the action method execution
        // Example: Logging or request validation
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // Perform actions after the action method execution
        // Example: Logging or response modification
    }
}

// Registering global filter in Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers(options =>
    {
        options.Filters.Add();
    });
}

Controller Filters

Controller filters are applied to all action methods within a specific controller. They allow you to apply behavior that is specific to a group of related actions.

Example:

// Custom controller filter implementing IActionFilter
public class AuthenticationFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        // Perform actions before the action method execution
        // Example: Authentication or authorization checks
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // Perform actions after the action method execution
    }
}

// Applying controller filter to a controller
[TypeFilter(typeof(AuthenticationFilter))]
public class MyController : Controller
{
    // Actions within this controller will be subject to the AuthenticationFilter
}

Action Filters

Action filters are applied to individual action methods, allowing you to customize the behavior of specific actions.

Example:

// Custom action filter implementing IActionFilter
public class LoggingFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        // Perform actions before the action method execution
        // Example: Logging or input validation
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // Perform actions after the action method execution
    }
}

// Applying an action filter to an action method
[ServiceFilter(typeof(LoggingFilter))]
public IActionResult MyAction()
{
    // Code for the action method
}

These examples demonstrate the usage of action filters at different scopes. Global filters provide common functionality for all actions, controller filters apply behavior to a specific group of actions within a controller, and action filters allow fine-grained control over individual action methods. By utilizing these action filter scopes, you can add the desired behavior and customization to your ASP.NET Core application.

By using these different scopes, you can apply action filters where they are most needed. Global filters provide overarching functionality across your entire application, controller filters offer behavior specific to a group of related actions, and action filters allow you to fine-tune the behavior of individual action methods.

Remember, each scope serves a unique purpose, and you can mix and match them based on your application's requirements. Whether you need broad protection, controller-specific enhancements, or action-level customization, action filter scopes in ASP.NET Core have got you covered!

Implementing your Own Action Filter

Even thou we reviewed all filter types that ASP NET Core supports we will focus on implementing an action filter to our web API that validates data. The action filter to implement will validate if the Post object is null as this is a repetitive snippet of code that needs to be added to various endpoints in the PostsController.

Clone the Repository Code on GitHub

Remember that if you want to follow along with the tutorial get the latest code changes up to this article from the Web API Repository at Github on the Patch branch.

GitHub - Osempu/BlogAPI at Patch

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Create a new Action Controller Class

Let’s begin by first creating a new action controller that will validate if the Post we want to Get, Delete, Edit, Patch actually exists and this way we will avoid duplicating that code in our controller actions.

public class PostExistsFilter : IAsyncActionFilter
{
    private readonly IPostRepository postRepository;

    public PostExistsFilter(IPostRepository postRepository)
    {
        this.postRepository = postRepository;
    }

    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        if (!context.ActionArguments.ContainsKey("id"))
        {
            context.Result = new BadRequestResult();
            return;
        }

        if (!(context.ActionArguments["id"] is int id))
        {
            context.Result = new BadRequestResult();
            return;
        }

        var post = await postRepository.GetPostAsync(id);

        if (post is null)
        {
            context.Result = new NotFoundObjectResult($"Post with id {id} does not exist.");
            return;
        }

        await next();
    }
}

You will create a new class called PostExistsFilter that implements the IAsyncActionFilter and this will be your ActionFilter, you have to use the async version as the IPostRepository uses the GetPostAsync function.

The IPostRepository interface will be injected using constructor injection.

Next, you will have to implement the interface method OnActionExutionAsync which provides the ActionExecutionContext and ActionExecutionDelegate as parameters.

Inside the method, the method will check if the action contains an id as an argument, and if not it will throw a new BadRequestResult then in the next if statement it will check the id to be an int and again if it’s not it will return a BadRequestResult.

After both if statements now that the method validated the id to exist as a parameter in the action and that the id is an int it will attempt to retrieve the post using the GetPostAsync(id) method. Last but not least if the post is null it will return a NotFoundObjectResult response with a custom error message and then call the ActionExecutionDelegate to continue with the action request.

Create an Attribute Class

If you use the PostExistsFilter as it is you would need to register it as a service in the Program class and use it above actions like this:

[ServiceFilter(typeof(PostExistsFilter))]
public async Task EditPost

This is not bad but we can achieve a much more clean and enhance the usability of filter attributes that depends on other classes.

So you will have to create a new attribute class called PostExistsAttribute that implements the TypeFilterAttribute base class and call the base constructor by referring to the PostExistsFilter so in much simpler words you will need to have something like the following:

public class PostExistsAttribute : TypeFilterAttribute
{
    public PostExistsAttribute() : base(typeof(PostExistsFilter))
    {
    }
}

Yeah, it is that simple. Just an attribute class that calls the base constructor passing our action filter.

This may seem odd but it’s pretty useful as you will no longer need to register your Filter in the service container in the Program class and the attribute will end up looking a lot cleaner when used on the corresponding action endpoints and you will look at that in a brief.

Applying your Action Filter in the PostsController

Now all that is left is to do is to apply the action filter to the endpoints that actually make use of the null checking for the Post entity.

[HttpGet("{id:int}")]
[PostExists]
public async Task GetPost(int id)

[HttpPut("{id:int}")]
[PostExists]
public async Task EditPost(int id, [FromBody] EditPostDTO editPostDto)

[HttpDelete("{id:int}")]
[PostExists]
public async Task DeletePost(int id)

[HttpPatch("{id:int}")]
[PostExists]
public async Task PatchPost(int id, [FromBody] JsonPatchDocument doc)

You should apply the action filter to these four endpoints and remove all code checking if the post is null. Also, you can note that the way you call the action filter is using the [PostExists] attribute instead of the old way of doing it which looked a lot harder to read.

Update to the GetPostAsync(id) method in the`PostRepository

To avoid concurrency problems you will need to update the GetPostAsync(id) method that retrieves a single post.

public async Task GetPostAsync(int id)
{
    var post = await context.Posts.AsNoTracking().SingleOrDefaultAsync(x => x.Id == id);
    return post;
}

This is to avoid tracking the retrieved post as the same post will be accessed to be updated, patched, or deleted and can have concurrency problems as they will all try to access the same entity at the same time.

Take your app for a test

Now you are ready to test your app and you will see no change if your endpoint supported the null check but if not you will notice that if the post you try to access is null then you will receive a NotFound HTTP response code.

Conclusion

Action filters are an important part of the ASP.NET Core framework, and they offer several benefits, including code reusability, separation of concerns, and customization. By using action filters, you can add additional functionality to your application and make it more maintainable.

Great Announcement

I’m back on YouTube so make sure you go and check out the new videos that I released these days and don’t forget to subscribe, like, and share with your friends that are also learning. Also, remember that you can follow me on Twitter as Oscar Montenegro and check out my Blog Unit Coding for more awesome content about designing and developing REST Services using ASP NET 7+ and amazing web applications with Blazor. Thanks for your constant support as I’m here because of all the amazing people that follow my work, for you guys cheers 🍻. See you all in the next article!

How to Use Patch Requests to Update Resources in Your REST API

Oscar Montenegro — Thu, 11 May 2023 04:23:34 GMT

If you're familiar with HTTP requests, you've probably heard of GET, POST, PUT, and DELETE. But have you heard of PATCH? In this article, we'll explain what a PATCH request is, why it's useful, and how you can use it, also I will show you the different type of operations that the patch method supports and how you can implement it on your own web API so without further ado let’s get into the action.

What is the Patch Request ?

The PATCH request is an HTTP method that is used to partially update an existing resource. With PATCH, you can modify specific attributes of a resource without having to send the entire resource back to the server.

For example, let's say you have a user profile that includes a name, email address, and phone number. If the user updates their phone number, you could use a PATCH request to send only the new phone number to the server, rather than sending the entire user profile this means a great improvement in flexibility at the time of updating large objects because you will no longer have to provide and update all the resource properties but only the ones that you want.

Why is Patch Request Useful ?

Patch request offers several benefits.

Firstly, it can be more efficient than other HTTP methods. If you only need to modify a small part of a resource, sending the entire resource to the server can be unnecessary and time-consuming. By using PATCH, you can reduce the amount of data that needs to be sent, which can improve performance.

Secondly, PATCH is useful when you need to make incremental changes to a resource. For example, if you want to update a user's email address and phone number separately, PATCH allows you to do this without overwriting any other attributes of the resource.

Finally, using PATCH can be beneficial for ensuring data consistency. If you use PUT to update a resource, you must send the entire resource to the server, even if only one attribute has changed. This can result in other attributes being overwritten accidentally. PATCH, on the other hand, allows you to modify only the attributes you want to change, reducing the risk of unintended consequences.

Different Patch Operations

There are six different patch operations:

Add

This operation adds a new value to a property.

{
	"op": "add",
	"path": "/title",
	"value": "new value"
}

Remove

Removes the value from a property or sets it to a default value.

{
	"op": "remove",
	"path": "/title"
}

Replace

Replaces a value to a new one. It is the equivalent of a remove operation followed by an add operation.

{
	"op": "replace",
	"path": "/title",
	"value": "new value"
}

Copy

Copies the value from one location to another(property) using two JSON pointers from and path.

{
	"op": "copy",
	"path": "/title",
	"from": "/author"
}

Move

Moves a value from one location to another(property) using two JSON pointers from and path.

{
	"op": "move",
	"path": "/title",
	"from": "/author"
}

Test

Tests if a property has an expected value. if the test fails, then the patch as a whole should not apply.

{
	"op": "test",
	"path": "/title",
	"value": "test value"
}

Example of a Patch Request Body

[
	{
        "op": "replace",
        "path": "/title",
        "value": "new title"
	},
	{
        "op": "add",
        "path": "/author",
        "value": "new author"
	}
]

In the code example above you can see that the request starts with a pair of square brackets that represents an array, in this case, is an array of operations, and every operation starts and is delimited by a pair of curly braces, meaning that you can execute a set of operations to an object and not just one.

Then every operation has an op property representing the type of operation you are executing, then the path property specifies on which property or field you will execute the operation, and finally, the value property specifies the value that will be used in the operation.

This is a pretty basic example because as you know you can use properties like from that are JSON pointers that gives you a lot of possibilities working with the patch method.

Clone the Repository from GitHub

Before starting to code I recommend you to go and get the code from the GitHub repository so you can follow along with this example. Make sure you get the code from the Sorting branch to have the latest version of the code up to this article.

GitHub - Osempu/BlogAPI at Sorting

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Install required Nuget Packages

In order to support the Patch requests we need to install two required libraries:

The Microsoft.AspNetCore.JsonPatch provides the JsonPatchDocument class type.

The Microsoft.AspNetCore.Mvc.NewtonsoftJson provides the NewtonSoftJson serializer into the application.

You can install these two Nuget Packages with the following dotnet cli command:

dotnet add package Microsoft.AspNetCore.JsonPatch
dotnet add package Microsoft.AspNetCore.Mvc.NewtonsoftJson

Register NewtonsoftJson in the Program file

In order to use the Newtonsoft library you have to add it as a service into the Program file after adding the controllers.

builder.Services.AddControllers()
                .AddNewtonsoftJson();

Now you are ready to implement the Patch method in the Post controller.

Implementing the Patch method

using Microsoft.AspNetCore.JsonPatch;
//code omitted for brevity

[HttpPatch("{id:int}")]
public async Task PatchPost(int id, [FromBody] JsonPatchDocument doc)
{
    var post = await repository.GetPostAsync(id);

    if(post is null)
    {
        return NotFound();
    }

    doc.ApplyTo(post);
    await repository.EditAsync(post);

    return NoContent();
}

First import the Microsoft.AspNetCore.JsonPatch namespace to support the Patch method and add the HttpPatch attribute to the PatchPost endpoint.

This Patch endpoint accepts the Post id and a JsonPatchDocument as the payload and it will get it from the body so add the [FromBody] attribute to this parameter.

You have to get the Post to update using the GetPostAsync(id) method from the repository class, then if the post is null return a NotFoun HttpResponseCode to notify that the resource does not exist.

Finally, use the ApplyTo() method to merge the changes into the request to the targeted resource. Then update the Post and return a NoContent HttpResponseCode.

For further information about the patch method visit https://jsonpatch.com/

Test the Patch method with Postman or swagger

Now you should be ready to test the new patch endpoint updating a single value from one of your posts. Below is an example of how to perform a replace operation to a post.

First, you need to input the id from the post you want to update and send the JSON payload in the format

Conclusion

HTTP PATCH is a useful method for updating resources partially and incrementally. By sending only the changes you want to make, you can reduce the amount of data sent, improve performance, and reduce the risk of unintended consequences. If you're working with APIs or web applications that allow partial updates, consider using PATCH to optimize your requests.

Follow me for more Web Development content

Keep posted if you want to grow your career as a Web Developer/Software Engineer as I’m constantly updating content on my Blog Unit Coding also follow me on Twitter as Oscar Montenegro where I’m starting to post my #100DayOfCode journey.

Thanks for reading my article and I will see you on the next one, Happy coding everybody!

Sorting Resources on your ASP NET Core Web API

Oscar Montenegro — Wed, 03 May 2023 16:07:55 GMT

Hello my fellow developers, here we are on a new part of this Web API Development series, we continue with exciting topics like the last post about Filtering Data in our API. Today we will be learning about sorting resources on our API, the effect it can have in our systems, and the benefits that provides for the client. I’ll teach you how you can sort your API resources and also will provide some useful code examples for you to follow along. So without further ado let’s get our hands on the code!

The Importance of Sorting Resources on API

Sorting resources on an API is crucial for several reasons. Firstly, it enhances the user experience by making it easy to find information. By sorting resources, users do not have to scroll through pages of irrelevant information to find what they are looking for. Instead, they can quickly find the information they need and move on to other tasks.

Secondly, sorting resources on an API improves the performance of the application. By reducing the amount of data that needs to be loaded, the application loads faster, leading to a better user experience.

Thirdly, sorting resources on an API makes it easier for developers to maintain the application. When resources are sorted, developers can easily locate specific data and make changes where necessary.

How to Sort Resources on API ?

Sorting resources on an API may seem complicated, but it is relatively simple. Here are the steps to follow:

Determine the field to sort by: The first step is to decide which field you want to sort by. For instance, if you are sorting products, you may choose to sort by price, product name, or product category.
Choose the sorting order: Once you have identified the field to sort by, you need to decide whether to sort in ascending or descending order. Ascending order means that the data is sorted from the smallest to the largest while descending order means that the data is sorted from the largest to the smallest.
Use the sorting parameter: Most APIs support a sorting parameter that allows users to sort resources. The sorting parameter is usually added to the end of the API URL and specifies the field to sort by and the sorting order. For instance, to sort products by price in ascending order, the URL may look like this: https://example.com/api/products?sort=price:asc.
Test the sorting functionality: Once you have implemented the sorting functionality, you need to test it to ensure that it works correctly. Testing involves trying out different sorting options and verifying that the data is sorted correctly.

Clone the repo from GitHub

If you want to follow along I recommend you clone the API repository from GitHub and make sure you get the code from the “Filtering” branch as it contains the latest code changes up to this article.

GitHub - Osempu/BlogAPI at Filtering

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Update the QueryPatameters class

Start by adding two new parameters to the QueryParameters class which holds all the parameters used to paginate, filter and now sort the API resources. Add an OrderBy parameter to specify the field to sort by and add another field named OrderAsc which states if the order is ascending if not it will be descending this will be true by default.

public class QueryParameters
{
    //Code Ommited for brevity

    //Sorting params
    public string OrderBy { get; set; } = string.Empty;
    public bool OrderAsc { get; set; } = true;
}

Add Sort logic to PostRepositoy Class

Now go into the PostRepository class and add the sorting logic. First, you will check if the OrderBy parameter is not null and if not then proceed to check if the OrderAsc is true to set the order flow or order direction to ascending or descending depending on the case. And lastly call the OrderBy method to perform the sorting operation. But you will get an error because the OrderBy does not accept string as an argument so you have to install a new package to be able to work with dynamic Linq queries.

public async Task> GetPostAsync(QueryParameters parameters)
{
    var allPosts = context.Posts.AsQueryable();

    //Filter by Author
    if(!string.IsNullOrEmpty(parameters.Author))
    {
        allPosts = allPosts.Where(x => x.Author == parameters.Author);
    }

    //Sort posts
    if(!string.IsNullOrEmpty(parameters.OrderBy))
    {
        string orderFlow = parameters.OrderAsc ? "ascending" : "descending";
        allPosts = allPosts.OrderBy($"{parameters.OrderBy} {orderFlow}");
    }

    //Paginated posts
    var pagedPosts = await allPosts
            .Skip((parameters.PageNumber - 1) * parameters.PageSize)
            .Take(parameters.PageSize)
            .ToListAsync();

    return pagedPosts;
}

Install the System.Linq.Dynamic.Core Nuget package

Proceed to install this Nuget package using the dotnet cli or the Nuget Package manager if you are using Visual Studio.

dotnet add package System.Linq.Dynamic.Core

This package will allow you to perform the sorting operation with the OrderBy method accepting a string as if it were a string query for example “orderby ascending”. Now the error should be gone and you can take the API for a test for example you can set the OrderBy parameter to Title and it will order the posts by Title alphabetically or you can go and sort them by CreatedDate and will sort the posts by the date they were created. Also, you can set the OrderAsc parameter to true or false to set the order flow.

Updating the PostResponseDTO class

Now you can sort by CreatedDate but if you tested the API you noted that when the posts were returned they don’t display this property so for that you have to update the PostResponseDTO to display the CreatedDate property so it makes sense when we sort by date. For that, you just have to add the CreatedDate property to the dto and that’s it, now you can see the date when the post was created when getting a single post or a list of posts.

public record PostResponseDTO(int Id, string Author, string Title, string Body, DateTime CreatedDate);

Take your API for a Test

Now you should be able to see the created date displayed and the sorting functionality must be working as expected. Think about what properties you can add tot he Post that you can sort by that can enhance your sorting logic or your API in general.

Conclusion

Sorting resources on an API is an essential aspect of application development. By sorting resources, users can quickly find the information they need, leading to a better user experience. Sorting resources also improves the performance of the application and makes it easier for developers to maintain it. By following the steps outlined in this article, you can easily sort resources on your API in a user-friendly manner.

Thanks for reading!

As always thanks a lot for reading my articles and for following me on my personal Blog, on Twitter, and on my YouTube channel. I don’t think that we can have a Friday API this week but I will work on something great for the next week so keep posted on that. Thanks and keep coding, see you on my next article!

Filtering In Your ASP NET Core Web API: The Key to Efficient Data Retrieval

Oscar Montenegro — Fri, 28 Apr 2023 15:02:25 GMT

Hello guys, I’m so glad to be here one more day to bring you some more valuable knowledge. Today we will not have API Friday 🥲, I know it’s sad but something it takes me more time than expected to build the projects and to play around with the new API every week at the same time that I’m creating content for the blog and some other daily life stuff. However today we will continue with our web API development series as we are getting our hands on some fun stuff, on the last article we were talking about pagination and its benefits for our application and the user experience, and today we will continue with a pretty similar topic as it is related. We will be talking about Filtering, why should you apply filtering, and as always a code example to continue to improve our Blog API so without further ado let’s get into today’s article.

On a Data-Driven World

As the world becomes increasingly connected and data-driven, web APIs have become a critical component of modern applications. APIs, or Application Programming Interfaces, allow developers to interact with the data and functionality of other software systems, enabling them to build more powerful, integrated applications.

One important feature of many web APIs is filtering. Filtering refers to the process of selecting a subset of data from a larger dataset based on specific criteria. In the context of a web API, filtering allows developers to retrieve only the data they need, rather than having to retrieve and process large amounts of irrelevant data.

What is filtering ?

Filtering is a process used to extract a subset of data from a larger dataset based on specific criteria. For example, if you were looking at a dataset of customer orders, you might want to filter the data to only show orders that were placed in the last month or orders that contained a specific product.

In a web API, filtering is typically accomplished by passing parameters to an API endpoint that specifies the criteria for selecting data. For example, you might use a parameter like ?filter=last_month to retrieve only the data that meets the specified criteria.

Filtering can be applied to various types of data, including text, numbers, dates, and more. The specific criteria used for filtering depends on the nature of the data and the requirements of the application.

Why is filtering important ?

Filtering is an important feature in web APIs for several reasons:

Reduced data transfer

One of the primary benefits of filtering is reduced data transfer. When working with large datasets, retrieving all the data can be a slow and resource-intensive process. By filtering the data to only retrieve the necessary subset, developers can significantly reduce the amount of data that needs to be transferred and processed.

For example, if you're building an e-commerce application that needs to retrieve a list of products for sale, you might use filtering to retrieve only the products that are currently in stock. This would reduce the amount of data that needs to be transferred, making the application faster and more efficient.

Improved performance

Filtering can also improve the performance of web APIs by reducing the amount of data that needs to be processed. When retrieving data from a database or other data source, filtering can allow the API to query only the relevant subset of data, rather than retrieving and processing the entire dataset.

For example, if you're building a social media application that needs to retrieve a list of posts from a user's friends, you might use filtering to only retrieve posts that were created in the last week. This would reduce the amount of data that needs to be processed, making the API faster and more responsive.

Increased flexibility

Filtering also provides increased flexibility for developers. By allowing developers to select only the data they need, APIs can be more easily integrated with other applications and systems.

For example, if you're building a weather application that needs to retrieve temperature data from a weather API, you might use filtering to retrieve only the data for a specific geographic location. This would allow you to integrate weather data with other parts of your application, such as a map or a location-based search feature.

Improved data quality

Finally, filtering can improve the quality of data returned by web APIs. By selecting only the relevant subset of data, developers can avoid including irrelevant or inaccurate data in their applications.

For example, if you're building a financial application that needs to retrieve stock prices from an API, you might use filtering to retrieve only the prices for a specific stock symbol. This would ensure that the data returned by the API is accurate and relevant to the application.

Clone the GitHub repo

As always if you want to follow along with the article clone the Blog API repository so you can have a hands-on experience applying filtering. Make sure you get the code from the Pagination branch as this contains the latest code up to this point.

GitHub - Osempu/BlogAPI at Pagination

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Update the QueryParameters Class

In the last article, we created a class called QueryParameters that holds the pagination parameters such as PageSize and PageNumber, and now we will add a filtering parameter to be able to filter by an author so the class will end looking like this.

public class QueryParameters
{
    const int maxPageSize = 50;
    public int PageNumber { get; set; } = 1;
    private int pageSize = 10;
    public int PageSize
    {
        get { return pageSize; }
        set { pageSize = (value > maxPageSize) ? maxPageSize : value; }
    }

    //Filtering params
    public string Author { get; set; } = string.Empty;
}

Everything is the same we just added the Author property at the end of the file and initialized it to an empty string.

Update your IPostRepository and PostRepository classes

Once again we see ourselves in the need to update our IPostRepository and PostRepository classes to pass them the QueryParameters as a parameter instead of the raw params. This is to improve the way we add more and more parameters avoiding having a method with a lot of parameters being passed.

public interface IPostRepository 
{
    Task> GetPostAsync(QueryParameters parameters);
}

public async Task> GetPostAsync(QueryParameters parameters)
{
}

Now with this change in place, you can keep adding more and more params to the QueryParameters class without having to mess with the signature of any of both the interface and the class.

Applying filtering in the repository class

As with Pagination you want to apply the filtering in the repository class when you are querying the database for all our resources. Filtering should be applied before pagination because you want to filter against all the database resources, not after the data set is paginated.

public async Task> GetPostAsync(QueryParameters parameters)
{
    var allPosts = context.Posts.AsQueryable();

    //Filter by Author
    if(!string.IsNullOrEmpty(parameters.Author))
    {
        allPosts = allPosts.Where(x => x.Author == parameters.Author);
    }

    var pagedPosts = await allPosts
            .Skip((parameters.PageNumber - 1) * parameters.PageSize)
            .Take(parameters.PageSize)
            .ToListAsync();

    return pagedPosts;
}

Filtering is added above pagination but before you need to check if the Author parameter is empty or null, as if it’s empty it means the client is not asking for filtering, if not then you will retrieve only the posts where the author is the specified one. No call to the ToListAsync method is made on the query as you still need to paginate before actually executing the query to the database.

Test your API filtering by Author

Now take your web API to test the new filtering functionality, you should add some posts with the same author if you don’t have any to actually see the filtering in action. Now this easy is how you add filtering to your web API, there are actually other ways to implement filtering, I showed you a pretty simple and straightforward to do it but if you look into the internet you will find some more crazy and improved ways to do it.

Conclusion

Filtering is an essential and useful feature of Web APIS that allows developers to get subsets of data from a larger dataset based on some specific criteria. By implementing filtering in their web APIs. developers can reduce data transfer from the server to the client and we already know that this is always something that we want as this saves time, improves performance, consume fewer resources, and improves the user experience as he can demand to see only relevant data to him. But as with everything it is not a silver bullet and you should always consider if filtering is something that will actually improve your application and that it makes sense to have it or if it will just add more complexity and make no change.

As always thanks for reading my articles and I hope you are getting a lot from reading them for your daily coding and work. Now you can follow me on Twitter as Oscar Montenegro I’m still new to Twitter so I don’t have that many posts but I will be posting some content there so you know what I’m up to in my daily life as a developer.

Thanks for everything and I hope you have an amazing weekend, enjoy it, take some time to rest and be with your loved ones, and as always, keep coding!

Improve Your Web API Performance With Pagination

Oscar Montenegro — Thu, 27 Apr 2023 00:02:41 GMT

Hello guys, today continuing with the ASP NET Core web API series we will review an exciting topic and that is pagination I think that non of us are oblivious to pagination as in almost any website there is an implementation of this functionality say for example on Google Search when you search for anything you get some results back and if you hit the bottom then you have a control where you select the next page to get more results in the case that you did not found what you were looking for and that is exactly what we want to implement in our web API today.

What is pagination ?

Pagination is a technique used in web APIs to break up a large set of data into smaller, more manageable pieces. This is achieved by limiting the number of results that we send back on each API response and providing a way for the client to request the next set of results.

In a typical implementation of pagination, the client sends a request to the server providing a certain number of results to be returned to per page and also the current page number.

Why should we use pagination in our web API ?

Pagination is commonly used in web APIs to improve performance and reduce the amount of data that must be transferred between the server and the client, especially when dealing with large datasets. Also improves user experience as small data chunks are more digestible than large datasets and help to prevent bad user experience on slow internet connections as it will not load the entire dataset only what is requested.

Clone the GitHub repo

Before starting to code remember that you can follow along with the tutorial, you just need to go to the GitHub repo and clone the AsynchronousEndpoints branch to get the latest changes up to this point.

GitHub - Osempu/BlogAPI at AsynchronousEndpoints

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Adding query parameters support to the Get endpoint

Currently, we call the Get endpoint and we get all the existing posts from the database so this is a great example of where we should implement pagination as the more our database grows the least likely we would like to return a large dataset.

The way the client will request the number of results and the page number is through query strings and ASP NET Core have a pretty simple way to deal with them using the [FromQuery] attribute int endpoint. This way we tell ASP NET Core to check the query string and then it will attempt to read the values from the query string and parse it into the parameter we specified.

[HttpGet]
public async Task GetPost([FromQuery] int pageSize = 50, [FromQuery] int currentPage = 1)
{
    var posts = await repository.GetPostAsync(pageSize, currentPage);

    //code ommited for brevity
}

We passed the pageSize and the currentPage parameters both decorated with the

[FromQuery] attribute so ASP NET Core attempts to read its values from the query string as we said before and both parameters have default values in case the user does not provide any and then we pass these parameters to the GetPostAsync method. Now you should be getting and error as this method does not accept any parameter and for that, we need to update the IPostRepository interface and PostRepository class.

Updating the IPostRepository interface and PostRepositoryClass

Now we need to update our interface and repo class respectively to support the pagination parameters

For the IPostRepository interface, we only need to define two parameters pageSize and pageNumber.

public interface IPostRepository 
{
    Task> GetPostAsync(int pageSize, int pageNumbe);
		//Code omitted for brevity
}

And for the post repository, we will implement the interface signature supporting the same parameters. Now all that is left is to actually implement the pagination functionality.

public async Task> GetPostAsync(int pageSize, int pageNumber)
{
		//Code omitted for brevity
}

Implementing pagination in PostRepository class

public async Task> GetPostAsync(int pageSize, int pageNumber)
{
    var allPosts = context.Posts.AsQueryable();

    var pagedPosts = await allPosts
                            .Skip((pageNumber - 1) * pageSize)
                            .Take(pageSize)
                            .ToListAsync();

    return pagedPosts;
}

You may get tempted to do this in the Post controller after getting all the posts but the idea behind pagination is to limit the number of resources the database return and this needs to be done in the repository class because that’s where we are calling the database.

First, we make a call to all the posts but as a queryable type, this means that we are asking for all the posts existing in the database but the LINQ query has not been executed yet, this helps us to save resources as we are still building the query, then we make another query to all the posts. We call the skip method to skip the previous pages in case the client is asking to see for example page 3 or 8, then we take a specific amount of posts to show to the user, this is specified by the pageSize parameter and finally, we call the ToListAsync() method to execute the query and return a list of posts.

Now you can run the app and start testing the pagination, if you are using Swagger then you will see two new parameters which are the query params that you can enter for pageSize and pageNumber, and when you execute the call the request URL should look similar to this

http://localhost:5049/api/post?pageSize=10¤tPage=1

so you should be getting 10 posts from the first page.

The problem with this approach

You must be thinking that this is all and we can move on right? well, spoiler alert, we can’t. The thing is that this solution does not scale well as we need to provide some default values for the query parameters in the case that the user does not provide them, although we can do that on the parameters imagine later we want to filter in our search that’s another parameter to pass, no think about sorting, we would end up with our endpoint having a lot of parameters to set and we know that’s not something good neither scalable that’s why we need to refactor our solution to make it more scalable for future changes.

Let’s create a new model class called QueryParameters, this class will hold all the parameters we need for pagination and for future changes in our API.

public class QueryParameters
{
  const int maxPageSize = 50;
  public int PageNumber { get; set; } = 1;
  private int pageSize = 10;
  public int PageSize
  {
      get { return pageSize; }
      set { pageSize = (value > maxPageSize) ? maxPageSize : value; }
  }
}

Now with the aid of this class, we will hold all the parameters we need for the pagination and future functionality to work. We are defining the max size the page can have, we set the page to a default value of 1 in the case the user does not provide the page to display and lastly we set the page size to a default value of 10 or whatever the user defines.

Implementing the new approach

[HttpGet]
public async Task GetPost([FromQuery] QueryParameters parameters)
{
    var posts = await repository.GetPostAsync(parameters.PageSize, parameters.PageNumber);

    var postsDto = mapper.Map>(posts);

    logger.LogDebug($"Get method called, got {postsDto.Count()} results");
    return Ok(postsDto);
}

If you run the app it will be running as before but now we have an improved version for when we add filtering and other parameters to enhance our endpoint.

Conclusion

Pagination is a powerful technique used to improve the user experience while saving server resources as we do not return all the data available, avoiding bottlenecks and performance problems over slow connections. As with all programming techniques, paging must be used wisely as in not every project it will make sense to apply it, for example, in an analytics service, in that context it makes sense to return hundreds if not thousands of records as the more data you have at hand the more reliable and precise this service becomes.

Build a Google Translate Clone with Blazor and .NET

Oscar Montenegro — Fri, 21 Apr 2023 16:32:52 GMT

Hello guys, it’s Friday and you know what it means right? Yeah, it’s API Friday so I guess I should have started saying H-API Friday to you all (ba dum tss). I’m really excited about the project that I got between hands for you. I did my best to present you something with almost full functionality something you can showcase in your developer portfolio if you are a beginner, and don’t worry I will start to create some projects for intermediate and advanced developers just have a little patience as I’m focusing right now on new .NET developers.

Today’s project is a clone of the google translate app using Google’s translate API v2. I’m a visual person so today I will present you with a nice-looking application, however, it will not only be a “pretty “ app it will also translate text, detect a language based on the user input, display the supported languages, and swap user input with translation result. So if you are as excited as I am to start coding let’s go for it!

Google Translate API Setup

First, you need to follow some steps in order to be able to use the Google Translate API.

Create a Google account or use your existing account if any
Access google cloud
Go to the google cloud console
Create a new project and name it whatever you want mine was named Google Translate Clone
Access your and look for Cloud Translation API
Enable the API and it will ask you to enable billing in your account
Enable billing as well (don’t worry we will not spend a penny on this project)
In your project view go to APIs and services > Credentials
Select Create Credentials and then select API Key

After you have followed these steps you can start using your API key for this and many other projects.

If for some reason you failed to follow the steps and need further help you can watch this video where he follows the same steps I listed above but you can see the Google Cloud interface and appreciate it more visually.

Alternative to accessing Google Cloud

if you don’t like the idea of accessing Google Cloud and enabling a billing account you can access Rapid API which is an API marketplace where you can find tons of APIs to use, you would need to create an account and then look for the Google Translate API and subscribe for free after this you will have access to the credentials Rapid API provides you without you having to access Google Cloud or enable a billing account but you would need to send two special headers on every request but don’t worry Rapid API got you covered and actually provides you with an example call so you know how to call the API from their host and it will look something like this

var client = new HttpClient();
var request = new HttpRequestMessage
{
	Method = HttpMethod.Post,
	RequestUri = new Uri(""),
	Headers =
	{
		{ "X-RapidAPI-Key", "YOUR_API_KEY" },
		{ "X-RapidAPI-Host", "google-translate1.p.rapidapi.com" },
	},
	Content = new FormUrlEncodedContent(new Dictionary
	{
		{ "q", "English is hard, but detectably so" },
	}),
};
using (var response = await client.SendAsync(request))
{
	response.EnsureSuccessStatusCode();
	var body = await response.Content.ReadAsStringAsync();
	Console.WriteLine(body);
}

Create a new Blazor WebAssembly App

Now that you have access to the Google Translate API let’s start creating a new blazor wasm app with the aid of the dotnet cli.

dotnet new blazorwasm-empty -o GoogleTranslateClone

As always go to your wwwroot>Index.html file and uncomment your scoped CSS stylesheet as by default this line is always commented and you have to enable it by yourself.

Add the Models to store the data

We need some models to store the data that we are getting back from the web API calls so let’s add a folder called Models and let’s create the following model classes.

public class Language
{
    [JsonPropertyName("language")]
    public string language { get; set; }

    [JsonPropertyName("name")]
    public string name { get; set; }
}

public class TranslatedText
{
    [JsonPropertyName("translatedText")]
    public string translatedText { get; set; }
}

We added a Language model to store the collection of supported languages from the API and the TranslatedText class to store the response from the translation endpoint. We are using the JsonpropertyName to map the JSON response to our model properties on deserialization.

Create GoogleTranslateClient class

As we are calling a web API we need a client class that consumes its endpoints so for that reason let’s add a new folder called Client and inside it we will create the GoogleTranslateClient class.

public class GoogleTranslateClient
{
    private const string baseAddress = "";
    
		private readonly HttpClient client;

    public GoogleTranslateClient(HttpClient client)
    {
        this.client = client;
    }
}

We start by adding a constant that will hold the base address of the client which is the Google API address. After this, we add a constructor and pass an HttpClient as a parameter to instantiate the client via dependency injection in the Program class.

Now this is not everything but I don’t want to throw a bunch of lines of code in front of you and expect you to understand it all like that. So I will explain every method of the client separately.

GetSupportedLanguages methods

With this method as the name suggests we intend to get a collection of the languages the Google API supports.

public async Task> GetSupportedLanguages()
{
    var queryParams = new Dictionary()
    {
        ["key"] = "YOUR_API_KEY",
        ["target"] = "en"
    };

    var uri = QueryHelpers.AddQueryString($"{baseAddress}/languages", queryParams);

    var response = await client.GetAsync(uri);
    string content = await response.Content.ReadAsStringAsync();

    var data = JsonObject.Parse(content);
    var languagesNode = data["data"]["languages"];
    var languages = JsonSerializer.Deserialize>(languagesNode)
                        .ToDictionary(x => x.language);
    return languages;
}

Nothing super special or out of the world we start by creating a string dictionary to store the API key and the target language. We use the QueryHelpers class to add the query string seamlessly just passing the address and the query params as parameters but in order to use the QueryHelpers class you need to install a Microsoft library so prepare your terminal to use the dotnet cli.

dotnet add package Microsoft.AspNetCore.WebUtilities

Now you should be able to use it without getting any errors. Then we send the request and parse it to a string as always. Now here comes the hacky stuff, in order to avoid creating a bunch of models to get the languages data I work directly with the JSON nodes and dive into its properties to get the languages to finally just deserialize into a list and call the ToDictionary method to return a Dictionary.

DetectLanguage method

Have you ever found a piece of text that you would like to translate but don’t know in which language is it written? well, what this method does is detect the language based on the input the user gives.

public async Task DetectLanguage(string input)
{
    var queryParams = new Dictionary()
    {
        ["key"] = "YOUR_API_KEY",
        ["q"] = input
    };

    var uri = QueryHelpers.AddQueryString($"{baseAddress}/detect", queryParams);

    var response = await client.PostAsync(uri, null);
    var content = await response.Content.ReadAsStringAsync();

    JsonNode data = JsonNode.Parse(content);
    JsonNode languageNode = data["data"]["detections"][0][0];
    Language language = JsonSerializer.Deserialize(languageNode);

    return language;
}

We start creating the same string dictionary to store the API key and in this case, we pass the parameter q which is the user input to analyze and detect the source language. Everything is the same, we call the QueryHelpers class to pass the query strings, send the post request and read the response as a string to parse into a JsonNode to manipulate the node data manually and deserialize into a Language object and proceed to return it.

Translate method

Finally, the method to translate the input from the client to the desired language.

public async Task Translate(string input, string source, string target)
{
    var queryParams = new Dictionary()
    {
        ["key"] = "YOUR_API_KEY",
        ["q"] = input,
        ["target"] = target,
        ["source"] = source
    };

    var uri = QueryHelpers.AddQueryString(baseAddress, queryParams);

    var response = await client.PostAsync(uri, null);
    var content = await response.Content.ReadAsStringAsync();

    JsonNode data = JsonNode.Parse(content);
    JsonNode translateNode = data["data"]["translations"][0];
    TranslatedText translation = JsonSerializer.Deserialize(translateNode);

    return translation;
}

This method takes three parameters, the input which is the sentence to translate, the language in which the sentence is written, and the target language to translate.

We pass these three parameters as query strings in the queryParams dictionary and use the QueryHelpers class to pass the query params to the request. We perform the post request and parse the response to a string to finally parse into a JSON node to get into its properties and get the translated text.

This is it for the GoogleTranslateClient so let’s add it to the services collection in the Program class.

builder.Services.AddScoped();

Add markup to Index.razor file

This is our main file so we will add all the markup here, we will not be creating any components although we could have as we will have some repeated markup for this example we did it all inside a single file without components but you can definitely do it and improve the app in many ways.


    Blazor Translate
    
        
            
                
            

            

            
                
            
        

        
            
            
        
    
    
        @if (!string.IsNullOrEmpty(notificationText))
        {
            @notificationText
        }

We define some basic HTML markup but there are some parts that I would like to point out and that is that we are populating the select controls using the supported languages method using a foreach loop to create an option tag for every supported language.

Also, we added a button to change the source text with the target text, this is to swap the content to translate with the translated content.

There are two textarea controls to input the text to translate and to display the translation, below this, we have a notification to display some messages for example to input a valid text if the textarea is empty or to notify the user when a text is translated from a language and finally a button to execute the translation.

Add the code to the Index.razor file

@code {
    private string sourceLanguage;
    private string targetLanguage = "en";
    private string sourceText;
    private string translatedText;
    private string notificationText;

    private Dictionary supportedLanguages = new Dictionary();

    protected override async Task OnInitializedAsync()
    {
        supportedLanguages = await GetSupportedLanguages();
    }

    private async Task> GetSupportedLanguages()
    => await client.GetSupportedLanguages();

    private async Task DetectLanguage(string input)
    => await client.DetectLanguage(input);

    private async Task Translate()
    {
        notificationText = string.Empty;
        if(string.IsNullOrEmpty(sourceText))
        {
            notificationText = "Insert a valid text to translate";
        }
        else if (string.IsNullOrEmpty(sourceLanguage))
        {
            Language detectedLanguage = await DetectLanguage(sourceText);
            var translationResult = await client.Translate(sourceText, detectedLanguage.language, targetLanguage);
            translatedText = translationResult.translatedText;
            if (supportedLanguages.TryGetValue(detectedLanguage.language, out Language language))
            {
                notificationText = $"Detected from {language.name}";
            }
        }
        else
        {
            var translationResult = await client.Translate(sourceText, sourceLanguage, targetLanguage);
            string decodedString = HttpUtility.HtmlDecode(translationResult.translatedText);
            translatedText = decodedString;
        }
    }

    private void ChangeSourceToTarget()
    {
        string tempSource = "";
        string temptext = "";

        tempSource = sourceLanguage;
        temptext = sourceText;

        if (string.IsNullOrEmpty(tempSource))
        {
            tempSource = "en";
        }

        sourceLanguage = targetLanguage;
        sourceText = translatedText;

        targetLanguage = tempSource;
        translatedText = temptext;
    }
}

At the top, we define some fields to store the values of the select controls and text areas and we initialize a SupportedLanguages property and populate it in the life cycle method OnInitializedAsync with the aid of the GetSupportedLanguages method which as we remember returns a dictionary containing the supported languages.

The detect language method does a call to the client detect language method and returns the language code. Now the translate method is where almost all the magic happens, we set the notificationText field to empty as we want to clear any old messages then we check if the sourceText property is not empty (which is the text to translate), if it is then we display an error message then we proceed to check if the sourceLanguage is not empty (this is the language of the text we want to translate), but if it’s empty then this means we want to detect the language so we call the detect language function and return the language in which it is written, then we proceed to translate the text now that we know the source language, decode the response as the response contains some HTML codes and finally, we check in the supported languages dictionary to look for the name of the detected language as the detect language function return the language code (eg. en, es, de, fr) but not the actual name, so once we know the language we print a notification displaying the language from which the text was translated. Following with the last case of the conditional statement if both the sourceLanguage and sourceText are not empty then we proceed to perform a normal translation without any additional tasks.

The final method is actually a utility method to swap the left side of the translate app with the right side so for that we define some temporary variables and start swapping values, we have a conditional statement checking if the select control from the left side was empty then we will change its value to “en” this is because we cannot send an empty value to the targetLanguage as this would cause an error because we need to know the target language always, then we continue with the swap and that’s it.

Adding styling to the app

The app is ready to work and rock but it still looks ugly so we will start adding some styling. Let’s begin by adding a style link in the index.html file to use font awesome to add some icons.

Add styling to the body element in app.css

Let’s go to our global CSS stylesheet and add a bit of styling.

body {
    display: flex;
    align-items: center;
    justify-content: center;
    min-height: 100vh;
    background: #3A4454;
}

Style the Index.razor

Now let’s add the main styling to our razor page for this, you need to create a new CSS file named Index.razor.css so once you did this you can add your scoped styling.

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
}

.container {
    width: 100%;
    background: #fff;
    border-radius: 10px;
    padding: 30px;
    text-align: center;
}

.wrapper {
    border-radius: 5px;
    border: 1px solid #bbb;
}

.wrapper .text-input {
    display: flex;
}

.text-input .to-text {
    border-left: 1px solid #bbb;
    border-radius: 0px;
    background-color: #f7f7f7;
}

.text-input textarea {
    height: 250px;
    width: 100%;
    border: none;
    outline: none;
    resize: none;
    font-size: 30px;
    border-radius: 5px;
    background: none;
    padding: 10px 15px;
}

textarea::placeholder {
    font-size: 30px;
    color: #878787;
    font-weight: 400;
}

.controls , li{
    display: flex;
    align-items: center;
    justify-content: space-between;
}

.controls, li, .icons , .icons i{
    display: flex;
    align-items: center;
    justify-content: space-around;
}

.controls {
    list-style: none;
    padding: 12px 15px;
    border-bottom: 1px solid #bbb;
}

.controls .row select {
    border: none;
    outline: none;
    font-size: 18px;
    background: none;
}

select {
    cursor: pointer;
}

.controls .exchange {
    color: #9f9f9f;
    font-size: 16px;
    cursor:pointer;
}

.exchange {
    border-radius: 50%;
    border: 1px solid #ddd;
    padding: 15px;
}

.detected-text {
    text-align: start;
    margin-left: 10px;
}

.container button {
    width: 100%;
    padding: 14px;
    margin-top: 20px;
    border: none;
    outline: none;
    cursor: pointer;
    border-radius: 5px;
    font-size: 17px;
    background-color: #007bff;
    color: #fff;
}

Ready to test your app

This is it now you should have a fully working clone of Google Translate. As I told you at the beginning you can detect languages, get a collection of the languages supported by the API and translate sentences from one language to another, the app is not perfect and can have some improvements but I had tons of fun building it and I hope you did as well.

Check out the repo on GitHub

If you had any trouble or I had a typo you can check out the repository on GitHub.

GitHub - Osempu/GoogleTranslateClone

Contribute to Osempu/GoogleTranslateClone development by creating an account on GitHub.

GitHubOsempu

Check out the live version

There is also a live version of this app hosted for free as an Azure Static Web App you can check it out here

Thanks for your reading and for your support!

As always thanks for reading my post and for your kind words and support with your thumbs up. I had a great time coding this app and hope you enjoy it and it helped you to learn more about blazor and C#, when I was learning these were the kind of tutorials that I wish I had found that are fun to code and have a bunch of code to learn from. Keep posted as I will continue posting projects like these using ASP NET Core technologies (Blazor, MVC, razor pages, etc) that will be really cool as we progress and they will begin to get harder and harder as we go.

Remember to follow me on my blog Unit Coding and on my youtube channel under the same name Unit Coding as I post content every week.

Thanks for everything guys I hope you have a great weekend and keep coding!

The Power of Asynchronous Code in your web API

Oscar Montenegro — Wed, 19 Apr 2023 23:59:43 GMT

Hello my fellow developers, on the last article I showed you how to add data validation using the fluent validation Nuget package. We discussed the relevance of implementing data validation for our API and for many other kinds of projects and also we saw how easy it was to implement yet the benefits are huge.

Data validation with Fluent Validation for ASP NET Core

Hello guys, welcome to another chapter of this series on API Development with ASP NET Core. In the last article, we talk about data mapping using auto mapper and I showed you how to implement data mapping from installing auto mapper to creating the mapping profiles and injecting auto mapper

Unit CodingOscar Montenegro

Today I will teach you how you can implement asynchronous code for your web API, you will see how easy it is and how you will leverage the power of asynchronous code for your app. But before we can start coding we need to understand what is asynchronous programming and what uses it have. So without further ado let’s get into today’s article.

What is asynchronous programming?

Software development has two primary paradigms when it comes to handling tasks: synchronous and asynchronous programming. Synchronous programming executes tasks one after the other, in a predetermined order. On the other hand, asynchronous programming enables the execution of multiple tasks simultaneously, without waiting for the previous task to finish. This article will dive deeper into asynchronous programming, its importance, and its various uses.

Why is Asynchronous Programming Important?

Asynchronous programming is essential for improving the performance and responsiveness of software applications. It is particularly useful for applications that require heavy data processing or network communication. By allowing multiple tasks to execute simultaneously, applications can run more efficiently and effectively. It is beneficial because it eliminates the need to wait for each task to complete before moving on to the next one.

Another advantage of asynchronous programming is its ability to handle long-running tasks without blocking the application's main thread. When a task takes a long time to complete, synchronous programming can cause the application to become unresponsive or even crash. Asynchronous programming enables applications to keep functioning normally while long-running tasks are processed in the background, thereby improving the overall user experience.

What Uses Does Asynchronous Programming Have?

Asynchronous programming has a wide range of uses in software development. One of its primary uses is in web development, where it handles requests and responses from servers. By using asynchronous programming, web applications can process multiple requests simultaneously, improving the overall performance and user experience.

Mobile app development is another area where asynchronous programming is commonly used. It handles tasks such as data synchronization, database access, and network communication. As a result, mobile apps can continue to function smoothly and responsively even when performing complex tasks in the background.

Asynchronous programming is also useful in gaming, artificial intelligence, and machine learning. These applications require the processing of multiple tasks simultaneously, which can be achieved through asynchronous programming. It helps to improve the performance and efficiency of these applications, leading to better overall results.

Clone the repo on GitHub

Before starting if you want to follow along with this tutorial you can clone the GitHub repository and make sure you get the code from the FluentValidation branch which contains the latest code changes up to this point.

GitHub - Osempu/BlogAPI at FluentValidation

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Update the IPostRepository interface

We need to update the post repository class to access the database asynchronously but before we can do that we actually need to update the IPostRepository interface as it defines the contract the repository class needs to comply.

public interface IPostRepository 
{
    Task> GetPostAsync();
    Task GetPostAsync(int id);
    Task AddAsync(Post post);
    Task EditAsync(Post post);
    Task DeleteAsync(int id);
}

We need to return a Task so for the Get methods we will wrap the return type inside a task and for the Add, Edit, and Delete we will simply return a Task as we cannot return void on an async method and also we will update the name of every function as they will now work asynchronously we will append the Async word.

Update PostRepository class

Now we should be getting an error because we changes the return type for every method defined in the IPostRepository interface so we need to update our PostRepository as well to make sure we comply with what our interface states.

public class PostRepository : IPostRepository
{
    private readonly BlogDbContext context;
    public PostRepository(BlogDbContext context)
    {
        this.context = context;
    }

    public async Task AddAsync(Post post)
    {
        context.Add(post);
        await context.SaveChangesAsync();
    }

    public async Task DeleteAsync(int id)
    {
        var post = context.Posts.Find(id);
        context.Remove(post);
        await context.SaveChangesAsync();
    }

    public async Task EditAsync(Post post)
    {
        context.Entry(post).State = EntityState.Modified;
        await context.SaveChangesAsync();
    }

    public async Task> GetPostAsync()
    {
        var allPosts = await context.Posts.ToListAsync();
        return allPosts;
    }

    public async Task GetPostAsync(int id)
    {
        var post = await context.Posts.FindAsync(id);
        return post;
    }
}

Let’s begin by changing the names of all the methods and append the Async word as they will now be working asynchronously, then add the async keyword and change the return type for every method to fully comply with the method signature defined by our interface.

Now the last step is to call SaveChangesAsync method in our Add, Edit, and Delete methods. For the Get method that retrieves all the posts we need to change the ToList() to ToListAsync and that would be enough, we need to do the same for the Get method that retrieves a single post but instead of using ToListAsync we will replace the Find method for its async version FindAsync and there you go now the repository class is calling the database asynchronously.

Making the Post Controller Async

Now all that is left is to update our controller endpoints to make them work asynchronously.

**[HttpGet]
public async Task GetPost()
{
    var posts = await repository.GetPostAsync();
    var postsDto = mapper.Map>(posts);
    logger.LogDebug($"Get method called, got {postsDto.Count()} results");
    return Ok(postsDto);
}

[HttpGet("{id:int}")]
public async Task GetPost(int id)
{
    try
    {
        var post = await repository.GetPostAsync(id);
        var postDto = mapper.Map(post);

        return Ok(postDto);
    }
    catch (Exception ex)
    {
        logger.LogError(ex, $"Error getting post with id {id}");
        throw;
    }
}

[HttpPost]
public async Task CreatePost(AddPostDTO addPostDTO)
{
    try
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }

        var newPost = mapper.Map(addPostDTO);
        newPost.CreatedDate = DateTime.Now;
        await repository.AddAsync(newPost);
        return CreatedAtAction(nameof(GetPost), new { id = newPost.Id }, null);
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "Unexpected error on Post method");
        throw;
    }
}

[HttpPut]
public async Task EditPost([FromBody] EditPostDTO editPostDto)
{
    try
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }
        var post = mapper.Map(editPostDto);

        post.LastUpdated = DateTime.Now;
        await repository.EditAsync(post);
        return NoContent();
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "Unexpected error on Put(Edit) Method");
        throw;
    }
}

[HttpDelete("{id:int}")]
public async Task DeletePost(int id)
{
    try
    {
        await repository.DeleteAsync(id);

        return NoContent();
    }
    catch (Exception ex)
    {
        logger.LogError(ex, $"Unexpected error on Delete method trying to delete post with Id {id}");
        throw;
    }
}**

Here what we did is that in every endpoint we added the async keyword and set the return type to Task. Also, we now call the async version of the repository methods AddAsync, EditAsync, DeleteAsync, and GetAsync.

Test the API

Now you can proceed to test the API, you will notice no change as it will run as before but now behind the scenes, it can take requests asynchronously and also the interaction with the database is asynchronous.

Conclusion

Asynchronous programming is an essential paradigm in software development, providing a wide range of uses and benefits. It enables the execution of multiple tasks simultaneously, leading to more efficient and effective software applications. It also enables long-running tasks to be processed without blocking the main thread, improving the overall user experience. As such, it is a critical tool for developers looking to create high-performance software applications. By embracing asynchronous programming, developers can create faster, more efficient, and more responsive applications, leading to better overall user experiences.

As always thanks for reading and considering supporting me on my blog Unit Coding and on my youtube channel under the same name Unit Coding. Keep posted for my future articles on web API development and also for cool projects using ASP NET Core.

Data validation with Fluent Validation for ASP NET Core

Oscar Montenegro — Thu, 13 Apr 2023 21:56:55 GMT

Data transfer objects and mapping in asp net core

Hello guys, I’m so glad to be back after a short rest. I took some time for myself to plan what’s coming next for my personal and professional life and to be honest, I’m still thinking about that but definitely, I feel more energic and enthusiastic about

Unit CodingOscar Montenegro

Today we will be talking about data validation using a very popular Nuget package called “Fluent Validation”. One of the coolest things about this Nuget package is that it uses a fluent interface to configure and initialize the data validators such as the fluent builder that we implemented for our Image Generator project some weeks ago, the fluent interface makes the initialization of complex objects more simple and readable and therefore it becomes more maintainable. Taking into consideration that this article is for very beginners we will touch on some basic topics on data validation.

What this article will cover?

The topics that we will cover in this article are the following.

Data validation
What is fluent validation?
Why se fluent validation
Installing fluent validation nuget package
Create a custom validator

Data validation

Data validation is an essential aspect of software development. It ensures that the data being processed is correct and consistent, leading to better performance, reliability, and security of the application. However, traditional methods of data validation can be time-consuming and error-prone. This is where Fluent Validation comes in. Fluent Validation is a library for .NET that simplifies the process of validating data in your application. In this article, we'll explore the benefits of Fluent Validation and how it can make your life as a developer easier.

What is Fluent Validation ?

Fluent Validation is an open-source library for .NET that makes it easy to define and execute validation rules. It provides a fluent interface for defining validation rules, making it easy to read and maintain. Fluent Validation can be used to validate any object, including complex objects, lists, and arrays.

Why use Fluent Validation ?

Fluent Validation provides a number of benefits over traditional validation methods, including:

Increased readability and maintainability of validation code: The fluent interface provided by Fluent Validation makes it easy to read and maintain validation code. This is especially true for complex validation rules.
Improved testability: Fluent Validation makes it easy to unit test validation rules. This ensures that your validation rules are working as expected and that any changes you make to the rules do not break existing functionality.
Increased productivity: By simplifying the validation process, Fluent Validation can help you write code more quickly and with fewer errors. This can save you time and reduce the likelihood of bugs.
Better error reporting: Fluent Validation provides detailed error messages that make it easy to understand what went wrong during validation. This can help you quickly identify and fix issues.

Now that you know what data validation is and why you should consider it for complex projects like this API we can move on to actually put our hands on some code taking as a starting point the installation of the fluent validation nuget package into our project.

Clone the repo from Github

To follow along with this article make sure you the repo from GitHub and make sure you get the code from the DtosAndMapping branch which contains the changes up to this article.

GitHub - Osempu/BlogAPI at DtosAndMapping

Contribute to Osempu/BlogAPI development by creating an account on GitHub.

GitHubOsempu

Install FluentValidation.AspNetCore nuget package

Let’s start implementing data validation installing the nuget package into our project using the dotnet cli or you could use the nuget package manager.

dotnet add package FluentValidation.AspNetCore

This command will install the needed nuget package for us to use fluent validation into our API and now we can start creating the validators for our Post model.

Add new Data Transfer Objects

In the last article we discussed what are DTOs and why are they used for on software development and we created one dto just for demonstration purposes. Now to create more meaningful validators we will create some more meaningful dtos as well, we will create a dto for when a user wants to create a new post when a new post is being updated and also a dto to return the posts which is the one that we already have but we will use “records”.

A Record is a reference type that provides a built-in functionality for encapsulating data and its properties are immutable which is just what we need for a dto.

Add new post DTO

Create a new record called AddPostDTO. When we need to create a new post we do not need to provide an Id so it becomes redundant to have the Id propertie as a requirement to create a post. So in this dto we only take the title, body and author of the post to be able to create it and then entity framework takes charge of passing the id to the database.

namespace BlogAPI.DTOs
{
    public record AddPostDTO(string Title, string Body, string Author);
}

Edit post DTO

To update a post we do need its Id to know which post we will update.

namespace BlogAPI.DTOs
{
    public record EditPostDTO(int Id, string Title, string Body, string Author);
}

Update the PostDTO to PostResponseDTO

We created a PostDTO in the data mapping article to return a post without displaying the created date property and last updated date property so now we will only make this a record to be consistent with all our dtos being records and change the name to PostResponseDTO to make it more meaningful and distinguishing between this dto and the EditPostDTO as they both hold the same properties.

namespace BlogAPI.DTOs
{
    public record PostResponseDTO(int Id, string Author, string Title, string Body);
}

Isn’t this code duplication?

You could argue that both EditPostDTO and PostResponseDTO are the same record as they hold the same properties and I did point that out a second ago but if you think it’s a good idea to use just one dto for the response and the edit as they hold the same properties right now that could be a big mistake, just think that if in the future our main Post model changes or our project needs changes and now I want to display the CreatedDate property when I return a Post I would update my dto that is used to edit and to return data but it makes no sense for the user to pass the CreatedDate value whenever he wants to edit the post and we would be forced to again build separate dtos for editing and to return the post. For that matter its important that we have separate dtos for that cases.

Add new mapping profiles

As we addded new dtos and updated our old dto we have to add new mapping profiles and update our PostProfiles file.

public class PostProfiles : Profile
{
    public PostProfiles()
    {
        CreateMap();
        CreateMap();
        CreateMap();
    }
}

Your PostProfiles class should look like this and also if you renamed your PostDTO to PostResponseDTO like me you will have to update the controller class as well but we will take a look on that in just a minute.

Create a custom validator

Let’s create validators for our AddPostDTO and EditPostDTO.

To define a set of validation rules for a particular object, you will need to create a class that inherits from AbstractValidator, where T is the type of class that you wish to validate.

Fluent validation documentation.

Add Post validator

public class AddPostValidator : AbstractValidator
{
    public AddPostValidator()
    {
        RuleFor(x => x.Title)
                .NotEmpty()
                .MaximumLength(100)
                .WithMessage("Title cannot exceed 100 characters");

        RuleFor(x => x.Body)
                .NotEmpty()
                .MaximumLength(500)
                .WithMessage("The body of the post cannot exceed 500 characters");

        RuleFor(x => x.Author)
                .NotEmpty()
                .MaximumLength(100)
                .WithMessage("The name of the author cannot exceed 100 characters");
    }
}

First we need to create a class called AddPostValidator that inherits from the AbstractValidator interface being T our AddPostDTO dto.

Then we can see fluent validation in action creating the first rule for the title property using the RuleFor method using a lambda expression to select the title property and chaining the NotEmpty method that states that the property should not be null nor empty, afther that we call the MaximumLength method and specify the max length that our title can have and last but not least we specify an error message to be displayed if the rule is not met. Then we apply the same rules for the body and author properties as our dto is not that complex yet we do not need to specify complex rules.

Edit Post validator

public class EditPostValidator : AbstractValidator
{
    public EditPostValidator()
    {
        RuleFor(x => x.Id)
                .NotEmpty()
                .WithMessage("Id cannot be null or empty");

        RuleFor(x => x.Title)
                .NotEmpty()
                .MaximumLength(100)
                .WithMessage("Title cannot exceed 100 characters");

        RuleFor(x => x.Body)
                .NotEmpty()
                .MaximumLength(500)
                .WithMessage("The body of the post cannot exceed 500 characters");

        RuleFor(x => x.Author)
                .NotEmpty()
                .MaximumLength(100)
                .WithMessage("The name of the author cannot exceed 100 characters");
    }
}

For our EditPostDTO dto we will apply the same rules as for the AddPostDTO except that we will ad the Id and we will specify that it cannot be empty nor bull and the error message to display if this rule is not met.

Register Fluent Validation in Program.cs

Let’s register the fluent validation nuget package as a service in the Program file below AddAutomapper let’s add these two lines to proceed to update the PostsController.

builder.Services.AddFluentValidationAutoValidation();
builder.Services.AddValidatorsFromAssemblyContaining();

Update the controllers using the new DTOs and validation the models

Now all that is left is to update our PostsController to add our newly added DTOs and to validate the models that the client is sending to our API so let’s begin with the CreatePost action.

[HttpPost]
public IActionResult CreatePost(AddPostDTO addPostDTO)
{
    try
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }

        var newPost = mapper.Map(addPostDTO);
				newPost.CreatedDate = DateTime.Now;
        repository.Add(newPost);
        return CreatedAtAction(nameof(GetPost), new { id = newPost.Id }, null);
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "Unexpected error on Post method");
        throw;
    }
}

you can see that we added an if statement to check whether the model state is valid and if not then we will return a bad request response to let the client know that he did a bas request and then asp net core will return the error messages that fluent validation provides by default and also the ones that we added in the validation classes. Also, we added a line to set the CreatedDate property to the moment we are creating the post.

Edit post endpoints

[HttpPut]
public IActionResult EditPost([FromBody] EditPostDTO editPostDto)
{
    try
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }
        var post = mapper.Map(editPostDto);

        post.LastUpdated = DateTime.Now;
        repository.Edit(post);
        return NoContent();
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "Unexpected error on Put(Edit) Method");
        throw;
    }
}

This is the second and last endpoint that we will update to support validation and to add our new dtos that works for the edit action. As in the last endpoint we added an if statement to check if the model state is valid this means that there is no error in the data that was sent to the API and then we map the EditPostDTO to the former Post model to edit it and if you pay attention we added a line to update the LastUpdated property so that every time that we update a post this property is updated automatically to that corresponding post.

Test your API

If you test the API and pass some invalid data then the response should look something like this.

{
  "type": "",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "traceId": "00-df250c99457dff70b0defd6d812b941f-7313f895506c9c22-00",
  "errors": {
    "Title": [
      "Title cannot exceed 100 characters"
    ],
    "Author": [
      "The name of the author cannot exceed 100 characters"
    ]
  }
}

We are getting a 400 BadRequest response message and an array called errors with the rules we are breaking being these the title rule and author rule as we are exceeding the limit of characters that we set on our validator class. Pretty satisfying don’t you think? Now you will avoid your API being full of invalid data and incomplete data so now we made it more resilient.

Conclusion

Data validation is essential for software development just imagine if anybody could insert any data into your API, that could be a mess. With data validation, we are making sure that only consistent and meaningful data is going into our database. Fluent validation is an excellent library that simplifies the process of data validation in our applications.

Thanks for your support, it means the world to me!

I always take a space at the end of every post to ask you to support me and follow me on my blog and youtube channel but today I want to thank you all for supporting me because the reason that I keep writing is that there are people like you that take some time and dedicate a special space to read whatever I’m writing and that means a lot to me it keeps me motivated and helps me to think that somebody in the world in the other side of this bright and clear screen is reading it and it’s being of use for him/she.

Thanks, everybody I will continue this API Development series until I feel that every basic aspect is covered and only then I will move on to another series. Also, tomorrow is friday and you know what that means, yay API Friday!!! I have been working on something special for you guys, nothing complex just something that you can build to have a good time and by the way if you want to know what was the last project for API Friday it was an image generator using the lorem picsum API and Blazor so check it out, I know you will have lots of fun coding it.

Image Generator with Blazor

Hello guys, happy Friday! Today I will inaugurate a new section that will be called “API Friday”. What will this API Friday be about? well, basically every Friday(or every two Fridays) I will post a .net project(blazor, asp net MVC, web API, etc.) made using a cool web

Unit CodingOscar Montenegro

So that would be it for today I have to prepare everything for tomorrow so again thanks for your support and see you on my next post!

Unit Coding

Build a Todo application with Blazor and C#

Give the project a start on Github

Create a new Blazor application

Let’s begin with the simplest implementation

Remove Bootstrap and default styling

Create a Todo model

Adding just the very basics

TODO

Leveling up our application

Creating the Header component

@AppTitle

Style for the header component

Adding more styling to the app.css file

Calling the header component from the home page

Styles for the home page

Using Line Awesome icons

Install Blazored.LocalStorage NuGet package

Styling the todo input

Adding the tasks container and todo component

Storing tasks in local storage

Adding the tasks filter

Your Todo app is now complete!

Optimizing Your .NET Application Development with NDepend

Overview

Code Review

Code Diff

Trendings

Dependencies Graph

Dependency Matrix

Metrics View

Conclusion

Implementing CORS in ASP.NET Core Web API: Enabling Secure Cross-Origin Resource Sharing

What is CORS?

Why Should I Use CORS?

Enabling a CORS in your Web App

Default Policies

Named Policies

Enable CORS using attributes

Enable CORS for Subdomains

Specify methods on your CORS policy

Set allowed Request Headers

Set Exposed Headers

Disable CORS

Conclusion

Follow me for Developer Tips and Clean Code Tips

A Comprehensive Guide to Caching Strategies in Web API Development

What is Caching ?

Benefits of Caching

1. Lightning-Fast Response Times

2. Reduced Server Load

3. Improved Scalability

Types of Caching

1. In-Memory Caching

2. Distributed Caching

3. Client-Side Caching

What is Response Caching?

The Response Cache Attribute

The Response Cache Parameters

Response Caching Middleware

Cache Profiles

Defining Cache Profiles in the appsettings.json file

Get the code repo from GitHub

Implementing Response Caching in your Web API

Add a Response Cache attribute to the Get Endpoints

Testing your application

Conclusion

Share this article with our brand-new sharing buttons!

Implementing HATEOAS in your ASP NET Core web API: Enhancing API Discoverability and Navigability

Overview of HATEOAS and its Significance in web APIs

Benefits of using HATEOAS in ASP NET Core Web APIs

Definition and core principles of HATEOAS

How HATEOAS enhances the discoverability and navigability of APIs

Role of hypermedia in HATEOAS

Get the code from GitHub

Install the RiskFirst.Hateoas nuget package

Add a Hateoas Response Model

Implementing HATEOAS in a new Controller

Register the Links Service in the program class

Test your web API and inspect the new Response

Adding more styling to the `app.css` file

Install `Blazored.LocalStorage` NuGet package