Mikołaj Kamiński

How to test typed HTTP clients in .NET 6?

2022-07-03T06:00:00-05:00

What is a typed HTTP client? In the simplest words, a strongly typed HTTP client is a class that has HttpClient dependency. Why do I prefer this solution over named HTTP clients?

You can easily inject the necessary dependencies into them.
There is no need to use strings as keys.
You may use IntelliSense while consuming them.

Here is an example of a client for which we will try to implement tests:

public class MyAwesomeHttpClient
{
    private readonly HttpClient _httpClient;
    private readonly ISomeOtherDependency _someOtherDependency;

    public MyAwesomeHttpClient(
        HttpClient httpClient,
        ISomeOtherDependency someOtherDependency)
    {
        _httpClient = httpClient;
        _someOtherDependency = someOtherDependency ?? throw new ArgumentNullException(nameof(someOtherDependency));
    }

    public async Task<string> GetRandomDadJoke()
    {
        var request = new HttpRequestMessage(HttpMethod.Get, new Uri("/", UriKind.Relative));
        var response = await _httpClient.SendAsync(request);

        if (!response.IsSuccessStatusCode)
            throw new Exception("I can't haz dad joke...");

        _someOtherDependency.DoNothig();
        var joke = await response.Content.ReadAsStringAsync();

        return joke;
    }
}

How to register and configure typed HTTP client?

To use typed HTTP clients, you must first register them in dependency injection container. Personally, I prefer to create a dedicated extension method, which I will then call on the service collection. Such an extension method has the advantage that I can register all the client’s dependencies and configure it in one place. Here is an example implementation:

public static IServiceCollection AddMyAwesomeHttpClient(this IServiceCollection services)
{
    services
        // Let's register our HTTP client
        .AddHttpClient<MyAwesomeHttpClient>()
        // Then we need to configure it
        .ConfigureHttpClient(httpClient =>
        {
            httpClient.BaseAddress = new Uri("https://icanhazdadjoke.com", UriKind.Absolute);
            httpClient.DefaultRequestHeaders
                .Add(nameof(HttpRequestHeader.Accept), MediaTypeNames.Text.Plain);
        })
        // Or maybe we want to add some exception policies to it?
        .AddPolicyHandler(HttpPolicyExtensions
            .HandleTransientHttpError()
            .RetryAsync(retryCount: 3));
    
    // Don't not forget about our client's dependencies!
    services.TryAddTransient<ISomeOtherDependency, SomeOtherDependency>();

    return services;
}

Let’s try to implement the tests.

First we need to mock the HttpClient

The core problem is mocking HttpClient, or rather HttpMessageHandler, which is used by HttpClient injected to the typed HTTP client.

For creating HttpMessageHandler mocks, I highly recommend the great MockHttp library created by Richard Szalay. Take a look at this example:

var httpMessageHandlerMock = new MockHttpMessageHandler();
// Mock the request
var mockRequest = httpMessageHandlerMock
        .When("https://icanhazdadjoke.com/")
        .Respond(
            MediaTypeNames.Text.Plain,
            "Why can't your nose be 12 inches long? Because then it'd be a foot!");
// Create a mock HttpClient
var httpClient = httpMessageHandlerMock.ToHttpClient();

var response = await httpClient.GetStringAsync("https://icanhazdadjoke.com/");
// response: Why can't your nose be 12 inches long? Because then it'd be a foot!

I think this tool is very useful.

The most obvious method of testing

Take a look at this sample test:

[Test]
public async Task MyAwesomeHttpClient_ShouldSucceed_WhenRequestingForRandomDadJoke()
{
    const string ValidJokeResponse =
        "My dog used to chase people on a bike a lot. It got so bad I had to take his bike away.";
    // Create and configure HttpMessageHandler mock
    var httpMessageHandlerMock = new MockHttpMessageHandler();
    httpMessageHandlerMock
        .When(HttpMethod.Get, "https://icanhazdadjoke.com/")
        .Respond(MediaTypeNames.Text.Plain, ValidJokeResponse);
    // Create mock HttpClient out of HttpMessageHandler mock
    var httpClientMock = httpMessageHandlerMock.ToHttpClient();
    // Configure it manually
    httpClientMock.BaseAddress = new Uri("https://icanhazdadjoke.com/", UriKind.Absolute);
    // Create MyAwesomeHttpClient instance manually
    var sut = new MyAwesomeHttpClient(
        httpClientMock,
        Mock.Of<ISomeOtherDependency>());

    var result = await sut.GetRandomDadJoke();

    result.Should()
        .Be(ValidJokeResponse);
}

I’m not happy with it. Actually, we inject not the same HttpClient that we configured with our AddMyAwesomeHttpClient extension method. At first glance, we can see several problems:

We need to manually inject dependencies into the typed client, instead of using a DI container for that.
The HttpClient we are mocking is not configured by the ConfigureHttpClient method. We need to configure it redundantly for the test purposes.
Mocked HttpClient is missing all exception policies we have configured.

It would definitely be best to test the HTTP client that we registered in the DI container with the AddMyAwesomeHttpClient method. Why? Because it is already properly configured and at the same time, we can test the AddMyAwesomeHttpClient method.

So, how to test it better?

The main idea is to create a test DI container, register our client in it with AddMyAwesomeHttpClient extension method, and then replace its primary HttpMessageHandler with mock.

In order to achieve this, we need to create a helper class, which implements IHttpMessageHandlerBuilderFilter interface. Its task will be to replace the primary HttpMessageHandler of the tested HttpClient with mock. Let’s say we name this class TestHttpMessageHandlerBuilderFilter.

The second thing is that we want to be able to overwrite the handlers of multiple clients registered in the DI container at the same time. For this reason, we also need to implement some kind of the HttpMessageHandler mock registry that our TestHttpMessageHandlerBuilderFilter will use. To simplify this issue, we can use our test DI container as a registry for the following entries:

internal sealed class HttpMessageHandlerMockWrapper
{
    public HttpMessageHandlerMockWrapper(
        Type typedHttpClientType,
        HttpMessageHandler httpMessageHandlerMock)
    {
        TypedHttpClientType = typedHttpClientType;
        HttpMessageHandlerMock = httpMessageHandlerMock;
    }
    
    public Type TypedHttpClientType { get; }
    public HttpMessageHandler HttpMessageHandlerMock { get; }
}

Our implementation of IHttpMessageHandlerBuilderFilter will look like this:

internal sealed class TestHttpMessageHandlerBuilderFilter
    : IHttpMessageHandlerBuilderFilter
{
    private readonly IEnumerable<HttpMessageHandlerMockWrapper> _httpMessageHandlerWrappers;

    public TestHttpMessageHandlerBuilderFilter(
        // Injection of previously registered maps
        IEnumerable<HttpMessageHandlerMockWrapper> httpMessageHandlerWrappers)

    {
        _httpMessageHandlerWrappers = httpMessageHandlerWrappers;
    }

    public Action<HttpMessageHandlerBuilder> Configure(Action<HttpMessageHandlerBuilder> next)
    {
        return builder =>
        {
            // Checking if a given HttpClient has a registered HttpMessageHandler mock
            var mockHandlerWrapper = _httpMessageHandlerWrappers
                .SingleOrDefault(x =>
                    x.TypedHttpClientType.Name.Equals(
                        builder.Name,
                        StringComparison.InvariantCultureIgnoreCase));

            if (mockHandlerWrapper is not null)
            {
                // If so, the default handler is replaced with mock
                Debug.WriteLine($"Overriding {nameof(builder.PrimaryHandler)} for '{builder.Name}' typed HTTP client");
                builder.PrimaryHandler = mockHandlerWrapper.HttpMessageHandlerMock;
            }
            next(builder);
        };
    }
}

Now we have to register everything in the test DI container. Let’s create an appropriate extension method for this purpose.

internal static class DependencyInjectionExtensions
{
    public static IServiceCollection OverridePrimaryHttpMessageHandler<TClient>(
        this IServiceCollection services,
        HttpMessageHandler mockMessageHandler)
    {
        if (services == null) throw new ArgumentNullException(nameof(services));
        if (mockMessageHandler == null) throw new ArgumentNullException(nameof(mockMessageHandler));

        // Register a mock handler
        services
            .AddTransient(_ => new HttpMessageHandlerMockWrapper(typeof(TClient), mockMessageHandler));

        // Replace the default or already registered IHttpMessageHandlerBuilderFilter
        // with our TestHttpMessageHandlerBuilderFilter
        services
            .Replace(
                ServiceDescriptor
                    .Transient<IHttpMessageHandlerBuilderFilter, TestHttpMessageHandlerBuilderFilter>());

        return services;
    }
}

Putting it all together

Let’s try to write a test of our typed client that will use dependency injection and our mocking mechanism.

[Test]
public async Task MyAwesomeTypedHttpClient_ShouldSucceed_WhenRequestingForRandomDadJoke()
{
    const string ValidJokeResponse =
        "My dog used to chase people on a bike a lot. It got so bad I had to take his bike away.";
    // Create and configure our HttpMessageHandler mock
    var httpMessageHandlerMock = new MockHttpMessageHandler();
    httpMessageHandlerMock
        .When(HttpMethod.Get, "https://icanhazdadjoke.com/")
        .Respond(MediaTypeNames.Text.Plain, ValidJokeResponse);
    // Create our test DI container
    var serviceProvider = new ServiceCollection()
        // Mock ISomeOtherDependency
        .AddTransient(_ => Mock.Of<ISomeOtherDependency>())
        // Add and configure our typed HTTP client
        .AddMyAwesomeHttpClient()
        // Overwrite what you need
        .OverridePrimaryHttpMessageHandler<MyAwesomeHttpClient>(httpMessageHandlerMock)
        .BuildServiceProvider();
    var sut = serviceProvider.GetRequiredService<MyAwesomeHttpClient>();

    var result = await sut.GetRandomDadJoke();

    result.Should()
        .Be(ValidJokeResponse);
}

It looks good and most importantly it works! We can even test our exception policy since we have fully configured HttpClient.

[TestCase(HttpStatusCode.BadRequest, 1)]
[TestCase(HttpStatusCode.InternalServerError, 4)]
public async Task MyAwesomeTypedHttpClient_ShouldFail_WhenReceiveErrorResponseCode(
    HttpStatusCode httpStatusCode, int failedRequestCountBeforeException)
{
    var httpMessageHandlerMock = new MockHttpMessageHandler();
    var testHttpRequestDefinition = httpMessageHandlerMock
        .When(HttpMethod.Get, "https://icanhazdadjoke.com/")
        .Respond(httpStatusCode);
    var serviceProvider = new ServiceCollection()
        .AddTransient(_ => Mock.Of<ISomeOtherDependency>())
        .AddMyAwesomeHttpClient()
        .OverridePrimaryHttpMessageHandler<MyAwesomeHttpClient>(httpMessageHandlerMock)
        .BuildServiceProvider();
    var sut = serviceProvider.GetRequiredService<MyAwesomeHttpClient>();

    var action = async () => await sut.GetRandomDadJoke();

    await action.Should()
        .ThrowAsync<Exception>();
    httpMessageHandlerMock.GetMatchCount(testHttpRequestDefinition)
        .Should().Be(failedRequestCountBeforeException);
}

Summary

Do you know a better way to test typed HTTP clients? Or maybe you have any questions or suggestions? If so, please don’t hesitate to contact me. I am curious what you think.

I created a sample application that I published on GitHub. Enjoy!

I couldn’t debug the code because of my name

2021-10-18T02:00:00-05:00

Some time ago, I finally managed to switch from Visual Studio to JetBrains Rider at work. Finally, because I used to work a lot with Rider before, and I really like this IDE. Unfortunately, I ran into some annoying problems with docker-compose debug configuration.

It turns out that the same problem also affects users of other InteliJ-based IDEs like RubyMine, PyCharm, PhpStorm and GoLand. Fortunately, I was able to fix it.

Debugging docker-compose service and UnicodeDecodeError

Rider solves the topic of Run/Debug configuration differently from Visual Studio, so I had to add my configuration myself. It is not that hard. All you need to do is select the docker-compose file, select the service to which the debugger is to attach, and that’s it.

What was my surprise when after clicking the Debug button I saw the following error:

Deploying 'Compose: local'...
docker-compose -f C:\Repositories\TestProject\docker-compose.yml -f C:\Users\Mikołaj\AppData\Local\JetBrains\Rider2021.2\tmp\docker-compose.override.yml up --no-deps --build my_service
ERROR: .UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb3 in position 536: invalid start byte

Have I made any mistake? I tried clicking the Run button. The application started without any problem. WTF?!

Mikołaj is a name of doom

I decided to check the difference between the Rider launch process in Debug and Release mode. It turned out that in the case of the Debug mode, it generates a docker-compose file with which it overwrites the original file. I was convinced that my original docker-compose was correct. Was the error related to the generated file? Let’s see what it looks like. My temporary file was stored in the following location: %LocalAppData%\JetBrains\Rider2021.2\tmp\docker-compose.override.yml

version: "3.4"
services:
  my_service:
    entrypoint:
    - "/riderDebugger/runtime-dotnet.sh"
    - "/riderDebugger/JetBrains.Debugger.Worker.exe"
    - "--mode=server"
    - "--frontend-port=57001"
    - "--backend-port=57101"
    environment:
      RIDER_DEBUGGER_LOG_DIR: "/riderLogs"
      RESHARPER_LOG_CONF: "/riderLogsConf/backend-log.xml"
    ports:
    - "57001:57001"
    - "57101:57101"
    volumes:
    - "C:\\Program Files (x86)\\JetBrains\\JetBrains Rider 2021.1.1\\lib\\ReSharperHost:/riderDebugger"
    - "C:\\Users\\Miko�aj\\AppData\\Local\\JetBrains\\Rider2021.2\\log\\DebuggerWorker\\\
      JetBrains.Debugger.Worker.2021_10_17_20_32_30:/riderLogs:rw"
    - "C:\\Program Files (x86)\\JetBrains\\JetBrains Rider 2021.1.1/bin:/riderLogsConf"

Take a look at the volumes section. One of the entries contains some strange character.

- "C:\\Users\\Miko�aj\\AppData\\Local\\JetBrains\\Rider2021.2\\log\\DebuggerWorker\\\
      JetBrains.Debugger.Worker.2021_10_17_20_32_30:/riderLogs:rw"

My username contains a "ł" character and because of it, this file cannot be processed properly.

But what can I do about it? After all, this file is generated automatically by Rider.

Let’s face the problem

When I found out that the bug was in the Rider itself, I reported it to technical support. I also found a similar report for PyCharm. Unfortunately, things haven’t moved forward since then. I decided to try to solve this problem myself. Fortunately, I was able to do this and can share my solution to this very annoying problem with others.

The first idea was to change the username to one that does not contain Polish characters. It turned out that Windows does not rename the user’s folder when changing the username. Manually renaming the folder was not an option. This way I could corrupt my profile in the system.

What if I changed the path where Rider stores temporary files? I started browsing the documentation from JetBrains and found an interesting article on advanced configuration of InteliJ-based IDEs. This article explains how you can change the paths that the IDE uses.

Solution

Start your IDE, and go to the Help section in the main menu. There you will find the Edit Custom Properties option. Click on it. The %APPDATA%\JetBrains\{your_IDE_version}\idea.properties file will open for editing.

Add the following line to it:

idea.system.path=${root.dir}/JetBrains/Rider/system

Save the file and restart the IDE. From now on, Rider will keep temporary files in C:\JetBrains\Rider\system directory. Of course you may have a different drive under the variable ${root.dir}, but the idea is the same.

Finally, you have to clean up after yourself. Go to the Help section of the main menu and click Delete Leftover IDE Directories.... Rider will scan for unnecessary folders and offer to delete them.

That’s all! Finally, you can start debugging your services launched from docker-compose!

Summary

From the moment the bug was reported to JetBrains support, 7 months passed until the publication of this post. I don’t know if they will ever fix this bug, but all I know is that it prevented me from working in my favorite IDE.

I hope you found this article helpful. If you have any questions about this, feel free to contact me.

My favorite way to handle configuration in .NET Core

2021-04-23T10:30:00-05:00

I am writing this blog post because I often see a configuration support proposal that uses hardcoded strings. Here’s a way to avoid it.

My way

This is a sample appsettings.json file:

{
    "ExampleConfig": {
        "ValueA": "aaa",
        "ValueB": "https://example.com",
        "ValueC": 1234
    }
}

This is our example model which we want to load from the configuration:

public class ExampleConfig
{
    public string ValueA { get; set; }
    public Uri ValueB { get; set; }
    public int ValueC { get; set; }
}

Here’s how I read the model from the configuration:

public class ExampleCommandHandler
{
    private readonly IConfiguration _configuration;

    public ExampleCommandHandler(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    public Task Handle(ExampleCommand)
    {
        var exampleConfig = _configuration
            .GetSection(nameof(ExampleConfig))
            .Get<ExampleConfig>()
            ?? throw new ConfigurationException(nameof(ExampleConfig));

        // ...
    }
}

There is one thing you need to watch out for. To call the Get<T> method, use Microsoft.Extensions.Configuration.Binder NuGet package.

That’s it. No hardcoded strings in the code!

An elegant way to validate MediatR commands and queries

2021-04-22T06:00:00-05:00

Today I would like to show you a really cool way to validate MediatR commands and queries using FluentValidation.

The OK way

Fine. Each of us validates commands and queries in some way. After all, they are the input. The vast majority of the validation code I’ve seen so far has been integrated with command and query handlers.

Here is an example handler code, which validates a command input.

public class CreateUserCommandHandler : IRequestHandler<CreateUserCommand>
{
    public async Task<Unit> Handle(
        CreateUserCommand request,
        CancellationToken cancellationToken)
    {
        // Some command validation logic e.g.
        if (string.IsNullOrEmpty(request.Username))
        {
            throw new ArgumentException($"Username cannot be empty");
        }

        // User creation logic
    }
}

There is nothing bad in that, but… What if we separate validation and command logic? Wouldn’t it be more maintainable?

Let’s separate it!

When I write about separation, I don’t mean extracting validation logic into a private method. It wouldn’t be a bit elegant. I’d like to extract all validation logic out of the handler. To achieve this, I am going to use the FluentValidation library.

Let’s implement our CreateUserCommand validator.

public class CreateUserCommandValidator : AbstractValidator<CreateUserCommand> {
  public CustomerValidator() {
    RuleFor(x => x.Username)
        .NotEmpty()
        .WithMessage("Username cannot be empty");
    RuleFor(x => x.Email)
        .NotEmpty()
        .WithMessage("Email address cannot be empty");
    RuleFor(x => x.Email)
        .EmailAddress()
        .WithMessage("Please specify a valid email address");
    // ...
  }
}

Of course, we have to register all our validators in the DI container. We can do it manually, but I recommend doing it using extensions from the extra NuGet package. Alternatively you can do it using Scrutor.

Then we have to modify our CreateUserCommandHandler to use our brand new CreateUserCommandValidator:

public class CreateUserCommandHandler : IRequestHandler<CreateUserCommand>
{
    private readonly IValidator<CreateUserCommand> validator;

    public CreateUserCommandHandler(
        IValidator<CreateUserCommand> validator) // AbstractValidator implements IValidator interface
    {
        _validator = validator;
    }

    public async Task<Unit> Handle(
        CreateUserCommand request,
        CancellationToken cancellationToken)
    {
        // Our whole validation code becomes:
        validator.ValidateAndThrow(request);

        // User creation logic
    }
}

Nice, but can we do it better? Well, of course we can.

Let’s call our validator implicitly

The last improvement will be to completely remove the explicit validation from the handler. Now it should look like this:

public class CreateUserCommandHandler : IRequestHandler<CreateUserCommand>
{
    public async Task<Unit> Handle(CreateUserCommand request, CancellationToken cancellationToken)
    {
        // User creation logic
    }
}

Now I have to tell you something important about MediatR. It allows you to implement something like middlewares. It’s called pipeline behavior.

Behaviors allow you to build your own pipeline that will be executed before the handler. Let’s implement our ValidationBehavior.

public class ValidationBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
    private readonly IValidator<TRequest> _validator;

    public ValidationBehavior(IValidator<TRequest> validator)
    {
        _validator = validator;
    }

    public Task<TResponse> Handle(
        TRequest request,
        CancellationToken cancellationToken,
        RequestHandlerDelegate<TResponse> next)
    {
        _validator.ValidateAndThrow(request); // Check out the other methods for more advanced handling of validation errors 
        return next();
    }
}

Finally, register it in a DI container. That’s it! Now, every time you run a command or query, it will be validated by the appropriate validator.

Nothing prevents you from implementing more validators for one command/query, but it will require modification of our ValidationBehavior. I’ll leave it for you as homework.

Summary

I hope you learned something interesting today. What do you think of this kind of separation? I think this makes the code easier to maintain.

I also decided to write a small demo that you can find in this GitHub repository. Enjoy!

Easy service registration in .NET DI containers using Scrutor

2021-04-21T06:00:00-05:00

I like to make my life easier. If I can automate a process, I’d love to do it. It is no different in programming. Today I would like to show you how to automate dependency registration in DI container.

Manual dependency registration

For example, we have a set of dependencies to register:

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddTransient<ICommandHandler<CreateUserCommand>, CreateUserCommandHandler>()
        .AddTransient<ICommandHandler<DeleteUserCommand>, DeleteUserCommandHandler>()
        .AddTransient<ICommandHandler<AddUserPostCommand>, AddUserPostCommandHandler>()
        .AddTransient<IQueryHandler<GetUserQuery, User>, GetUserQueryHandler>()
        .AddTransient<IQueryHandler<GetUserPostQuery, Post>, GetUserPostQueryHandler>();
}

It is not difficult to imagine a scenario where there will be many more dependencies to register. Luckily, there’s an easy way to automate this!

Automation with Scrutor

Let me introduce you to Scrutor. It is a small but powerful library that allows automatic assembly scanning and dependency registration. It is actually an IServiceCollection extensions set.

The following code does exactly the same as the previous example, except that it does it automatically.

public void ConfigureServices(IServiceCollection services)
{
    services.Scan(scan => scan
        .FromAssemblyOf<CreateUserCommand>() // Indicates the assembly where all dependencies are located 
            .AddClasses(classes => classes.AssignableTo(typeof(ICommandHandler<>))) // Register all command handlers
                .AsImplementedInterfaces() // We will be able to resolve them by their interfaces
                .WithTransientLifetime() // Scope definition
            .AddClasses(classes => classes.AssignableTo(typeof(IQueryHandler<,>)))
                .AsImplementedInterfaces()
                .WithTransientLifetime());
}

Now you won’t have to remember to register another dependency. Super handy, huh?

Concluding

In conclusion, it’s worth using Scrutor. Hope you find it useful and save you a lot of time. I encourage you to read its documentation and learn about its other capabilities.

Do you automate any boring and repetitive stuff? Let me know!

Do we have to await every single C# async method?

2021-04-20T10:30:00-05:00

Did you ever see code a like that? The method calls another asynchronous method and returns its direct result.

[HttpPost]
public async Task<GetUserQueryResult> Get([FromBody] GetUserQuery query)
{
    var result = await _mediatr.Send(query);
    return result;
}

Okay, it works perfectly well, so what’s the matter? Now take a look at the code below:

[HttpPost]
public Task<GetUserQueryResult> Get([FromBody] GetUserQuery id)
{
    return _mediatr.Send(query);
}

I got rid of the async and await keywords. This makes the Get method synchronous. It just passes the task on and does not wait for the result.

Both pieces of code work the same, but are they equally efficient? Let’s check it out!

So what’s the difference?

The await keyword is syntactic sugar. In fact, when compiled, it is turned into a state machine that manages the asynchronous code. Additional code increases execution time and consumes additional resources.

Let me show you an example class:

public class TestClass
{
    public Task<int> MethodA()
    {
        return Task.FromResult(1);
    }

    public async Task<int> MethodB()
    {
        return await Task.FromResult(1);
    }
}

And its benchmark:

public class Benchmark
{
    private TestClass testObject = new TestClass();

    [Benchmark]
    public async Task NoRedundantOperators()
    {
        await testObject.MethodA();
    }

    [Benchmark(Baseline = true)]
    public async Task RedundantOperators()
    {
        await testObject.MethodB();
    }
}

Here are the results of the benchmark:

Method	Mean	Error	StdDev	Ratio
NoRedundantOperators	34.90 ns	0.738 ns	1.035 ns	0.58
RedundantOperators	60.17 ns	1.243 ns	2.144 ns	1.00

As you can see, the code without unnecessary operators is almost twice as fast!

I have put all the benchmark code in my GitHub repository so you can test it yourself. You can find the repository here.

Finally

I hope I convince you that it is not always worth it to await every single async method call. As always, if you have any interesting thoughts on this topic, please let me know!

How to merge JSON documents in .NET Core and .NET 5?

2021-04-19T10:30:00-05:00

Let’s say we have two JSON documents that we would like to merge. How can this be achieved?

Using `Newtonsoft.Json`

In .NET Core, until version 3 was released, the default serializer was the well-known and liked Newtonsoft.Json. Merging JSON documents with this library is very simple:

var object_A = JObject.Parse("{ 'A': 1, 'B': 2, 'C': 3 }");
var object_B = JObject.Parse("{ 'C': 4, 'D': 5, 'E': 6 }");

var object_C = new JObject();
object_C.Merge(object_A);
object_C.Merge(object_B);
/*
object_C is:
{
  "A": 1,
  "B": 2,
  "C": 4,
  "D": 5,
  "E": 6
}
*/

Here comes `System.Text.Json`

System.Text.Json was released with the release of .NET Core 3, and it is part of its runtime. However, it can be used with earlier versions of .NET Core by installing the appropriate NuGet package.

So, how to merge JSON documents with a brand new, blazing fast library released by Microsoft? It turns out that at the time of writing this post, there is no user-friendly API implemented yet.

Does that mean it is impossible? Definitely not. While looking for a way to solve this problem, I came across an article on the Microsoft website that described the differences between System.Text.Json and Newtonsoft.Json.

For performance reasons, the JsonDocument object is read-only as opposed to the JObject. This is the reason why Microsoft has not implemented the document merge API. Fortunately, there is an API suggestion that is covered in this GitHub issue. It seems that the proposed API is faster than the API of the Newtonsoft.Json library.

Here is a BenchmarkDotNet comparison results of both APIs:

Method	Mean	Error	StdDev	Median	Min	Max	Ratio	Gen 0	Gen 1	Gen 2	Allocated
MergeNewtonsoft	29.01 us	0.570 us	0.656 us	28.84 us	28.13 us	30.19 us	1.00	7.0801	0.0610	-	28.98 KB
Merge_New	16.41 us	0.293 us	0.274 us	16.41 us	16.02 us	17.00 us	0.57	1.7090	-	-	6.99 KB

Final thoughts

It looks like System.Text.Json will stay with us longer. I wonder if it will get an official API implementation for merging JSON documents. What do you think? If you have any interesting thoughts on this topic please let me know!

ASP.NET Core, Newtonsoft JSON serializer and DateTime handling issue

2021-04-14T01:30:00-05:00

Today I encountered an interesting case. I got a report that “something changes the date format while processing data”. I started debugging our distributed system looking for the source of the problem. It took me a while, so I’d like to share this story today, so you don’t have to waste your time.

Dynamic properties in a statically typed world

One of the microservices handles the HTTP POST request which the body model is similar to this:

public class ExampleModel
{
    // ...
    public JObject DynamicObject { get; set; }
}

For simplicity let’s say that exactly that request model is stored in NoSQL database and could be retrieved with another endpoint.

Another service calls our application with a following HTTP request body:

{
    // ...
    "dynamicObject": {
        "someStringProperty": "2021-04-14T08:30:00.000+0000",
        "anotherStringProperty": "QWERTY"
    }
}

Then requests it back and gets following response:

{
    // ...
    "dynamicObject": {
        "someStringProperty": "2021-04-14T08:30:00Z", // wtf?!
        "anotherStringProperty": "QWERTY"
    }
}

As you can see, the value of someStringProperty is different from what was sent before! In my case, this is unacceptable behavior. I need it to be exactly the same string.

Solution

After a while of debugging I found a culprit. Newtonsoft JSON serializer parsed someStringProperty as a date. However, client service treats it as string. It turns out that this is default Newtonsoft JSON serializer behavior. It just guessed the type based on the value.

The solution is to create serializer with the following JsonSerializerSettings:

new JsonSerializerSettings()
{
    // by default it is DateParseHandling.DateTime
    DateParseHandling = DateParseHandling.None
};

Now someStringProperty will be parsed as a string. Fixed!

One more thing

While searching the internet for a solution to my problem, I came across an interesting open GitHub issue in the Newtonsoft.Json library repository. It is closely related to my problem. At the time of writing this post, it’s still open for almost 5 years!

Take a look: “A string that looks like a date is changed when deserializing an ISerializable object #904”.

Summary

Hopefully, writing this post will save someone from a long debugging session. If you have any interesting thoughts on this, or I helped you somehow, please let me know. I will be very pleased!

Extension methods in C# and Ruby

2021-04-12T01:00:00-05:00

Extending classes with new methods is a pretty useful feature of object-oriented programming languages. However, implementation of extension methods can be more or less simple and elegant. Today I would like to compare implementation of extension methods in C# and Ruby.

C# extension methods

Let’s consider the following example class.

public class ExampleClass
{
    public string GetName()
    {
        return "Mikołaj";
    }
}

To extend it with a new method we have to implement another independent static class, which has an implementation of our extension method.

public static class ExampleClassExtensions
{
    public static string Greet(this ExampleClass exampleClass)
    {
        var name = exampleClass.GetName();
        return $"Hello {name}!";
    }
}

There are two important things. The first parameter of the extension method have to be preceded by the this keyword and should be of the type on which the method is operating.

ExampleClassExtensions can be named anything you like. It may also contain extension methods for classes other than ExampleClass. I named it so as to keep a clear naming convention.

The Ruby way

Okay, so let’s start with our example class which will be extended with extra method.

class ExampleClass
    def get_name
        "Mikołaj"
    end
end

Implementation of an extension method is as simple as redefining our ExampleClass with an extra method. Take a look:

class ExampleClass
    def greet
        "Hello #{self.get_name}!"
    end
end

That’s it. Super simple.

Which one I consider to be better?

I really like simple solutions, so at first glance Ruby extension methods implementation seems better to me.

On the other hand, the C# solution does not directly modify the class being extended. The notation is more complicated, but it provides a separation between the class and its extensions.

It’s hard for me to decide which solution is better. I’m just getting started with Ruby, and I have plans to study its object model better. I think it is too early to express my opinion on this.

If you have any interesting thoughts on this topic, please let me know!

Why do I find Ruby sexy?

2021-04-10T06:00:00-05:00

I am a full time .NET developer, but I have been interested in Ruby for some time. Not very professional, but I liked this technology very much. I would like to share why I think so.

Human friendly syntax

Ruby’s creator, Yukihiro Matsumoto, said in one of the interviews: “Ruby is designed for humans, not machines”. I think that he managed to achieve his goal.

Ruby has very clean and simple syntax which makes it human friendly. I like when code is easy to read and understand.

def say_hello name
    "Hello #{name}!"
end

["Mikołaj", "Tom", "Jerry"]
    .map {|x| say_hello x}
    .each{|x| puts x}

At first, it may look a bit like Python syntax, but unlike it, Ruby doesn’t force indentation. I believe that this is a great advantage over Python.

I’ve heard that code written in Ruby is so readable that programmers use it to discuss business logic with non-technical people. Pretty cool!

Rich standard library

The Ruby Standard Library is so rich that I can’t cover all the cool features in this post. It’s great how many useful tools we get out of the box.

Let me show you some date and time examples.

Time.now                # produces current date and time
Time.now.utc            # produces current date and time converted to UTC
Time.new("2021-06-01")  # produces new Time object which stores given date
Time.at(1617443220)     # same as above but using timestamp
Time.now.monday?        # indicates if date is monday

A few more examples:

123.digits                  # produces [3, 2, 1]
"Test".chars                # produces ["T", "e", "s", "t"]
[1, 2, 3].combination(2)    # need combinations of array elements?
[1, 2, 3].permutation       # or maybe permutations?
[1, nil, 2, nil, 3].compact # returns new array without nil values
[[1, 2], [3, 4]].flatten    # produces [1, 2, 3, 4]
[1, 2, 3].rotate            # produces [2, 3, 1]

Super handy and readable! Especially compared to e.g. the standard JavaScript library which is very poor.

I really encourage you to review the documentation because Ruby has a lot more interesting features.

Deeply ingrained testing culture

Should I write tests or not? This is obvious to Ruby programmers. They just write tests. It’s part of their culture. I am writing about it because it is not so obvious in other technologies.

Have you ever worked on any legacy projects without a single unit test? I used to and it was a traumatic experience. Ruby developers starting to work with legacy code can expect their code was somehow tested. It is better to have slow or low quality tests than none.

I’ve seen it somewhere before…

As I said before, I am a full time .NET developer. I am really accustomed to C# and its features such as Linq.

I love the way I can chain Linq methods. And guess what… Ruby has very similar feature! Take a look at this two code snippets (first is C#, second is Ruby):

new string[] { "Tom", "Jerry", "Spike" }
    .Where(x => x.Contains('e'))
    .Select(x => x.Length)
    .Sum();

["Tom", "Jerry", "Spike"]
    .filter{|x| x.include? "e"}
    .map{|x| x.length}
    .sum

At first glance, you can see that both pieces of code do exactly the same thing. For me both method chains are clearly traceable, readable and very elegant.

Remote work

Finally, remote work is very popular in the Ruby world. Most of the Ruby programmers worked this way before it became so popular in the pandemic era. For me personally, remote work is the best way to work. This is a huge time saver.

Final thoughts

I have to admit, Ruby programming is very enjoyable. It definitely deserves to dive deeper into its features. It’s hard for me to find something that I don’t like.

I think the next step is to look at the Ruby on Rails framework. I’ve heard a lot of good feedback about it. Especially about how efficient and productive it is to create an application using it.

If you have any interesting thoughts on this topic, let me know!

Mikołaj Kamiński

How to test typed HTTP clients in .NET 6?

How to register and configure typed HTTP client?

First we need to mock the HttpClient

The most obvious method of testing

So, how to test it better?

Putting it all together

Summary

I couldn’t debug the code because of my name

Debugging docker-compose service and UnicodeDecodeError

Mikołaj is a name of doom

Let’s face the problem

Solution

Summary

My favorite way to handle configuration in .NET Core

My way

An elegant way to validate MediatR commands and queries

The OK way

Let’s separate it!

Let’s call our validator implicitly

Summary

Easy service registration in .NET DI containers using Scrutor

Manual dependency registration

Automation with Scrutor

Concluding

Do we have to await every single C# async method?

So what’s the difference?

Finally

How to merge JSON documents in .NET Core and .NET 5?

Using Newtonsoft.Json

Here comes System.Text.Json

Final thoughts

ASP.NET Core, Newtonsoft JSON serializer and DateTime handling issue

Dynamic properties in a statically typed world

Solution

One more thing

Summary

Extension methods in C# and Ruby

C# extension methods

The Ruby way

Which one I consider to be better?

Why do I find Ruby sexy?

Human friendly syntax

Rich standard library

Deeply ingrained testing culture

I’ve seen it somewhere before…

Remote work

Final thoughts

Using `Newtonsoft.Json`

Here comes `System.Text.Json`