DEV Community: Oscar Montenegro

Optimizing Your .NET Application Development with NDepend

Oscar Montenegro — Mon, 26 Jun 2023 18:24:00 +0000

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.

A Comprehensive Guide to Caching Strategies in Web API Development

Oscar Montenegro — Thu, 08 Jun 2023 19:41:42 +0000

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 sinceit 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

unitcoding.com

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 through 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" ]
    }
  }
}

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<CacheProfile>());
    }
});

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<IActionResult> GetPost([FromQuery] QueryParameters parameters)
{
    ...
{

[HttpGet("{id:int}")]
[PostExists]
[ResponseCache(Duration = 60, VaryByQueryKeys = new []{"*"})]
public async Task<IActionResult> 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!

Share this article with our brand-new sharing buttons!

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:53:13 +0000

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.

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

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<string, Link> links;

    [JsonPropertyName("links")]
    public Dictionary<string, Link> Links 
    { 
        get => links ?? (links = new Dictionary<string, Link>());
        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<string, Link> 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<IActionResult> Get([FromQuery] QueryParameters parameters)
    {
        var posts = await postRepository.GetPostAsync(parameters);
        var postsDto = mapper.Map<IEnumerable<PostResponseDTO>>(posts);

        var hateoasResults = new List<PostHateoasResponse>();

        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<IActionResult> GetById(int id)
    {
        var post = await postRepository.GetPostAsync(id);
        var postDto = mapper.Map<PostResponseDTO>(post);

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

        return Ok(hateoasResult);
    }

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

        var newPost = mapper.Map<AddPostDTO, Post>(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<IActionResult> Edit(int id, [FromBody] EditPostDTO editPostDto)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }

        var post = mapper.Map<EditPostDTO, Post>(editPostDto);

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

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

    [HttpPatch("{id:int}", Name = nameof(Patch))]
    public async Task<ActionResult> Patch(int id, [FromBody] JsonPatchDocument<Post> 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<PostHateoasResponse> 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<PostHateoasResponse>(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": "http://localhost:5049/api/hateoas/posts",
      "method": "GET"
    },
    "GetById": {
      "rel": "PostsHateoas/GetById",
      "href": "http://localhost:5049/api/hateoas/posts/13",
      "method": "GET"
    },
    "Edit": {
      "rel": "PostsHateoas/Edit",
      "href": "http://localhost:5049/api/hateoas/posts/13",
      "method": "PUT"
    },
    "Delete": {
      "rel": "PostsHateoas/Delete",
      "href": "http://localhost:5049/api/hateoas/posts/13",
      "method": "DELETE"
    },
    "Patch": {
      "rel": "PostsHateoas/Patch",
      "href": "http://localhost:5049/api/hateoas/posts/13",
      "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 | Sofware Development | Sofware Engineering

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

unitcoding.com

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:32:46 +0000

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

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.

What are related Entities❓

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.

How to expose related Entities 🔎

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

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<IEnumerable<Post>> GetPostAsync(QueryParameters parameters);
    Task<Post> GetPostAsync(int id);
    Task<IEnumerable<Post>> GetPostByAuthorId(int id);
    Task<IEnumerable<Post>> 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<IEnumerable<Post>> 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<Post> 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<IEnumerable<Post>> 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<IEnumerable<Post>> 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<TagOnlyResponseDto> 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<Author, AuthorOnlyResponseDto>();
}

public TagProfiles()
{
    CreateMap<Tag, TagOnlyResponseDto>();
}

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<IActionResult> GetAuthor()
      {
          var authors = await repository.GetAsync();
          var authorsDto = mapper.Map<IEnumerable<AuthorOnlyResponseDto>>(authors);
          return Ok(authorsDto);
      }

        [HttpGet("{id:int}")]
        public async Task<IActionResult> GetAuthor(int id)
        {
            var author = await repository.GetAsync(id);
            var authorDto = mapper.Map<AuthorOnlyResponseDto>(author);
            return Ok(authorDto);
        }

        [HttpGet("{id:int}/posts")]
        public async Task<IActionResult> GetPostByAuthorId(int id)
        {
            var posts = await postRepository.GetPostByAuthorId(id);
            var postDto = mapper.Map<IEnumerable<PostResponseDTO>>(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<IActionResult> GetTag()
    {
        var tags = await repository.GetAsync();
        var tagsDto = mapper.Map<IEnumerable<TagOnlyResponseDto>>(tags);
        return Ok(tagsDto);
    }

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

    [HttpGet("{id:int}/posts")]
    public async Task<IActionResult> GetPostFromTagId(int id)
    {
        var posts = await postRepository.GetPostByTagId(id);
        var postsDto = mapper.Map<IEnumerable<PostResponseDTO>>(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.

Getting all the posts related to a Tag 🏷️

[
  {
    "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:20:46 +0000

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

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<Person>()
            .HasOne(p => p.Passport)
            .WithOne(a => a.Person)
            .HasForeignKey<Passport>(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<Review> 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<Review>()
            .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<Course> Courses { get; set; }
}

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

// Configuration
public class MyContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Student>()
            .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<Person>()
            .HasOne(p => p.Address)
            .WithOne(a => a.Person)
            .HasForeignKey<Address>(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

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<Post> which will be the collection navigation property

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

    public ICollection<Post> 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<Post>.

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

    public ICollection<Post> 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<Tag> 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<Post>
  {
      public void Configure(EntityTypeBuilder<Post> 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

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:43:58 +0000

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 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

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<LogActionFilter> 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<LogActionFilter>();

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<LoggingResourceFilter> 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<ExceptionLoggingFilter> 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<CustomEndpointFilter>();
}

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<CustomResultFilter>();
    });
}

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<GlobalLoggingFilter>();
    });
}

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

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<IActionResult> 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<IActionResult> GetPost(int id)

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

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

[HttpPatch("{id:int}")]
[PostExists]
public async Task<ActionResult> PatchPost(int id, [FromBody] JsonPatchDocument<Post> 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<Post> 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:24:48 +0000

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 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

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<ActionResult> PatchPost(int id, [FromBody] JsonPatchDocument<Post> 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<T> 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:09:26 +0000

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

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<IEnumerable<Post>> 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 16:25:08 +0000

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.But here is the last API Friday blog post just in case you want to give it a check.

Build a Google Translate Clone with Blazor and .NET

unitcoding.com

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

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<IEnumerable<Post>> GetPostAsync(QueryParameters parameters);
}

public async Task<IEnumerable<Post>> 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<IEnumerable<Post>> 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.

Thanks for your support, now follow me on social media!

As always thanks for reading my articles and I hope you are getting a lot from reading them for your daily coding and work. Remember to follow me on my blog Unit Coding and my YouTube channel even though I have not uploaded any content in a while 😅 also 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 on 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:09:47 +0000

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

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<IActionResult> 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<IEnumerable<Post>> 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<IEnumerable<Post>> GetPostAsync(int pageSize, int pageNumber)
{
        //Code omitted for brevity
}

Implementing pagination in `PostRepository` class 🏤

public async Task<IEnumerable<Post>> 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&currentPage=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<IActionResult> GetPost([FromQuery] QueryParameters parameters)
{
    var posts = await repository.GetPostAsync(parameters.PageSize, parameters.PageNumber);

    var postsDto = mapper.Map<IEnumerable<PostResponseDTO>>(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.

The Ultimate Guide to Creating a Google Translate Clone App from Scratch

Oscar Montenegro — Fri, 21 Apr 2023 16:47:20 +0000

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("https://google-translate1.p.rapidapi.com/language/translate/v2/detect"),
    Headers =
    {
        { "X-RapidAPI-Key", "YOUR_API_KEY" },
        { "X-RapidAPI-Host", "google-translate1.p.rapidapi.com" },
    },
    Content = new FormUrlEncodedContent(new Dictionary<string, string>
    {
        { "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.

<link href="GoogleTranslateClone.styles.css" rel="stylesheet" />

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 = "https://translation.googleapis.com/language/translate/v2";

        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<Dictionary<string,Language>> GetSupportedLanguages()
{
    var queryParams = new Dictionary<string, string>()
    {
        ["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<List<Language>>(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<Language> DetectLanguage(string input)
{
    var queryParams = new Dictionary<string, string>()
    {
        ["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<Language>(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<TranslatedText> Translate(string input, string source, string target)
{
    var queryParams = new Dictionary<string, string>()
    {
        ["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<TranslatedText>(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<GoogleTranslateClient>();

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.

<div class="container">
    <h1>Blazor Translate</h1>
    <div class="wrapper">
        <ul class="controls">
            <li class="row from">
                <select name="language-select" title="language-select" @bind="@sourceLanguage">
                    <option value="">Detect Language</option>
                    @foreach (var language in supportedLanguages)
                    {
                        <option value="@language.Key">@language.Value.name</option>
                    }
                </select>
            </li>

            <li class="exchange" @onclick="@ChangeSourceToTarget"><i class="fas fa-exchange-alt"></i></li>

            <li class="row to">
                <select name="language-select" title="language-select" @bind="@targetLanguage">
                    @foreach (var language in supportedLanguages)
                    {
                        <option value="@language.Key">@language.Value.name</option>
                    }
                </select>
            </li>
        </ul>

        <div class="text-input">
            <textarea class="from-text" name="" id="" cols="30" rows="10" placeholder="Enter Text"
                @bind="@sourceText"></textarea>
            <textarea class="to-text" name="" id="" cols="30" rows="10" readonly disabled placeholder="Translation"
                @bind="@translatedText"></textarea>
        </div>
    </div>
    <div class="detected-text">
        @if (!string.IsNullOrEmpty(notificationText))
        {
            <p>@notificationText</p>
        }
    </div>
    <button @onclick="@Translate">Translate Text</button>
</div>

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<string, Language> supportedLanguages = new Dictionary<string, Language>();

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

    private async Task<Dictionary<string, Language>> GetSupportedLanguages()
    => await client.GetSupportedLanguages();

    private async Task<Language> 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 aid of the GetSupportedLanguages method which as we remember return 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 message 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.

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.4.0/css/all.min.css" integrity="sha512-iecdLmaskl7CVkqkXNQ/ZH/XLlvWZOJyj7Yy7tcenmpD1ypASozpmT/E0iPtmFIB46ZmdtAc9eNBvH0H/ZpiBw==" crossorigin="anonymous" referrerpolicy="no-referrer" />

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

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 would have 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 — Thu, 20 Apr 2023 00:05:54 +0000

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

unitcoding.com

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

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<IEnumerable<Post>> GetPostAsync();
    Task<Post> GetPostAsync(int id);
    Task AddAsync(Post post);
    Task EditAsync(Post post);
    Task DeleteAsync(int id);
}

We need to return a Task<T> 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<IEnumerable<Post>> GetPostAsync()
    {
        var allPosts = await context.Posts.ToListAsync();
        return allPosts;
    }

    public async Task<Post> 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<IActionResult> GetPost()
{
    var posts = await repository.GetPostAsync();
    var postsDto = mapper.Map<IEnumerable<PostResponseDTO>>(posts);
    logger.LogDebug($"Get method called, got {postsDto.Count()} results");
    return Ok(postsDto);
}

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

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

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

        var newPost = mapper.Map<AddPostDTO, Post>(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<IActionResult> EditPost([FromBody] EditPostDTO editPostDto)
{
    try
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }
        var post = mapper.Map<EditPostDTO, Post>(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<IActionResult> 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<IActionResult>. 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.

DEV Community: Oscar Montenegro

Optimizing Your .NET Application Development with NDepend

Overview

Code Review

Code Diff

Trendings

Dependencies Graph

Dependency Matrix

Metrics View

Conclusion

A Comprehensive Guide to Caching Strategies in Web API Development

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

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 🧪

Get Post HATEOAS Response 📮

Conclusion 🌇

Almost Hitting 5K monthly views 😲📈🎉

Unit Coding | Sofware Development | Sofware Engineering

Exposing Related Entities in your Web API

What are related Entities❓

How to expose related Entities 🔎

Get the code from GitHub 🐙

Updating the PostRepository class ⤴️

IRepository class updated ⬆️

PostRepository Class 📫

Foreseeing Self-Reference Loop from Property Error ➿

Adding some new Dtos 🏭

Updating PostResponseDto 📬

Adding the new mapping profiles 🗺️

Updating the AuthorsController ✍🏾

Updating the TagsController 🏷️

Testing the API 🧪

Getting all the Authors ✍🏾

Getting all the Posts from an Author ✍🏾

Getting all the Tags 🏷️

Getting all the posts related to a Tag 🏷️

Posts Controller 🏤

Conclusion 🌇

We’ve reached 3K views on Unit Coding 🥳🎉🎊

Relationships in Entity Framework Core

What are relationships in Entity Framework Core ❓

One-to-One Relationship 🫂

One-to-Many Relationship 👨‍👩‍👧‍👦

Many-to-Many Relationship 👥

Configurations in Entity Framework Core ⚙️

By Convention 🏪

Data Annotations 📅

Fluent API 🍃

Implementing Entities Relationships in Your Project 👷🏾‍♂️

Defining Cache Profiles in the `appsettings.json` file

Install the `RiskFirst.Hateoas` nuget package 📦

Updating the `PostRepository` class ⤴️

`IRepository` class updated ⬆️

`PostRepository` Class 📫

Updating `PostResponseDto` 📬

Updating the `AuthorsController` ✍🏾

Updating the `TagsController` 🏷️

Getting all the `Posts` from an `Author` ✍🏾

Updating the `Post` model

`Post` Dtos updated

Applying your Action Filter in the `PostsController` 🍎

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

Example of a `Patch` Request Body 📄

Register NewtonsoftJson in the `Program` file 🪧

Implementing the `Patch` method 🩹

Test the `Patch` method with Postman or swagger 🧪

Update the `QueryPatameters` class 🏖️

Install the `System.Linq.Dynamic.Core` Nuget package 📦

Updating the `PostResponseDTO` class 🏛️