DEV Community: Dev Leader

How To Use IServiceCollection In Console Applications – What You Need To Know

Dev Leader — Mon, 20 May 2024 14:00:00 +0000

When it comes to dependency injection and using the built-in IServiceCollection, the framing feels such that we’re restricted to ASP.NET Core. So if we wanted to use IServiceCollection in console applications instead, what options do we have?

It turns out that we absolutely can! In this article, I’ll touch on one of the Microsoft Learn articles as well as explain an alternative approach… That you can run right in your browser with dotnetfiddle!

Microsoft Learn Article on IServiceCollection in Console Applications

Microsoft Learn is a tremendous source of valuable information. I feel like in recent years it continues to surprise me how much valuable information we can find there since I’m used to just relying on MSDN for doc comments and maybe the odd helpful example.

However, in this case, I was a little taken back because the article seemed to be a little bit more cumbersome than I was expecting. If our goal is just to be able to use the IServiceCollection interface so that we can work with our familiar dependency injection API, I would hope that we can stick to the basics.

However, it looks like the example in the tutorial goes a little bit beyond that and demonstrates the usage of an HostApplicationBuilder.

HostApplicationBuilder For Dependency Injection

Let’s look at the example code, which is taken directly from the Microsoft Learn article:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using ConsoleDI.Example;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);

builder.Services.AddTransient<IExampleTransientService, ExampleTransientService>();
builder.Services.AddScoped<IExampleScopedService, ExampleScopedService>();
builder.Services.AddSingleton<IExampleSingletonService, ExampleSingletonService>();
builder.Services.AddTransient<ServiceLifetimeReporter>();

using IHost host = builder.Build();

ExemplifyServiceLifetime(host.Services, "Lifetime 1");
ExemplifyServiceLifetime(host.Services, "Lifetime 2");

await host.RunAsync();

static void ExemplifyServiceLifetime(IServiceProvider hostProvider, string lifetime)
{
    using IServiceScope serviceScope = hostProvider.CreateScope();
    IServiceProvider provider = serviceScope.ServiceProvider;
    ServiceLifetimeReporter logger = provider.GetRequiredService<ServiceLifetimeReporter>();
    logger.ReportServiceLifetimeDetails(
        $"{lifetime}: Call 1 to provider.GetRequiredService<ServiceLifetimeReporter>()");

    Console.WriteLine("...");

    logger = provider.GetRequiredService<ServiceLifetimeReporter>();
    logger.ReportServiceLifetimeDetails(
        $"{lifetime}: Call 2 to provider.GetRequiredService<ServiceLifetimeReporter>()");

    Console.WriteLine();
}

There’s a lot going on here, of course, because they want to use a single example to demonstrate a few different things. However, my biggest challenges with this is that we can see the IServiceCollection being used via the builder.Services property call… but why do we need to go make an entire hosted application here?

Now, I’m not claiming that you shouldn’t use a hosted application or anything like that — but I am saying that this feels a little bit heavy-handed. If I just want to use IServiceCollection then why am I required to build a hosted application?

Using IServiceCollection in Console Applications Directly

It turns out that it’s not complex rocket surgery to get this to work without the hosted application pieces from the Microsoft Learn example. That’s important for me because I want to provide people alternatives when I create content about Autofac and they just want to use IServiceCollection like they are familiar with.

Let’s look at this example code which you can see directly on dotnetfiddle:

Simply, we can create a new service collection by creating a new ServiceCollection instance:

var services = new ServiceCollection();

Interestingly there was no dependency on having a hosted application or any other type of builder to do this. We can leverage it directly. It’s also important to note in the dotnetfiddle example that I shared that there are no Nugets imported. So we are able to create this instance without additional packages added.

From there, we can start to register our dependencies directly onto the IServiceCollection (keeping in mind I am only illustrating one type of dependency here):

services.AddSingleton<MyService>();
services.AddSingleton<MyDependency>();

However, this is just the service collection and we still need to create the instance of a service provider that we can resolve dependencies from:

using var serviceProvider = services.BuildServiceProvider();

With the service provider available, we can go ahead and resolve dependencies directly from it:

var myService = serviceProvider.GetRequiredService<MyService>();

Wrapping Up IServiceCollection in Console Applications

To wrap up this article, we don’t need to go with a hosted application if we want to leverage an IServiceCollection in console applications for dependency injection. While the Microsoft Learn article is awesome with plenty of solid examples, I felt like it overcomplicated what could otherwise be a bit more straightforward.

So if you’re looking to go leverage an IServiceCollection in your console projects instead of Autofac, go nuts! Even though I like using Autofac for all of my dependency injection, I think it’s important to understand the options that you have!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Dev Leader Weekly | Substack

My weekly newsletter that simplifies software engineering for you, along with C# code examples. Join thousands of software engineers from companies like Microsoft and Amazon who are already reading! Click to read Dev Leader Weekly, a Substack publication with thousands of subscribers.

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

Autofac ComponentRegistryBuilder in ASP.NET Core – How To Register Dependencies

Dev Leader — Thu, 09 May 2024 14:00:00 +0000

In this article, we’ll be exploring how to use Autofac ComponentRegistryBuilder in ASP.NET Core. Prior articles in this series have highlighted some challenges for getting set up to do C# plugin architectures — at least for my own standards. I’ll be walking us through how this approach can help overcome some of the challenges that have previously been highlighted.

This will be part of a series where I explore dependency resolution with Autofac inside of ASP.NET Core. I'll be sure to include the series below as the issues are published:

At the end of this series, you'll be able to more confidently explore plugin architectures inside of ASP.NET Core and Blazor -- which will be even more content for you to explore. Keep your eyes peeled on my Dometrain courses for a more guided approach to these topics later in 2023.

Dev Leader Weekly | Substack

weekly.devleader.ca

Where Did We Leave Off With Autofac in ASP.NET Core?

The previous two articles looked at the following scenarios:

Setting up using the AutofacServiceProviderFactory as the standard recommended approach
Skipping AutofacServiceProviderFactory and using Autofac ContainerBuilder directly

In both cases, we were able to get a web application up and running using Autofac for dependency injection. However, both of these had limitations around:

Accessing the WebApplication instance on the container
Weird nuances with minimal API support

While both options are absolutely viable — and may be great for you given your constraints — I wanted to push a bit further to see if the wrinkles could be ironed out. I want to strive towards having configuration done in separate Autofac modules and pushing towards a C# plugin architecture for the majority of my application development.

Exploring A Sample ASP.NET Core Application

This one is going to be different than the previous articles — we’ve achieved plugin status. I want to show you how the code from the previous examples can now be broken out into more dedicated pieces. Most of what we’ve gone over before is the same concept, but I’ve reduced the weather route to something more contrived just to eliminate the waste.

Make sure to follow along with this video on Autofac for additional explanations as we go through:

The Entry Point Configuration

Here’s how simple our Program.cs file is now:

await new FullResolveWebApi().RunAsync(CancellationToken.None);

That’s right — one line of code. But okay, you’re probably curious where all the setup actually takes place. Let’s go a bit deeper:

using Autofac;

internal sealed class FullResolveWebApi
{
    public async Task RunAsync(CancellationToken cancellationToken)
    {
        var containerBuilder = new MyContainerBuilder();
        using var container = containerBuilder.Build();
        using var scope = container.BeginLifetimeScope();

        var app = scope
            .Resolve<ConfiguredWebApplication>()
            .WebApplication;
        await app.RunAsync(cancellationToken).ConfigureAwait(false);
    }
}

This looks familiar to what we saw in the previous example! We’re able to get the goodness of that really lean startup configuration But wait! What’s that custom MyContainerBuilder class?!

using Autofac;

using System.Reflection;

internal sealed class MyContainerBuilder
{
    public IContainer Build()
    {
        ContainerBuilder containerBuilder = new();

        // TODO: do some assembly scanning if needed
        var assembly = Assembly.GetExecutingAssembly();
        containerBuilder.RegisterAssemblyModules(assembly);

        var container = containerBuilder.Build();
        return container;
    }
}

This is missing from the code above if we compare it to the previous article, but it can also be extended to do assembly scanning if that’s a requirement. So far, so good. We have one more piece though, and that’s ConfiguredWebApplication:

internal sealed class ConfiguredWebApplication(
    WebApplication _webApplication,
    IReadOnlyList<PreApplicationConfiguredMarker> _markers)
{
    public WebApplication WebApplication => _webApplication;
}

internal sealed record PreApplicationBuildMarker();

internal sealed record PreApplicationConfiguredMarker();

This marker record might seem a bit confusing but we’ll tie this all together in a dedicated section.

WebApplicationBuilder Autofac Module

Now that we’ve seen how our initial ASP NET Core application bootstrap code is looking, it’s time to look at some of the core dependency registration that’s going to be a union of what we saw in the previous articles AND some new behavior:

using Autofac;
using Autofac.Extensions.DependencyInjection;

internal sealed class WebApplicationBuilderModule : global::Autofac.Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .Register(ctx =>
            {
                var builder = WebApplication.CreateBuilder(Environment.GetCommandLineArgs());
                return builder;
            })
            .SingleInstance();
        builder
            .Register(ctx =>
            {
                var config = ctx.Resolve<WebApplicationBuilder>().Configuration;
                return config;
            })
            .As<IConfiguration>()
            .SingleInstance();

        WebApplication? cachedWebApplication = null;
        builder
            .Register(ctx =>
            {
                if (cachedWebApplication is not null)
                {
                    return cachedWebApplication;
                }

                var webApplicationBuilder = ctx.Resolve<WebApplicationBuilder>();
                ctx.Resolve<IReadOnlyList<PreApplicationBuildMarker>>();

                webApplicationBuilder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory(containerBuilder =>
                {
                    foreach (var registration in ctx.ComponentRegistry.Registrations)
                    {
                        containerBuilder.ComponentRegistryBuilder.Register(registration);
                    }

                    containerBuilder
                        .RegisterInstance(webApplicationBuilder)
                        .SingleInstance();
                }));

                cachedWebApplication = webApplicationBuilder.Build();
                return cachedWebApplication;
            })
            .SingleInstance();
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();
                app.UseHttpsRedirection();
                return new PreApplicationConfiguredMarker();
            })
            .SingleInstance();
        builder
            .RegisterType<ConfiguredWebApplication>()
            .SingleInstance();
    }
}

You’ll notice that the code snippet above shows that we’re now mixing in the AutofacServiceProviderFactory alongside our standalone Autofac ContainerBuilder approach. What we’re able to do is leverage this code to re-register some of the dependency registrations on the second Autofac ContainerBuilder:

foreach (var registration in ctx.ComponentRegistry.Registrations)
{
    containerBuilder.ComponentRegistryBuilder.Register(registration);
}

Now that we can duplicate our registrations, we get the registration of the WebApplication from the parent container onto the dedicated WebApplication‘s ContainerBuilder. But two things we should note:

We need to cache the WebApplication instance. This is because later on when the WebApplication instance itself needs to resolve dependencies that depend on an instance of WebApplication, it will go re-run the registration even though it’s a single instance! This is because this is a duplicated registration across the container that has never technically been executed at the time of registration. We may need to pay special attention to this sort of thing as we go forward to avoid expensive re-resolution of types.
We see another marker type: PreApplicationConfiguredMarker. What’s with these markers?!

Marker Classes for Controlling Dependency Ordering and Requirements

So far we’ve seen two instances of marker types. These marker types are a way that we can force certain registration code to execute before some other registration code executes. This is a more flexible way of saying “I don’t care which types specifically get registered or which registration code runs, but anyone that needs to be registered before some checkpoint, make sure you return one of these”. This allows us to force code to execute before a checkpoint.

If we consider the code in the example above, we see that the ConfiguredWebApplication instance requires the full collection of PreApplicationConfiguredMarker instances. This means that we can’t even create an instance of ConfiguredWebApplication until all dependent code, as indicated by our marker type, has finished executing. This essentially forces Autofac to run certain code for us because it will attempt to run all code that provides one of these marker instances.

The two markers we see in this example code are very naive/primitive — however, this concept can be expanded to provide more robust checkpoints in your dependency registration process.

CSharp Plugin Architecture in ASP.NET Core Unlocked!

The cat’s out of the bag! We can now successfully create an Autofac module for a plugin! This code shows us enabling C# plugin architecture in ASP.NET Core as we’re able to add a new discoverable module that adds its own API endpoints:

using Autofac;

namespace Plugins;

internal sealed class PluginModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        // load whatever dependencies you want in your plugin
        // taking note that they will be able to have access
        // to services/dependencies in the main application
        // by default
        builder.RegisterType<DependencyA>().SingleInstance();
        builder.RegisterType<DependencyB>().SingleInstance();
        builder.RegisterType<DependencyC>().SingleInstance();

        // minimal APIs can resolve dependencies from the
        // method signature itself
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();

                app.MapGet(
                    "/hello",
                    (
                        DependencyA dependencyA
                      , DependencyB dependencyB
                      , DependencyC dependencyC
                    ) =>
                    {
                        return new
                        {
                            AAA = dependencyA.ToString(),
                            BBB = dependencyB.ToString(),
                            CCC = dependencyC.ToString(),
                        };
                    });

                // this is a marker to signal a dependency
                // before the application can be considered
                // configured
                return new PreApplicationConfiguredMarker();
            })
            .SingleInstance();
    }
}

internal sealed class DependencyA(
    WebApplicationBuilder _webApplicationBuilder)
{
    public override string ToString() => _webApplicationBuilder.ToString();
}

internal sealed class DependencyB(
    Lazy<WebApplication> _webApplication)
{
    public override string ToString() => _webApplication.Value.ToString();
}

internal sealed class DependencyC(
    IConfiguration _configuration)
{
    public override string ToString() => _configuration.ToString();
}

If you’d like a more full explanation as to what you’re seeing, I highly recommend you read the articles linked at the top of this one first just to get an idea of why we have some dependencies set up like this. The TL;DR is that this code demonstrates that we can access some dependencies that are of interest to us when building plugin architectures.

What Benefits For CSharp Plugin Architecture Have Been Unlocked?

The code examples in this article are essentially marrying approaches from two of the previous articles… so hopefully we have the best of both worlds! Let’s have a look:

Can access WebApplicationBuilder instance from the WebApplication‘s dependency container.
Can access IConfiguration instance from the WebApplication‘s dependency container.
Can access WebApplication instance from the WebApplication‘s dependency container.
Can resolve Autofac ContainerBuilder dependencies on the minimal APIs directly
Can create separate Autofac modules (i.e. for plugin usage) that register minimal APIs directly onto the WebApplication instance
Can get an extremely lightweight (one line!) entry point to our application. The core “skeleton” application code is fundamentally just setting up dependencies to be resolved.

All of these are boxes that I wanted to check before continuing to build plugins. With this infrastructure in place, I feel much more confident!

What Gaps Are Left For CSharp Plugin Architecture?

Of course, we need to look at both pros AND cons when we analyze things. Let’s dive in:

We have two dependency containers to worry about. In theory, the usage of Autofac ComponentRegistryBuilder in ASP.NET Core should allow us to clone registrations between the two, but more complexity can potentially arise from this as we continue.
We saw an interesting need to cache the WebApplication instance to avoid dependency recreation — are there other scenarios like this we haven’t hit yet?
One of the general plugin architecture concerns: Being able to configure EVERYTHING with plugins can make some things harder to find and structure. Do we really need these little marker types to help organize ourselves?

Wrapping Up Autofac ComponentRegistryBuilder in ASP.NET Core

Overall, I’m quite happy with how using Autofac ComponentRegistryBuilder in ASP.NET Core has allowed us to progress our dependency injection patterns. This approach which I’ve highlighted in the article has made it significantly easier for me to go structure plugins the way that I’d like to in a C# plugin architecture. Not without tradeoffs — but I feel this pattern fits my needs.

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

Autofac ContainerBuilder in ASP.NET Core – What You Need To Know

Dev Leader — Wed, 08 May 2024 14:00:00 +0000

There are many ways to manage dependency injection inside our applications, and I think it’s important to understand the benefits and limitations of different approaches. Using an Autofac ContainerBuilder in ASP.NET Core as the primary way to structure your dependencies instead of using the suggested AutofacServiceProviderFactory is one such path we can explore!

In this article, I highlight how to use Autofac’s ContainerBuilder in your ASP.NET Core application instead of the AutofacServiceProviderFactory. We’ll look at what you can and cannot do with this approach, versus the other approaches we have access to with dependency injection.

This will be part of a series where I explore dependency resolution with Autofac inside of ASP.NET Core. I'll be sure to include the series below as the issues are published:

Dev Leader Weekly | Substack

weekly.devleader.ca

The Problem With AutofacServiceProviderFactory

To be fair, the section title is almost click-bait. I do think that AutofacServiceProviderFactory being used as the suggested way to set up Autofac in your ASP.NET Core applications is great for most applications. The great majority of developers who want to use Autofac as their dependency injection framework of choice would not run into many issues at all this way.

It does afford us the ability to:

Access the WebApplicationBuilder (and anything available at this point in time)
Access to the instance of IConfiguration (also available off the WebApplicationBuilder instance)
Ability to pass dependencies onto minimal APIs

But the big issue for me: We can’t access the WebApplication instance. When I build plugin architectures in C#, in particular building ASP.NET Core applications, I like to have access to the WebApplication instance in order to register routes. This allows me to register minimal APIs from my plugins with ease, which technically only need access to an implementation of IEndpointRouteBuilder to get the handy syntax.

Can I register non-minimal APIs without this? Absolutely. Is there another way to provide similar syntax and not require a WebApplication instance? Very likely. But instead of trying to work around THAT problem, I wanted to see if I could just get access to the dependency I am interested in.

It was time to change the plan on how to set up my dependency container!

Exploring A Sample ASP.NET Core Application

Let’s look at a sample application so that we have some common ground to explore. If you’ve read the previous article, this will look similar — a variation of the sample weather application:

using Autofac;

using Microsoft.AspNetCore.Mvc;

// personal opinion:
// I absolutely love having the entry point of my
// applications being essentially:
// - make my dependencies
// - give me the primary dependency
// - use it
// - ... nothing else :)
ContainerBuilder containerBuilder = new();
containerBuilder.RegisterModule<MyModule>();

using var container = containerBuilder.Build();
using var scope = container.BeginLifetimeScope();
var app = scope.Resolve<WebApplication>();
app.Run();

internal record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

internal sealed class MyModule : Module
{
    protected override void Load(ContainerBuilder containerBuilder)
    {
        containerBuilder.RegisterType<DependencyA>().SingleInstance();
        containerBuilder.RegisterType<DependencyB>().SingleInstance();
        containerBuilder.RegisterType<DependencyC>().SingleInstance();
        containerBuilder
            .Register(ctx =>
            {
                var builder = WebApplication.CreateBuilder(Environment.GetCommandLineArgs());
                return builder;
            })
            .SingleInstance();
        containerBuilder
            .Register(ctx => ctx.Resolve<WebApplicationBuilder>().Configuration)
            .As<IConfiguration>()
            .SingleInstance();
        containerBuilder
            .Register(ctx =>
            {
                var builder = ctx.Resolve<WebApplicationBuilder>();

                var app = builder.Build();
                app.UseHttpsRedirection();

                // FIXME: the problem is that the Autofac ContainerBuilder
                // was used to put all of these pieces together,
                // but we never told the web stack to use Autofac as the
                // service provider.
                // this means that the minimal API will never be able to
                // find services off the container. we would need to resolve
                // them BEFORE the API is called, like in this registration
                // method itself, from the context that is passed in.
                //DependencyA dependencyA = ctx.Resolve<DependencyA>();

                // FIXME: But... What happens if something wants to take a
                // dependency on the WebApplication instance itself? Once the
                // web application has been built, there's no more adding
                // dependencies to it!

                var summaries = new[]
                {
                    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
                };

                app.MapGet(
                    "/weatherforecast",
                    (
                        [FromServices] DependencyA dependencyA
                      , [FromServices] DependencyB dependencyB
                      , [FromServices] DependencyC dependencyC
                    ) =>
                    {
                        var forecast = Enumerable
                            .Range(1, 5)
                            .Select(index => new WeatherForecast
                            (
                                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                                Random.Shared.Next(-20, 55),
                                summaries[Random.Shared.Next(summaries.Length)]
                            ))
                            .ToArray();
                        return forecast;
                    });

                return app;
            })
            .SingleInstance();
    }
}

internal sealed class DependencyA(
    WebApplicationBuilder _webApplicationBuilder);

internal sealed class DependencyB(
    WebApplication _webApplication);

internal sealed class DependencyC(
    IConfiguration _configuration);

One callout of this approach is that using the Autofac ContainerBuilder class as our primary dependency container affords us the opportunity to structure our entry point to just:

Container creation
Dependency registration
Primary dependency resolution
… Call a single method to start the app up!

This is, in my opinion, ideal application startup code. Why? Because you never need to come back here to touch it. Ever. No matter how many things you add in! And that’s all because you can scan assemblies to load more modules.

Again, this is a personal preference of mine and I am not trying to claim this should be everyone’s goal.

The Flaws of Autofac ContainerBuilder in ASP.NET Core

Of course, another approach that isn’t quite bulletproof. So let’s discuss what we DON’T get with this setup of Autofac:

Service-resolved parameters passed on minimal APIs simply don’t work. The WebApplication that was built is not configured to use Autofac as the dependency injection framework!
Like the previous article, we still can’t get the WebApplication instance on the dependency container… So we didn’t make any advancements specifically on accessing that.

But that’s mostly it! It’s not a terrible list of drawbacks, but the Autofac ContainerBuilder approach was not a silver bullet solution for us. So what did we get out of it? This video on Autofac will also help explain:

The Benefits of Autofac ContainerBuilder in ASP.NET Core

Pros and cons for everything we do! Now that we’ve seen the issues with Autofac ContainerBuilder in ASP.NET Core, it’s time to look at what advancements we got out of this:

We can still access the WebApplicationBuilder and IConfiguration instances, so that’s a comparable benefit to using the AutofacServiceProviderFactory approach.
We can get a very streamlined entry point to our program, which I really like to see. Container creation, registration, resolve your entry point method, and that’s all!
Minimal APIs work, but not with dependencies. Still, we can pre-resolve the dependencies the minimal APIs want and pass those in at the time of method registration. See the commented code!

More Inversion for Plugin-Based ASP.NET Routes?

We saw that we could register minimal APIs within an Autofac registration method, but unfortunately, we cannot resolve dependencies from the container directly on the minimal API call itself. We could go build a dedicated class like the following that handles route definitions with dependencies being resolved automatically:

internal sealed class WeatherForecastRoutes(
    DependencyA _dependencyA
    // FIXME: still can't depend on this because
    // we can't get the WebApplication
//, DependencyB _dependencyB 
  , DependencyC _dependencyC)
{
    private static readonly string[] _summaries = new[]
    {
        "Freezing", "Bracing", // ...
    };

    public WeatherForecast[] Forecast()
    {
        var forecast = Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                Random.Shared.Next(-20, 55),
                _summaries[Random.Shared.Next(_summaries.Length)]
            ))
            .ToArray();
        return forecast;
    }
}

The automatic resolution happens if we have this class AND the dependencies all on the same container. Then it’s just a matter of calling this code:

var weatherForecastRoutes = ctx.Resolve<WeatherForecastRoutes>();
app.MapGet("/weatherforecast2", weatherForecastRoutes.Forecast);

This still sucks a bit from a plugin perspective because we’d need to go resolve all of the route classes manually just to call the registration code like that — all stemming from the fact that these things can’t resolve their own access to the WebApplication instance.

But wait… What if we flip things around? What if we could resolve some interface like IRegisterRoutes and pass in the WebApplication instance?!

// NOTE: make sure to register WeatherForecastRouteRegistrar on the
// autofac container as IRegisterRoutes!

internal interface IRegisterRoutes
{
    void RegisterRoutes(WebApplication app);
}

internal sealed class WeatherForecastRouteRegistrar(
    WeatherForecastRoutes _weatherForecastRoutes) :
    IRegisterRoutes
{
    public void RegisterRoutes(WebApplication app)
    {
        app.MapGet("/weatherforecast2", _weatherForecastRoutes.Forecast);
    }
}

// TODO: add this to the autofac code where the 
// WebApplication instance is built:
foreach (var registrar in ctx.Resolve<IEnumerable<IRegisterRoutes>>())
{
    registrar.RegisterRoutes(app);
}

Now we don’t even need to care if the WebApplication instance is accessible to our plugins! Maybe the first version wasn’t so limiting after all? Maybe we’re onto something here… But the next article should explain this in more detail.

Wrapping Up Autofac ContainerBuilder in ASP.NET Core

In this article, I explored using an Autofac ContainerBuilder explicitly instead of using AutofacServiceProviderFactory as is normally suggested. We saw some similar benefits and drawbacks, but also a different set of things to consider. Each way can offer pros and cons depending on what you’re after in your application.

What was interesting was that if we’re trying to work towards plugins, we might not even need to access the WebApplication instance from our plugins at all! If we care about minimal APIs, this might still be limiting… but otherwise, we’re onto an interesting line of thinking!

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

AutofacServiceProviderFactory in ASP.NET Core – Problems With Dependency Injection (Part 1)

Dev Leader — Tue, 07 May 2024 14:00:00 +0000

We have plenty of awesome options for dependency injection when working in ASP.NET Core applications. For the most part, if you’re not building anything super complicated concerning your types or your software architecture, you can get by with the built-in IServiceCollection. However, we can use AutofacServiceProviderFactory in ASP.NET Core to make Autofac our dependency container of choice in our app!

In this article, I highlight how to use AutofacServiceProviderFactory in your ASP.NET Core application along with what you can and cannot do with it. Having many options for dependency injection means that we have many pros and cons to analyze!

This will be part of a series where I explore dependency resolution with Autofac inside of ASP.NET Core. I'll be sure to include the series below as the issues are published:

Dev Leader Weekly | Substack

weekly.devleader.ca

Dependency Injection: A Primer

What is Dependency Injection

Dependency Injection (DI) is a design pattern used in programming to make software systems easier to develop, test, and maintain. In C#, like in many other programming languages, dependency injection helps to decouple the components of your applications. Ideally, this leads to developing software that is more flexible and extensible.

Dependency Injection is about removing the hard-coded dependencies and making it possible to change them, either at runtime or compile time. This can be useful for many reasons, such as allowing a program to use different databases or testing components by replacing them with mock objects.

Consider a code example where we create an instance of a car with an engine:

public sealed class Car
{
    private readonly IEngine _engine;

    public Car()
    {
       // The Car class directly depends on the GasEngine class.
        _engine = new GasEngine();  
    }
}

We can instead “inject” the dependency via the constructor:

public sealed class Car
{
    private readonly IEngine _engine;

    // The engine is injected into the car via the constructor
    // so now there is no direct dependency on the Engine class,
    // but there is a dependency on the IEngine interface
    // which has nothing to do with the implementation
    public Car(IEngine engine)
    {
        _engine = engine;
    }
}

We can even use the idea of a “Dependency Container” that helps make this process seem a bit more magical by not requiring us to explicitly create instances of objects by passing in dependencies. Instead, the container allows us to resolve these dependencies. More on that in the next section!

What is Autofac?

Autofac is a popular inversion of control (IoC) container for .NET. It manages the dependencies between classes by injecting instances where needed, thereby facilitating a more modular and testable codebase. Autofac is used extensively in applications to implement the dependency injection pattern, allowing us to write cleaner, more maintainable code for the reasons I explained in the previous section.

There are other IoC containers to help us manage and resolve dependencies in our applications, including the built-in IServiceCollection, but Autofac is the one that I am most comfortable using. As .NET has evolved IServiceCollection has become more feature-rich, and with the gap in features between the two closing, Autofac is still one that I like using in my development.

What is the AutofacServiceProviderFactory in ASP.NET Core?

The AutofacServiceProviderFactory is a specific component in the Autofac library designed for integrating Autofac with the built-in dependency injection (DI) system in ASP.NET Core. Essentially, it acts as a bridge allowing you to use Autofac as the DI container instead of the default one provided by Microsoft.

I’ve written about this before in this article:

Autofac In ASP NET Core - How To Avoid This Debugging Nightmare

Learn how to use Autofac in ASP NET Core applications with only a couple of lines of code! Avoid this common problem when setting up dependency injection.

devleader.ca

Exploring A Sample ASP.NET Core Application

I wanted to make sure we had a common application to refer to when I get into more of the technical details of what we do and do not get with AutofacServiceProviderFactory. The following code is the sample weather app we get from Visual Studio when creating a new ASP.NET Core web API, but I’ve modified it slightly to showcase some of the behavior we get with AutofacServiceProviderFactory:

using Autofac;
using Autofac.Extensions.DependencyInjection;

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory(containerBuilder =>
{
    containerBuilder
        .RegisterInstance(builder)
        .SingleInstance();
    containerBuilder
        .Register(ctx => ctx.Resolve<WebApplicationBuilder>().Configuration)
        .SingleInstance();
    // FIXME: we can't do this because the WebApplicationBuilder
    // the WebApplicationBuilder is responsible for building the
    // WebApplication, so we can't do that manually just to add
    // it into the container
    //containerBuilder
    //    .Register(ctx =>
    //    {
    //        var app = ctx.Resolve<WebApplicationBuilder>().Build();
    //        app.UseHttpsRedirection();
    //        return app;
    //    })
    //    .SingleInstance();
    containerBuilder.RegisterType<DependencyA>().SingleInstance();
    containerBuilder.RegisterType<DependencyB>().SingleInstance();
    containerBuilder.RegisterType<DependencyC>().SingleInstance();
    //containerBuilder
    //    .RegisterBuildCallback(ctx =>
    //    {
    //        // FIXME: this was never registered
    //        var app = ctx.Resolve<WebApplication>();

    //        var summaries = new[]
    //        {
    //            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    //        };

    //        app.MapGet(
    //            "/weatherforecast",
    //            (
    //                [FromServices] DependencyA dependencyA // this will work
    //              , [FromServices] DependencyB dependencyB // FIXME: this will fail!!
    //              , [FromServices] DependencyC dependencyC // this will work
    //            ) =>
    //            {
    //                var forecast = Enumerable.Range(1, 5).Select(index =>
    //                    new WeatherForecast
    //                    (
    //                        DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
    //                        Random.Shared.Next(-20, 55),
    //                        summaries[Random.Shared.Next(summaries.Length)]
    //                    ))
    //                    .ToArray();
    //                return forecast;
    //            });
    //    });
}));

// FIXME: we can't get the WebApplication into the
// Autofac container, because it's already been built.
// this means if we have anything that wants to take a
// dependency on the WebApplication instance itself, we
// can't resolve it from the container.
var app = builder.Build();
app.UseHttpsRedirection();

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet(
    "/weatherforecast",
    (
        [FromServices] DependencyA dependencyA // this will work
      , [FromServices] DependencyB dependencyB // FIXME: this will fail!!
      , [FromServices] DependencyC dependencyC // this will work
    ) =>
    {
        var forecast = Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                Random.Shared.Next(-20, 55),
                summaries[Random.Shared.Next(summaries.Length)]
            ))
            .ToArray();
        return forecast;
    });

app.Run();

internal record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

internal sealed class DependencyA(
    WebApplicationBuilder _webApplicationBuilder);

internal sealed class DependencyB(
    Lazy<WebApplication> _webApplication);

internal sealed class DependencyC(
    IConfiguration _configuration);

You should note that I’ve modified the weather API itself to take in 3 dependencies that we want to resolve from the service list. [FromService] is in fact not required here, but it makes the error messages more clear if you were to go run this and want to understand where and why it fails.

But wait… why does it fail?! Keep on readin’ and follow along with this video on Autofac to find out more:

What Can We Get With AutofacServiceProviderFactory in ASP.NET Core?

Let’s start off with what we get from this setup because I do think that this is the typical path. To be clear, there’s nothing “wrong” with this approach, but you need to understand where dependencies are registered and resolved, and therefore what works with your container:

We have access to the WebApplicationBuilder on the Autofac ContainerBuilder instance. This allows us to have services depending on the app builder instance, which means we can have modules and/or plugins that want to setup information on the app builder or otherwise read state from the app builder.
With that said, we have access to the IConfiguration instance from the WebApplicationBuilder because it’s exposed on the web app builder itself.
We get the ability to resolve dependencies from the container that are defined directly on our minimal APIs! In the example I shared above, the dependency classes A through C are all types that can be resolved from the container automatically on the minimal API. There’s a catch for one of these which we’ll cover, but the point is their registrations can be seen by our minimal API.

In general, this is probably “good enough” for most situations if you just want to use Autofac for your ASP.NET Core application. However, this is limiting for the style of development that I like to do.

What’s Missing With AutofacServiceProviderFactory in ASP.NET Core?

Now that we’ve seen the goodness that we get, let’s discuss where there are some drawbacks. They’re essentially already highlighted in the code with FIXME comments, but it’s worth elaborating on them in more detail here. Again, this is not to suggest this is the “wrong” way to do it, just that you have some considerations to make:

The WebApplication instance is not something that we can resolve from the container. That is, if you ever want to have classes automatically resolve from the dependency container, they cannot take a dependency on WebApplication. This is because this instance is never registered onto the container and therefore cannot be automatically injected for us.
We can’t overcome this behavior by calling the Build() method manually on the WebApplicationBuilder inside of an Autofac registration. This is because the chain of registrations executes once we call Build() on the web application builder OUTSIDE of the container, which then handles the rest of the application being built. Said another way, this creates a bit of a circular dependency on the responsibilities that need to be handled.
Because we cannot resolve the WebApplication instance from the dependency container, we cannot create plugins that add their own routes to the application using the minimal API route registration syntax. If this is indeed possible to do, it would have to be using a different API and instance of a different type since the WebApplication instance is not accessible to us via the container.
Based on the above points, we cannot have dependencies on the routes like DependencyB in the example above. This is because this type has a dependency on WebApplication and the container simply does not know about it. In the future articles, you’ll see examples of this pattern coming up again so it’s worth mentioning in this article for reference.

Many of these are not a concern for folks building typical applications. However, as someone that builds mostly plugin architecture applications, this is very limiting for me!

Wrapping Up AutofacServiceProviderFactory in ASP.NET Core

In this article, I provided a brief overview of dependency injection and Autofac within ASP.NET Core. The primary takeaway was looking at what you do and do not get when using AutofacServiceProviderFactory in ASP.NET Core. While the limitations of this are minimized for the average application, this does not work well for a plugin architecture that wants to extend the API routes via plugins.

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

Break into Big Tech – My Journey from Startup to Microsoft

Dev Leader — Mon, 06 May 2024 14:00:00 +0000

Many software engineers set their sights on getting into big tech someday — It seems like the destination to end up at in one’s career. Now this of course isn’t universally true (nor should it be) but regardless, this is a goal for many. But is Big Tech all it’s cracked up to be? Are the stereotypes true? How the heck can someone get into these big companies?

In this article, I wanted to share with you my journey from working at startup companies all the way to being a Principal Software Engineering Manager at Microsoft. I’d love to share with you my interview experiences and my observations about what I value (and what I dislike) from startups and Big Tech.

Remember that your career journey is for you to own. Don’t try to copy someone else’s life, just learn from their experiences and take charge of your own. There’s no “wrong” path. Every path is unique.

I wrote this article for my good friend, Muhammad Waseem. He graciously offered to include my story in one of his newsletters, and I thought it would be such an awesome opportunity to share with his audience. My version of the article has been slightly adapted so I can share other relevant content for my own audience.

Muhammad, my friend, thank you for thinking about me!

Dev Leader Weekly | Substack

    <div class="color-secondary fs-s flex items-center">
        <img
          alt="favicon"
          class="c-embed__favicon m-0 mr-2 radius-0"
          src="proxy.php?url=https://substackcdn.com/image/fetch/$s_!zfLf!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4a947694-4ddd-4cc0-befa-83c12c83141d%2Ffavicon.ico"
          loading="lazy" />
      weekly.devleader.ca
    </div>
  </div>
</div>

My Background

I went to the University of Waterloo for computer engineering. While I didn’t like my classes at all, my 6 internships really solidified that I wanted to be in this industry. I spent my internships mostly at startups or small companies, but in completely different sectors so I could get different experiences.

Action: Take advantage of internships if you have the option!

Action: Use your internships to explore different domains and styles of companies!

My first real full-time software engineering job outside of university was a digital forensics company, now called Magnet Forensics, that was just starting out. This was the first time I started to have a good mix of autonomy and solid leadership mixed together because up until this point with work, I felt it hard to stay motivated in what I was doing for work.

This company had also taken a chance on me because they appreciated my existing skills and way of thinking but knew that I had zero experience in digital forensics. This was also going to be one of the first times in my career that I really noticed “Oh crap, I don’t know how to do any of this…” only to realize that after several months I was on my way to building expertise.

Action: Find companies and leadership that you align with. This may take time and experience in industry.

Action: Don’t be afraid to jump into new challenges. It’s the best way to learn.

I became a technical manager within several months of being at this company, which required my time was spent coding and managing. But this was all due to one critical software engineering skill that I think everyone should invest more time in: Communication.

Action: Work on your soft skills, not just your technical skills

Check out this video with Callie Buruchara for more details on why communication is so valuable:

Getting into Big Tech

This was one of my least favorite things I’ve done in the past few years. I find that I don’t do a great job selling myself to recruiters, and it feels unnatural to discuss my accomplishments. I needed to spend time updating my resume, which would include highlighting some of the biggest accomplishments in my career up to this point.

Action: Update your resume with high impact work. Pick relevant experiences to what you’re applying for.

I applied to some of the popular Big Tech companies and after several weeks had interviews that were lined up over a few weeks. In order to do this, I chose the route of going onto their career pages and going through the typical paths. I felt that I had solid work experience and based on historically what I had heard, it shouldn’t be too difficult to hear back.

Action: Most (if not all) companies have career pages that show you what they are actively hiring for. Use those.

Admittedly, the job market now is extremely different than it was when I was applying. You need to do everything you can to stand out. This may be an EXTREMELY difficult time to apply to Big Tech companies because of the volume of people trying — so I do not want you to be discouraged. It may not currently be in your favor, but that doesn’t mean you can’t focus on things that are in your control.

Action: Give some consideration to companies that aren’t Big Tech. They can offer incredible opportunities and there’s less competition.

Networking can be very powerful — so get in touch with recruiters as much as you can. You may have luck connecting with hiring managers, but from my personal experience, I have to direct every single person to the Microsoft careers page anyway.

Action: Always try to be networking! Build relationships with recruiters!

With that said, if you’re interested in Microsoft, my biggest advice would be to:

Use the Microsoft careers page to find jobs you’re interested in
Use LinkedIn to connect with recruiters
Use LinkedIn to connect with employees in the space

When you connect with the employees in the space DO NOT ask them to refer you. They don’t even know you, so they should not be referring you. Instead, see if you can get some time from them to learn about what it’s like working in that space. Build a true connection and use it as a learning opportunity.

Interviewing – Exactly What You’d Expect

I’m an engineering manager and I was applying for engineering manager roles… But you bet that I was still being interviewed like a Principal-level software engineer AND with management components added in. There are many similarities with how I would be interviewed compared to an individual contributor software engineer!

I was grinding LeetCode questions every day. Systems design questions. Behavioral questions. All of it. Every day for multiple hours. This was extreme for me because I hadn’t interviewed in nearly a DECADE. And every single big tech company was similar. Algorithms. Systems design. Behavioral. Much of what you read or hear online about this is spot on.

Action: Familiarize yourself with coding questions (LeetCode), distributed design questions, and project/behavioral questions

Action: Set aside time to practice as much as you can.

You need to be prepared to ask clarifying questions in the technical part. I hate these types of technical interview questions because I’ve seen people practice them like crazy, get hired, and then struggle as a developer because they just managed to train themselves well at interviewing. Something to keep in mind.

Action: When you’re practicing, try verbally asking clarifying questions and give yourself some constraints. You need to get good at this.

I only had one of my interviews, but that’s okay. It can happen to anyone. Ultimately, I chose Microsoft because everything I had heard about the work culture was aligned with what I wanted.

These two livestreams focus on getting noticed and preparing for interviews, and I think they’re very valuable to go alongside this:

And the second one focusing on the interview process itself, here:

Big Tech – Final Thoughts

I want to close out this article by bringing back what I said in the introduction:

There’s no “wrong” path. Every path is unique.

My philosophy in software engineering is that there are pros and cons to everything. Where we work is no different. Some similarities and differences from my own experiences:

You might be working on platforms and/or internal systems compared to user-facing offerings. Figure out what you prefer!
You can find a lot of meaning in what you’re doing at big or small companies, but it’s often easier to feel that you have a bigger relative impact at a smaller company
How much autonomy you have can vary from company to company — usually smaller companies there’s more flexibility and autonomy because there’s less bureaucracy built in.
From team to team, or company to company, you might notice the rate at which you can ship features/fixes is different. This can be a VERY big quality of life to consider as a software engineer.
Big tech has very ironed out career ladders whereas startups it can be more chaotic — but your level vs how much REAL experience you gain are not always aligned.
How you interview for Big Tech is well documented but for startups and smaller companies the interview processes may look quite different

There are many more things to compare — but I want you to know that many people will value these things differently. What we value in life changes as well. I’m very respectful of my work-life time boundaries now. No more 16-hour days.

But a question I’d leave you with is… What do you truly value in your career? In your life?

Dev Leader Weekly | Substack

    <div class="color-secondary fs-s flex items-center">
        <img
          alt="favicon"
          class="c-embed__favicon m-0 mr-2 radius-0"
          src="proxy.php?url=https://substackcdn.com/image/fetch/$s_!zfLf!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4a947694-4ddd-4cc0-befa-83c12c83141d%2Ffavicon.ico"
          loading="lazy" />
      weekly.devleader.ca
    </div>
  </div>
</div>

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

MudBlazor with Blazor Interactive SSR – What You Need To Know

Dev Leader — Wed, 01 May 2024 16:00:00 +0000

This is yet another selfish guide! I’m writing this to help my future self with having MudBlazor with Blazor interactive SSR working within a new project. Of course, the positive side effect is that you get to benefit from this guide too! Maybe it wasn’t so selfish after all, right?!

This guide will focus on getting MudBlazor with Blazor interactive SSR set up and configured in a new Blazor project in dotnet 8. This is hopefully applicable for future versions of dotnet, as long as this doesn’t change behavior dramatically. Following this guide will ideally prevent you from running into all sorts of fun Blazor render mode issues.

What is MudBlazor?

Like with all user-interface tech stacks, it’s very common to have reusable control libraries. One such control library is MudBlazor. In their own words:

MudBlazor is an ambitious Material Design component framework for Blazor with an emphasis on ease of use and clear structure. It is perfect for .NET developers who want to rapidly build web applications without having to struggle with CSS and Javascript. MudBlazor, being written entirely in C#, empowers you to adapt, fix or extend the framework. There are plenty of examples in the documentation, which makes understanding and learning MudBlazor very easy.

Originally, I went looking for MudBlazor because I wanted to develop more of a customized list view in my application. However, the default controls didn’t seem like they did a great job for what I wanted. I’ve spent well over a decade building user interface applications in WinForms and WPF, so I’m no stranger to control libraries. But that’s exactly why I figured I shouldn’t need to roll my own — someone else has got this covered!

Dev Leader Weekly | Substack

weekly.devleader.ca

What Are Blazor Render Modes?

Blazor Web Apps use different render modes to control where and how components are rendered. The modes include:

Static Server: Renders components on the server without interactivity.
Interactive Server: Also renders on the server but allows interactivity using Blazor Server.
Interactive WebAssembly: Renders interactively on the client-side using Blazor WebAssembly.
Interactive Auto: Starts with server-side rendering and shifts to client-side on subsequent interactions after the Blazor bundle is downloaded.

These render modes are set using the @rendermode directive in the component’s code. More details on configuring and applying these modes can be found on the Microsoft documentation page.

This article is not focusing on which render mode is better or worse, nor will I be doing an in-depth analysis. I wanted to provide this context so that you can see we’ll be using Interactive Server render mode to get Blazor server-side rendering (SSR) with our app.

With that said, the distinction between client-side and server-side rendering is important for performance and interactivity:

Client-side rendering (WebAssembly mode): Components are executed and rendered directly in the user’s browser using WebAssembly. This mode offers a richer, more interactive experience as it doesn’t require a round-trip to the server for UI updates. However, it involves a larger initial download and more resource consumption on the client side.
Server-side rendering (Server mode): Components are executed and rendered on the server. The rendered UI is delivered as static HTML to the client’s browser, and interactivity is maintained through a SignalR connection that manages event handling and UI updates. This mode minimizes client-side resources since the client doesn’t execute the component logic, but it relies heavily on the network connection to the server, which can impact responsiveness and user experience.

Each mode has its use case depending on the application’s needs for performance, scalability, and complexity. The focus of this article is on a server rendering mode not because I claim it’s superior, but because it’s what I needed for my own development purposes.

How to Get MudBlazor with Blazor Interactive SSR Working

The following sections will give you the step-by-step actions required to get MudBlazor with Blazor interactive SSR working. You can follow along with this MudBlazor video tutorial as well:

New Blazor Project Setup

The first thing that we need to do is create our project in Visual Studio. To do that, we’re going to select the “Blazor Web App” project template from Visual Studio.

Next, we’ll want to ensure we select the correct render mode. We want it to be “Server” as we see in the screenshot below.

The other options are of course up to you. If indeed you need another render mode, then the rest of this guide is not for you as we’re strictly focused on server-side render (SSR) mode. Remember, the reason that I wrote this is that I thought I had to use the dual mode for supporting MudBlazor because the instructions I received didn’t seem to line up exactly.

Configuring Mud Blazor with Blazor Interactive SSR

Now that we have our project setup, it’s time to get going with setting up MudBlazor. I should note that they DO have instructions that you can follow on their GitHub — so if you’re getting stuck with my guide, go read theirs. However, I followed theirs the first time and still ran into some fun hiccups because I didn’t know what project to create. Not the fault of MudBlazor nor the fault of Blazor; Just Nick’s fault.

Step one will be getting the nuget package installed:

dotnet add package MudBlazor

And once installed, we only have a couple of spots to go update! Starting off, to make the MudBlazor accessible in our razor files by default, we can add the following to _Imports.razor:

@using MudBlazor

Slightly separate guidance from what they list on their GitHub, but we can place the following code in the <head> block of App.razor

<link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700&display=swap" rel="stylesheet" />
<link href="_content/MudBlazor/MudBlazor.min.css" rel="stylesheet" />
<MudThemeProvider/>
<MudDialogProvider/>
<MudSnackbarProvider/>

Next, we add the following to the <body> block of the same file:

<script src="_content/MudBlazor/MudBlazor.min.js"></script>

And finally, we need these two lines into program.cs to enable dependency injection for MudBlazor:

using MudBlazor.Services;
builder.Services.AddMudServices();

Using MudBlazor with Blazor Interactive SSR

Now that we’re all configured, we can use MudBlazor! I started off with the sample application to prove this all out, so I figured I’d change the default “counter” page to use MudBlazor controls.

Here’s the change to that code that I made:

@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<MudText Typo="Typo.h6">
    Current count: @currentCount
</MudText>
<MudButton
    Variant="Variant.Filled" 
    Color="Color.Primary" 
    OnClick="ButtonOnClick">
    Click Me!
</MudButton>

@code 
{
    private int currentCount = 0;

    void ButtonOnClick()
    {
        currentCount++;
    }
}

And if you want to see it in action:

Wrapping Up MudBlazor with Blazor Interactive SSR

This was just a simple guide to get you up and running using MudBlazor with Blazor interactive SSR! If you start off with the Blazor server-side rendering project instead of the dual mode where it’s auto server and webassembly, you’ll have a much better time. However, maybe you know what you’re doing significantly better than me and you’re ready to jump into the dual render-mode support — but I certainly was not!

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

Try Catch in C#: The Basics You Need to Know

Dev Leader — Tue, 30 Apr 2024 16:00:00 +0000

As much as we’d like to write perfect programs, there’s going to be a point where you need to think about handling error cases in your C# applications. That’s why you’re here: for an introduction to try catch in C#!

In this article, I’ll explain the very basics of how to structure try catch blocks and what each block is responsible for. The code is simple and aims to help explain some of the basic concepts to beginners working in C#. If that sounds like you, read on!

Overview of Exception Handling in CSharp

Let’s face it: there are going to be exceptions in our C# applications and services at some point. We hate to admit it, but it’s a reality that we have to understand how to work with.

Exception handling in C# is done by using what’s called a try/catch block. So try catch in C# is how we set up code to have some type of protection and define the logic for how we want to deal with those exceptions.

The following sections will explain the two main pieces, try and catch, and later on we’ll see an extra third component we can add to the try catch blocks we create in C#. You can follow along with this video on how to handle exceptions with try/catch blocks in C# as well:

The Try Block

The try block is the first important part of our exception handling that we need to look at. It serves the purpose of enclosing the code that might potentially throw an exception. By placing the code within a try block, we ensure that any exceptions that occur can be caught and handled appropriately — but it’s not handled by this block, this block just tells us what will get handled.

The try block is structured using the keyword “try”, followed by a set of curly braces that contain the code we want to monitor for exceptions. This code is often referred to as the “protected code”, as it is within this block that we anticipate will be potentially throwing exceptions. Here’s an example of a try block in C#:

try
{
    // Code that might throw an exception
    int result = Divide(10, 0);
    Console.WriteLine("The result is: " + result);
}

In this example, we have a function called “Divide” that takes two integers as parameters and attempts to perform a division operation. However, if the second parameter is zero, it will throw a divide by zero exception. By enclosing this code within a try block, we can catch and handle this exception appropriately — but we need another block to actually handle it! And that’s where we’re headed in the next section!

The Catch Block

The main purpose of the catch block is to provide a mechanism for handling exceptions gracefully. The try block allows us to define what we want to protect, and the catch block allows us to define what we’ll handle and how we’ll handle it.

When an exception is thrown, the catch block allows us to specify the actions to be taken in response to that exception. These actions could include logging the exception, displaying an error message to the user, or taking any other necessary corrective measures. The choice is yours!

To catch a specific type of exception, we use the catch keyword followed by the exception type we want to handle. This allows us to handle different exceptions in different ways, tailoring our response based on the specific type of exception.

Here’s an example of a catch block that handles a specific exception type, in this case, the DivideByZeroException:

try
{
    int result = 10 / 0; // This will throw a DivideByZeroException
}
catch (DivideByZeroException ex)
{
    Console.WriteLine("An error occurred: " + ex.Message);
}

In this example, the code within the try block attempts to divide the number 10 by 0, which will result in a DivideByZeroException. The catch block catches this exception and executes the code within its block, which in this case, simply writes an error message to the console, displaying the message provided by the exception.

You can also use a base exception class or omit the exception portion altogether to catch all (well, almost all) exceptions:

try
{
}
catch (Exception ex)
{
    // this will catch all catchable exceptions
}

// OR

try
{
}
catch
{
    // note that we don't have an exception instance in this case!
}

Dev Leader Weekly | Substack

weekly.devleader.ca

Handling Multiple Exceptions

If one exception can be thrown from a called piece of code, odds are that many can. As a result, it’s common to encounter scenarios where multiple types of exceptions can occur within a single try block. These exceptions may arise due to different errors or exceptional situations that need to be handled appropriately. In this section, I’ll discuss how to handle multiple exceptions by using either multiple catch blocks or a single catch block with multiple exception types. Let’s see how!

Multiple Catch Blocks Approach

When handling multiple exceptions, one approach is to use multiple catch blocks. Each catch block is responsible for handling a specific type of exception. By using this approach, you can specify separate code blocks to handle different exceptions based on their respective types.

Here is an example that demonstrates the multiple catch blocks approach:

try
{
    // Code that may throw exceptions
}
catch (ArgumentNullException ex)
{
    // Handle ArgumentNullException
}
catch (DivideByZeroException ex)
{
    // Handle DivideByZeroException
}
catch (FormatException ex)
{
    // Handle FormatException
}

In the above example, the catch block following the try block will catch and handle any ArgumentNullException that occurs. Similarly, the catch blocks for DivideByZeroException and FormatException will handle their respective exceptions.

Single Catch Block with When Filtering

Another approach for handling multiple exceptions is to use a single catch block that can handle multiple exception types. This approach can be useful when you want to handle multiple exceptions in the same way without writing separate catch blocks for each one.

Here is an example that demonstrates the single catch block approach:

try
{
    // Code that may throw exceptions
}
catch (Exception ex) when // look at this fancy keyword!
(
    ex is ArgumentNullException ||
    ex is DivideByZeroException || 
    ex is FormatException
)
{
    // Handle ArgumentNullException, DivideByZeroException, and FormatException
}

In the above example, the catch block will handle any ArgumentNullException, DivideByZeroException, or FormatException that occurs within the try block. This is because we’ve placed a filter onto the exception handler using the when keyword!

I should note that you can do more filtering than just type-checking with the when keyword. You’re able to examine the different properties for the exception instance and create filters accordingly. If you needed to filter by a certain exception message or error code on a particular exception type, you can do that with the when keyword.

The Finally Block

The finally block in C# is used to define a section of code that will always be executed, regardless of whether an exception occurred or not. Its purpose is to ensure that certain tasks, such as releasing resources or performing cleanup operations, are always carried out, regardless of the outcome of the try block.

The finally block is executed after the try and catch blocks, whether an exception is thrown or not. It’s written with the keyword “finally” followed by a set of curly braces {}. Any code within these braces will be executed immediately after the catch block finishes.

Finally Block Use Case

One common use case for the finally block is to release any resources that were acquired within the try block. This could include closing file handles, database connections, network sockets, or any other resource that needs to be freed up. By placing the cleanup code in the finally block, you can ensure that it will be executed even if an exception is thrown in the try block.

Here is an example that demonstrates the use of the finally block for resource cleanup:

try
{
    // Code that could potentially throw an exception
    // Acquiring resources
    // Performing operations
}
catch(Exception ex)
{
    // Exception handling code
    // Logging or displaying error messages
}
finally
{
    // Code to release resources
    // Closing file handles, database connections, etc.
}

In this example, if an exception is thrown in the try block, the program flow will jump to the catch block to handle the exception. However, regardless of whether an exception is thrown or not, the code within the finally block will always be executed afterwards. This ensures that any acquired resources are properly released, preventing resource leaks and maintaining the stability of the program.

Alternative to Finally Blocks: IDisposable

The finally block that we can use when it comes to try catch in C# is very helpful — but try/catch syntax is already a bit clunky to begin with. It’s a common pattern that we want to clean up resources and if we’re being defensive, we want to make sure that we clean them up even when we have error scenarios.

We can use the IDisposable interface and a using block to help support this. So instead of requiring a finally block to clean things up, you could have code inside of a Dispose() method on the object that implements IDisposable. The code would be simplified to this:

public class MyClass : IDisposable
{
    public void Dispose()
    {
        // TODO: do your cleanup... same 
        // stuff that you might have wanted
        // in your finally block!
    }
}

using (Myclass myClass = new())
{
    // do stuff with myClass
}

// dispose runs after we leave the block

This is a lot less clunky, in my opinion than a whole try/finally block to support cleanup — but of course, this will not catch errors just ensure you can still run cleanup code. We can simplify this further with implicit using now where the Dispose() method runs when the variable goes out of scope:

public void SomeMethod()
{
    // implicit using...
    using Myclass myClass = new();

    // do stuff with myClass

    // dispose runs at the end here since the variable goes out of scope
}

Considerations for Try Catch in CSharp

Now that you’ve seen several different ways we can use try catch in C# as well as some different use cases, let’s talk about some considerations. We’ve seen the tools we have to use, but some guidance on using them appropriately seems fitting:

Is it REALLY exceptional?: Consider if the exception you’re catching is truly exceptional. Unfortunately, many libraries and programs have exceptions thrown that are not truly exceptional behavior for an application. This can complicate logic and slow things down. So if you don’t need to throw them, don’t. But you also might need to catch them because you don’t want the entire program to terminate.
Catch All vs Catch Specific: Many people frown upon using a try/catch block that attempts to catch all exceptions. The argument is that you could be masking an underlying problem with a blanket handler. However, there are absolutely situations (many of which I’ve used in a professional setting) where we’ve been better off with a catch-all. Some things we are calling are outside of our control with respect to the errors they throw, and if you don’t need your entire application or service to end… then you need to handle them.
Proper Cleanup: Consider if you need something like a finally block or to use the dispose pattern. Remember, using the dispose pattern can help clean up the code but alone it does not prevent exceptions from being thrown.
Logging & Telemetry: You’ll not only want to understand recovery patterns when using try catch in C#, but you should consider if you need to be doing something with this error information. If you have a live service running in production, there are many cases where you’ll want to know what’s going wrong or what can be improved. Logging and telemetry can help!

Wrapping Up Try Catch in CSharp

Now you’ve had a chance to see the basics of try catch in C#! I’ve aimed to help familiarize you with the purpose of the different blocks, and introduced the finally block as well! With some basic code examples to refer to along with some extra considerations to keep in mind when programming, you’re all set to start catching exceptions in your code!

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

How to Convert a String to Byte Array in C#: Encoding and Decoding Simplified

Dev Leader — Mon, 29 Apr 2024 16:00:00 +0000

In programming, it’s very common that we need to go between strings and bytes. Humans read strings. Computers read bytes. As a result, it’s important for us dotnet developers to understand how to convert a string to a byte array in C#. We accomplish this through a process called encoding and decoding to go back and forth between the two.

In this article, I’ll provide you code examples to be able to convert a string to a byte array in C# — and back again! You’ll also learn about some of the nuances of character encodings to look out for!

Encoding and Decoding in CSharp

If we want to convert a string to a byte array — or go the other way — we need to understand the concept of encoding and decoding. In software engineering, encoding refers to the process of transforming a string into a sequence of bytes, while decoding involves the reverse process of transforming bytes back into a string. Simple, right?

Remember that strings are a sequence of characters, and the concept of a character makes a lot of sense to us as readers, but computers understand bytes. Characters themselves can be represented by numbers in computers so when we want to work with strings at a lower level, such as when sending data over a network or storing it in a file, we need to convert the string into a byte array.

Encoding comes into play when converting strings to byte arrays. It determines how the characters in the string are represented as bytes. The encoding scheme defines the mapping between characters and their byte representations. Common encoding schemes include UTF-8, UTF-16, ASCII, and Unicode.

Choosing the correct encoding is important because different encoding schemes support different sets of characters. For example, ASCII only supports the basic English alphabet (with a few more characters), while UTF-8 and UTF-16 are capable of representing characters from multiple languages and scripts. More on this later though since I know you’re eager for some code!

Dev Leader Weekly | Substack

weekly.devleader.ca

Choosing an Encoding for String to Byte Array Conversion

When converting strings to byte arrays in C#, one of the most important things to consider is character encoding. Character encoding determines the mapping between characters and byte values, and if you’re considering transforming data one way then you may want to put some thought into how to transform it back!

What’s that supposed to mean? Well, if we use a data transform — let’s say taking a string and transforming it to bytes with an ASCII encoding — if there is not a mapping of a particular character to a byte representation we lose that data in the result. Now what happens if you want to go the other way and get your byte array back to a string?

Data is missing!

In C#, there are various encodings available, including ASCII, UTF-8, and UTF-16, each with its specific characteristics and usage scenarios. Let’s explore these encodings and see how they can be used for string to byte array conversion.

ASCII Encoding

ASCII encoding represents characters using 7 bits, allowing for a total of 128 different characters. It’s primarily suitable for handling basic English characters and is more space-efficient compared to other encodings. Here’s an example of converting a string to a byte array using ASCII encoding:

string text = "Hello, World!";
byte[] asciiBytes = Encoding.ASCII.GetBytes(text);

In many modern applications, ASCII may not be what you’re after. This is especially true if you have users across the globe in locales that are not English. That’s not to say that ASCII cannot be used, but you’ll want to be careful about what data you ASCII encode so as to not lose information during the encoding transform.

So keep in mind that the ASCII character set represents characters using a 7-bit encoding scheme, allowing for a total of 128 unique characters. However, with the growing need for internationalization and multilingual support, ASCII alone is insufficient to represent all characters effectively.

Good thing we have some other options coming right up!

UTF-8 Encoding

UTF-8 encoding is a variable-length encoding scheme that can represent any Unicode character. It’s widely used for encoding text in various languages and is backward compatible with ASCII. It uses fewer bytes for representing ASCII characters but may require more bytes for non-ASCII characters. Here’s an example of converting a string to a byte array using UTF-8 encoding:

string text = "Привет, мир!";
byte[] utf8Bytes = Encoding.UTF8.GetBytes(text);

UTF-16 Encoding

UTF-16 encoding represents characters using either 2 or 4 bytes, making it capable of representing any Unicode character. It’s commonly used by applications that need to handle multilingual text or when interoperability with other systems is required. The encoding can be little-endian or big-endian, with the former being more prevalent. Here’s an example of converting a string to a byte array using UTF-16 encoding:

string text = "こんにちは、世界！";
byte[] utf16Bytes = Encoding.Unicode.GetBytes(text);

UTF-8 Encoding vs UTF-16 Encoding – What’s The Difference?

Each of these encodings is variable width, and their size gives them different characteristics when we consider different alphabets.

Starting with UTF-8, it’s variable-width and backward-compatible with ASCII. In this encoding:

ASCII characters, which are on the range U+0000 to U+007F, take only 1 byte.
In the next range, code points U+0080 to U+07FF take twice as much space at 2 bytes each.
Code points U+0800 to U+FFFF take one more byte, bringing us up to 3 bytes
And finally, code points U+10000 to U+10FFFF take 4 bytes.

This can be very effective for English text because those characters will take up minimal space. However, when it comes to Asian text it’s not ideal for the exact opposite reason.

Because UTF-16 has code points from U+0000 to U+FFFF take 2 bytes and code points U+10000 to U+10FFFF are double that at 4 bytes, it’s not-so-great for English. It does happen to be better suited for Asian characters though.

There’s even UTF-32 encoding! This is a fixed-width encoding where all of the code points take four bytes — unlike the others I’ve mentioned which are dynamic in size. This can use much more storage than the other encodings, but because of its simplicity can be much faster to operate on.

Give some consideration to the alphabets you’ll need to support primarily!

Best Practices for String to Byte Array Conversion

When converting strings to byte arrays in C#, it’s important to follow best practices to ensure efficiency and reliability. In this section, I’ll discuss some key best practices that you should keep in mind when performing string to byte array conversions.

Error Handling and Validation

When working with encodings, it’s important to handle potential errors and validate your data to prevent unexpected behavior in your code. Ideally, you structure the flow of your application such that you know what kind of data you’re dealing with. If you can write code to avoid errors in the first place, this is preferred!

We don’t want to have to rely on this but sometimes it’s outside of our control — handling errors is by using try-catch blocks. By encapsulating the conversion code within a try block, you can catch any exceptions that may occur during the conversion process and handle them gracefully. If you don’t have control over the source of the input data, this is something you might need to do for safety.

Encoding Selection

C# provides several encoding options for converting strings to byte arrays, such as UTF-8, UTF-16, ASCII, and more. It’s important to select the appropriate encoding based on the specific requirements of your application. Consider factors such as character sets, compatibility with other systems, and performance implications when choosing the encoding.

// Example of encoding selection
string inputString = "Hello, World!";
byte[] encodedBytes = Encoding.UTF8.GetBytes(inputString);

Just like we saw in the previous examples, after the Encoding class we get to pick the static property holding the encoding instance. If we need to select one to pass around as a variable and parameter, you can absolutely store it in a dedicated encoding reference:

Encoding selectedEncoding = Encoding.UTF8;
SomeMethod("Hello World!", selectedEncoding);

Selecting the wrong encoding can have big consequences for your application! This is especially true if you save data with an encoding that will lose data resolution and you can’t reverse it… so put some care into this!

Now You Know How to Convert a String to Byte Array in CSharp!

You’re a pro now with encoding and decoding! Well, maybe not a full-on expert… but you have the basics put in front of you and some guidelines to work with. That’s a pretty good start.

Remember to select the right encoding for the situation you’re dealing with. Keep in mind that you can potentially lose data resolution when using the wrong encoding, and as a result, lose data forever!

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

API Gateways in Zuplo – Creating an ASCII Art API

Dev Leader — Wed, 24 Apr 2024 16:00:00 +0000

I was approached by Adrian Machado, an employee at Zuplo, for a problem I didn’t even know I had — yet. When I jumped on the call with him to walk through their product offering, I remember thinking “Holy crap — this is for me”. You see, I’m more than happy to code up solutions for things and build systems, but there’s a class of work that I REALLY don’t want to have to deal with. And every single time I work on a new project/product/service that’s web-facing this stuff comes up every time… And API Gateways in Zuplo I feel like make this infinitely more easy to navigate.

In this article, I’m going to share with you my experiences with onboarding my ASCII art generator onto an API Gateway in Zuplo. To cover all of the capabilities, I’ll need to spread this out over several articles, but this will explain how I achieved routing traffic through the gateway!

Full disclosure: Zuplo sponsored the article for my website, but I wanted to share it on additional platforms because I genuinely enjoyed working with it.

What is Zuplo?

Zuplo is an API Management platform that places an emphasis on the Developer Experience (DevEx) for building web APIs. Zuplo‘s goal is to build a platform to make it fast and straightforward to build awesome APIs. Directly from them:

We are trying to build a platform to make it fast and straightforward for developers to deliver a Stripe-level API experience to their users.

Zuplo

It’s one thing to get the logic for an API implemented — which is where historically I shine pretty well. But building out a fully operational API that you can have users and other services relying on isn’t a trivial process — especially once you consider monetizing it. You’ll need to factor in:

Documentation
Testing
Deployments
Monitoring

Nevermind all of the other things regarding access and protection like authentication and rate limiting… The list goes on. But Zuplo aims to try and get you focused on what matters (what your API needs to do) so they can handle the rest.

What is an API Gateway?

An API Gateway is a component in many modern distributed systems, particularly — but not exclusively — in microservices architectures. It acts like the bouncer at the club of your backend services, managing and directing incoming API calls from clients to various backend services. I like to think of it like “the front door” — although it does more than that.

So… What exactly does that mean?

When you have a bunch of services, each handling a specific piece of functionality (like billing, user profiles, inventory, etc.), it’s not always ideal to have everyone on the outside of your system hitting them directly. And now you might ask, “Well… Why?”, and that’s because managing all those direct connections can get messy.

Think about handling authentication, rate limiting, and data transformation for each service individually. That’s where the API Gateway comes into play. These can simplify a lot of the interactions between services as well as callers to your services on the outside. The API Gateway simplifies client interactions with your service or services — like my front door analogy — providing a single entry point for all client requests.

What Does Zuplo Offer for API Gateways?

While this article will not be covering all of these in detail (c’mon, I need to spread out the juicy details a little bit…), here are some of the core offerings from Zuplo with respect to API gateways:

API Key Management: Zuplo allows you to add API key-based authentication to your APIs rapidly — literally in a few minutes.
Rate Limiting and Throttling: Zuplo’s rate-limiting functionality can work great when paired with their other features, like the API keys I just mentioned. They have ready-to-go limiting based on keys or JWTs but they also allow you to customize this further in code.
Routing and Forwarding: With Zuplo, you can handle the request right at the edge server using the code you write in Zuplo itself, you can run a lambda, or you can forward/rewrite the request!

Yes, sure, these are all things that Zuplo didn’t invent, but using these within Zuplo means you don’t have to go build them from scratch — and they make it ridiculously easy for you to use.

But what else does their platform do for you if you’re developing APIs?

Full Policy Library: It’s actually almost ridiculous how many out-of-the-box policies are provided for what you might want to do with your API. Think of these almost like a “middleware” that you can insert inbound and outbound on your API as building blocks — which means you don’t need to go build this stuff from scratch!
Documentation Generation: Right in the portal you’re able to configure and define documentation for your APIs, but all of the heavy lifting is done for you. Simply make your changes, customize what you want in your documentation, save and it’s automatically deployed to an easily consumable API documentation portal.
Automatic Rapid Deployments: During my demo, I was blown away by just making changes in the portal, and pressing save, and everything is instantly deployed and live. Honestly, the API developer experience feels ridiculously smooth for these features because of how simple and quick these things become.

ASCII Art Generator Via Zuplo

In the following sections, I’ll walk you through how I went from my desktop C# ASCII art generator to an API endpoint on Zuplo that hits my server in the cloud! You can also watch the companion video where I explain how I got my ASCII art generator API setup with an API gateway:

Why an ASCII Art Generator?

In 2023 I wrote an article on ASCII art and how to create an ASCII art generator in C#. I thought this was a fun little project, but it ended up being one of the articles that still — to this very day — drives a lot of traffic to my website. Even the YouTube video, which I’ll embed right after, has a thumbnail that still ranks quite high on Google!

This project was fun to build, drove traffic to my site, and was quite self-contained with respect to the amount and complexity of code. I figured that this would be a perfect candidate to build an API for.

But back when I first started getting traction for this content, I really didn’t want to be bothered with building out all of the rate-limiting, auth, etc… These are all things I know can be done when building ASP.NET core applications, but honestly, I couldn’t be bothered to invest the time.

But Zuplo changes that for me because the reality is I don’t have to invest much time at all! I mean this candidly: When Adrian from Zuploo got on the call with me, I didn’t even realize I had a problem that Zuplo would solve until he started walking me through their offering. I realized literally while on the call that Zuplo is what could allow me to skip over the parts of API development that I truly just don’t want to work on!

Initial Challenges — Nick’s Fault!

Thanks to the code being very simple for ASCII art generation, I figured I’d just port everything over directly to Zuplo! One of the very cool features of Zuplo is that I can define a route’s logic RIGHT in Zuplo using Typescript:

It’s worth noting that just by doing that configuration, Zuplo will automatically go add the associated Typescript file for you:

So this is TOTALLY awesome — especially for Typescript folks. But here’s where my challenge started.

Because I’m dealing with images, I need a package that handle different image formats. In order to get this set up in Zuplo, which is very doable, I have to understand a little bit more about building things in Typescript. Directly from their documentation:

Additionally, you can also bundle custom modules inside of your own project. This process is does require some knowledge of node and npm, but it allows you to use any module or version of the module. To learn how to bundle your own modules, see the sample Custom Modules on Github.

Zuplo

So for those of you who work with Node and you’re familiar with all of this stuff — Lucky for you, this should be trivial! For me, the easiest thing was to pivot.

While it would be super cool to have my API running completely on Zuplo‘s edge servers, I already have machines up hosted in the cloud. It was time to turn to Azure!

Deploying A Web Service to Azure

Fortunately for me, I already had a multi-purpose API server set up in Azure that I use for several of my other projects. It’s completely plugin-based, so any time I’d like to extend functionality and add new feature sets, I just add new plugins!

In this case, it was almost just as simple as copying the example code that I had from my previous article on building an ASCII art generator in C# over to a new plugin namespace in my existing web app. One of the small steps I needed to take was putting the web API in place for the first time though!

This was an interesting opportunity though because I wasn’t writing an API in C# for end-users to hit… I was writing an API for Zuplo to hit! While I don’t want to write a crappy API right at my origin, I figured that at least Zuplo would allow me to build transforms to my API if needed.

Here’s a quick peek at what my code looks like on the server side:

using Autofac;
using Microsoft.AspNetCore.Mvc;

internal sealed class AsciiModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .RegisterType<AsciiArtFromUrlRequestValidator>()
            .SingleInstance();
        builder
            .RegisterType<AsciiArtGenerator>()
            .AsImplementedInterfaces()
            .SingleInstance();
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();

                var routeGroup = app.MapGroup("ascii");

                // FIXME: correct the container ordering-issue to inject properly
                var imageSourceFactory = ctx.Resolve<IImageSourceFactory>();
                var asciiArtGenerator = ctx.Resolve<IAsciiArtGenerator>();
                var asciiArtFromUrlRequestValidator = ctx.Resolve<AsciiArtFromUrlRequestValidator>();

                routeGroup.MapPost(
                    "/url",
                    async (
                        [FromBody] AsciiArtFromUrlRequest request,
                        IHttpClientFactory httpClientFactory,
                        CancellationToken cancellationToken) =>
                    {
                        if (!asciiArtFromUrlRequestValidator.Validate(request).IsValid)
                        {
                            return Results.BadRequest();
                        }

                        // FIXME: introduce further validations
                        Stream imageStream;
                        try
                        {
                            using var client = httpClientFactory.CreateClient();
                            imageStream = await client
                                .GetStreamAsync(request.ImageUrl, cancellationToken)
                                .ConfigureAwait(false);
                        }
                        catch
                        {
                            return Results.Problem();
                        }

                        using var imageSource = imageSourceFactory.CreateFromStream(imageStream);
                        var art = asciiArtGenerator.GenerateAsciiArtFromImage(
                            imageSource,
                            AsciiGenerationOptions.Default with
                            {
                                ScaleDownFactor = request.ScaleDownFactor,
                                HorizontalStretchFactor = request.HorizontalStretchFactor
                            });

                        AsciiArtResponse response = new(
                            art.Art,
                            art.Width,
                            art.Height);
                        return Results.Ok(response);
                    });

                return new RouteRegistrationDependencyMarker();
            })
            .SingleInstance();
    }
}

The code above gives us a POST route on the server that’s essentially just <server>/ascii/url, which takes a URL that my server can work with. I’d like to opt for switching over to an API where image bytes can be uploaded, but this seemed like an easy way to get started.

This isn’t going to be a full tutorial on deploying to Azure by any means but using “App Service” within Azure, I have full git-actions integration so that every time I make a commit, my application is deployed.

My Zuplo API is Alive!

Now that my own server is deployed in Azure, it’s time to rock and roll! This is where the simplicity of Zuplo really shines. Here’s the new route I added with URL rewriting:

I literally only had to press the save button (not shown in the screenshot) and within about 3 seconds the test button became live for me to use. Directly from the browser, much like using Postman, I was able to send a test URL and get back some fancy ASCII art. I’ll skip the screenshot because Zuplo isn’t optimized to try rendering ASCII art for us — I know, I know… a critical flaw!

Security Between Azure and Zuplo API Gateway

As I was putting all of this together, I said “Wait a sec! My server is still exposed to the Internet without ANY protection in front of it!”. This is realistically not a huge problem at the moment because nobody even knows the address of it. But still — I wanted to do this properly.

I reached out to Zuplo and asked “Hey, what’s your recommended way to do this?”, just in case they had more magic up their sleeves. They politely explained and mentioned that’s also covered in the example getting started documentation. And obviously, I read that ahead of time… we ALWAYS read the docs… right?

RIGHT?

After reading the documentation, I had one little change to make on my server, which was using a custom middleware for adding API authentication. By the way, if I haven’t sold you on plugin architecture before, API key authentication for my server was just another plugin:

internal sealed class ApiKeyModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();
                var config = ctx.Resolve<IConfiguration>();

                const string ApiKeyConfigKey = "<APP_CONFIG_KEY_HERE>";
                Lazy<string?> lazyApiKey = new(() => config.GetValue<string>(ApiKeyConfigKey));

                app.Use(async (context, next) =>
                {
                    const string ApiKeyHeader = "<HEADER_KEY_GOES_HERE>";
                    if (!context.Request.Headers.TryGetValue(ApiKeyHeader, out var apiKeyVal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Api Key not found.");
                    }

                    var apiKey = lazyApiKey.Value;
                    if (!string.Equals(apiKey, apiKeyVal, StringComparison.Ordinal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Invalid API Key.");
                    }

                    await next(context);
                });

                return new PostAppRegistrationDependencyMarker();
            })
            .SingleInstance();
    }
}

Now one more super quick change to Zuplo to add a policy to add my configured API key that I have on my server, and we’re done:

What’s Next for API Gateways in Zuplo?

At this point, I have a public API through Zuplo that can get hit, uses an API key with my own server, forwards that request, and gets the response. It’s a full end-to-end integration which I would have loved to do right within Zuplo — but my Typescript skills were mocking me. That will certainly be an exercise for the future because I think it would be awesome to have this one truly at the edge node.

But before I can make this API public, I still need a few more things… And I never actually accomplished them yet:

API Documentation
Rate limiting
Authentication
Monetization!

The good news is that since I have my API integrated with Zuplo now, a lot of what’s left is almost all drag-and-drop in their portal! I don’t suspect I’ll have to code anything inside of my own server at this point.

Wrapping Up API Gateways in Zuplo

Overall, I thought this was an awesome platform to work with. Getting API Gateways in Zuplo setup is simple and quick — it’s hard to argue with those two things. But if you consider people like me who don’t want to go hand-roll this kind of stuff per service they create, the fact that they’ve integrated so many building blocks makes this dreamy. There were policies in the catalog that made me think “Oh crap! I didn’t even consider that!”.

I’m looking forward to continuing to build this API out in Zuplo and getting it to a point where I can monetize it! So keep your eyes peeled — because you’ll soon have an ASCII art API you can integrate with. While yes, this post is sponsored by Zuplo , I can say without a doubt their platform greatly simplifies a lot of the pain points I never enjoy dealing with when I develop.

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

API Key Authentication Middleware In ASP NET Core – A How To Guide

Dev Leader — Tue, 23 Apr 2024 16:00:00 +0000

While putting some special content together, I found myself needing to integrate API key authentication middleware into my ASP.NET Core application. I’ve written before about using custom middleware in ASP.NET, but I’ve also been trying to do a better job of documenting smaller code changes like this so the next time I’m looking I have an easy reference.

And that means YOU get some free code and a reference guide to go along with it!

What is Middleware in ASP.NET Core?

Middleware in ASP.NET Core is code that you can add into an application’s pipeline to handle requests and responses. Each of these components can:

Choose whether to pass the request to the next component in the pipeline
Can perform work before and after the next component in the pipeline.

When building an ASP.NET Core application, middleware can be used to implement functionality such as authentication, error handling, logging, and serving static files. The list goes on, and you can even implement your own custom middleware. If you’d like more information on middleware to get started, you can check out this article that I’ve written:

Custom Middleware in ASP.NET Core – How to Harness the Power!

For our use case here, we’ll be looking at adding our own custom middleware to an ASP.NET Core application. Given that we want to do some type of authentication with an API key, we should be able to create middleware that STOPS processing if the key is invalid or CONTINUE processing if the key is valid. Should be simple enough, right? Let’s continue on and see!

API Key Authentication Middleware Example Code

Now that you understand what middleware in ASP.NET core is, let’s look at an example. For my application, I wanted to handle the API key from the request header. Of course, this could be done in different ways, like having a query parameter for example, but the header was what I decided to go with.

Here’s the example API key authentication middleware in this code snippet:

public async Task MyMiddleware(
    HttpContext context,
    RequestDelegate next)
{
    // if you wanted it as a query parameter, you'd
    // want to consider changing this part of the code!
    const string ApiKeyHeader = "<YOUR_HEADER_KEY_HERE>";
    if (!context.Request.Headers.TryGetValue(ApiKeyHeader, out var apiKeyVal))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Api Key not found.");
        return;
    }

    const TheRealApiKey = "<YOUR_SECRET_API_KEY_HERE>";
    if (!string.Equals(TheRealApiKey, apiKeyVal, StringComparison.Ordinal))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Invalid API Key.");
        return;
    }

    await next(context);
}

The code above is very much representative of the chain of responsibility design pattern! Our middleware handler can take action, and then is able to call into the next delegate using the context that was passed in — or it can terminate the sequence by writing a response back and leaving the method without calling the next handler. But if you’re wondering where we hook this up, then check this code snippet:

// "app" here is the WebApplication instance after
// being built by the web application builder
app.Use(MyMiddleware);

Odds are you do NOT want to have your API key right in your code — in fact, I would say “PLEASE DO NOT DO THIS!” so that you don’t accidentally commit a secret API key into your source control. A way that we can work around this is by using environment variables and the app configuration! So in the following code example, you can see a string value being looked up in the application’s configuration:

// "app" here is the WebApplication instance after
// being built by the web application builder
var config = app.Configuration
var secretApiKey = config.GetValue<string>("<CONFIG_KEY_NAME>");

Now instead of comparing against a hard-coded API key directly in your code, you can read it from a configuration instance, which can be populated by environment variables!

Using This With Plugin Architecture in CSharp

It’s no secret that I like using plugin architectures when I’m developing software — but this might be your first time reading some of my content. So spoiler alert: I love using plugins when designing software systems.

In the ASP.NET Core application that I wanted to add my API key authentication middleware to, I have a very simple loading scheme that allows dependencies to “hook” into the web application building process. This is accomplished by a couple of basic steps:

I use Autofac and assembly scanning to look for DLLs with Autofac modules to load in at startup time
These DLLs become plugins, so by definition any plugin can then use the dependency container builder to register their own dependencies
Part of that registration process means they can ask the container for the web application instance that was built
Once they have that web application instance, they are able to hook up their middleware to it.

This is a very simple/naive way to do this because there’s no ordering or control on the middleware. If certain middleware MUST be registered before/after other middleware, there’s no opportunity to say so — You just buckle up and hope for the best. However, that’s okay for now because my middleware needs are EXTREMELY limited currently. I will create an ordering scheme for this if/when necessary.

So what does my plugin code look like? Pretty much what we saw earlier, except inside of an Autofac module:

internal sealed class ApiKeyModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();
                var config = ctx.Resolve<IConfiguration>();

                const string ApiKeyConfigKey = "API_CONFIG_KEY_NAME";
                Lazy<string?> lazyApiKey = new(() => config.GetValue<string>(ApiKeyConfigKey));

                app.Use(async (context, next) =>
                {
                    const string ApiKeyHeader = "HEADER_KEY_NAME";
                    if (!context.Request.Headers.TryGetValue(
                        ApiKeyHeader,
                        out var apiKeyVal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Api Key not found.");
                        return;
                    }

                    var apiKey = lazyApiKey.Value;
                    if (!string.Equals(apiKey, apiKeyVal, StringComparison.Ordinal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Invalid API Key.");
                        return;
                    }

                    await next(context);
                });

                // this is used to help control the ordering of dependencies
                // so the application won't start until all of these
                // have been resolved!
                return new PostAppRegistrationDependencyMarker();
            })
            .SingleInstance();
    }
}

If you’re wondering what the benefit is: I never had to touch any other code in my project and I instantly added API authentication to every single route. This code is currently in the main assembly, but I could have added it to a new project, built the DLL, and dropped it into the running directory to get this behavior activated.

That’s the power of building with plugins!

Wrapping Up API Key Authentication Middleware

Overall, adding API key authentication middleware in ASP.NET Core applications is quite simple! The middleware can be added directly onto the application instance and you can decide how you’d like to load your secret API key to compare against. By sprinkling in a little bit of C# plugin architecture like I prefer to use in many of my projects, it’s a breeze to extend the functionality of your ASP.NET Core app!

Dev Leader Weekly | Substack

weekly.devleader.ca

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

8 Things I Wish I Understood Earlier In My Career

Dev Leader — Mon, 22 Apr 2024 16:00:00 +0000

Our lives and careers are journeys, so we should expect that we’ll be learning for the duration we’re on this planet. As long as we’re moving forward in life, we have experiences to learn from. When I reflect on my career, there are a lot of lessons that I wish I could have taught myself early on. While I can’t talk to my younger self, I can share these with you!

If you enjoy this kind of content, I often write about it in my weekly newsletter. You can subscribe to it for free:

Dev Leader Weekly | Substack

    <div class="color-secondary fs-s flex items-center">
        <img
          alt="favicon"
          class="c-embed__favicon m-0 mr-2 radius-0"
          src="proxy.php?url=https://substackcdn.com/image/fetch/$s_!zfLf!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4a947694-4ddd-4cc0-befa-83c12c83141d%2Ffavicon.ico"
          loading="lazy" />
      weekly.devleader.ca
    </div>
  </div>
</div>

1 – Keep Building

Keep building things. It doesn’t matter if they’re not million-dollar product ideas. Build things to learn about how they work.

The goal when we’re building things, especially early in our software engineering journeys, is not to get-rich-quick. The goal is to practice and learn.

There’s no shortcut to mastery except for understanding sooner that there’s no shortcut. We need to practice — so build software.

2 – Reinvent The Wheel

We’re always told to not reinvent the wheel. There’s no point doing it if someone else has already done it.

But this isn’t always good advice.

Reinventing the wheel is one of the best ways to understand how something works and the complexity behind it. It might not be the best thing to chase in a production environment with paying customers, but it’s great for learning.

If you’re ever curious about how things work or interested in the complexities of a system or technology — try building it yourself. You’re almost guaranteed to learn something about what you’re diving into. I’d be shocked if you didn’t!

3 – Learn In Public

Document your journey so others can learn alongside you. This can help reinforce learning in so many ways because you need to find ways to explain the concepts that you think you’re now understanding.

However, don’t masquerade as an expert. Be humble and acknowledge that you’re new and learning. Others will be more willing to help.

Remember that everyone has different opinions. Some people are more loud but it doesn’t make them more correct. In fact, the louder people unwilling to listen to other perspectives are more often than not going to be less helpful. So don’t be discouraged.

If people correct your mistakes, this is a great chance for you to take lessons learned and improve!

4 – We Build Software In Teams

In the large majority of cases, software is built in teams. This means that you need to focus on communication skills, collaboration skills, and ALL of the other skills that aren’t just technical.

When it comes to technical direction, you need to consider that it’s not just your choices.

This is a good thing — because the different backgrounds, experiences, and perspectives will allow you to build better software as a group.

5 – Composition > Inheritance

Inheritance gets pushed a LOT when teaching programming but if you gravitate towards using composition early then you’ll “shortcut” a few years of really crappy code.

Seriously. I’m guilty of writing mountains of code with ridiculously long inheritance hierarchies. I can’t blame this entirely on WinForms and the Controls paradigm that was used… I should have taken some responsibility!

I’d spend a good portion of my early career rewriting a lot of overly complex inheritance code because it became too complex.

6 – Don’t Fear Learning

Don’t be afraid to learn new things. Building expertise can feel great, but don’t let it make you feel so safe that new things feel scary.

You’re going to suck at new things but it’s very temporary. You’ll prove to yourself repeatedly that you eventually get working knowledge and feel very comfortable.

In my career, my best growth opportunities were when I was forced into something new and uncomfortable. Every time I came out on top.

Discomfort led to incredible learning experiences.

7 – Own Your Career Development

Nobody is as interested in your career progression as you are. Great managers will indeed help encourage you and give you opportunities to move things along.

But we can’t just sit back and wait for this. We won’t always have amazing managers.

The sooner you realize that being passive is not a good strategy for progression, the sooner you can take action.

8 – Remember To Have Fun

You’re in this for the long haul, spending many hours of your life building software. You better enjoy it.

Not every day is going to be easy. Not every day will be interesting. Not every day will exciting.

But overall, you need to find ways to enjoy what you’re doing. It will help you learn. It will help you be engaged. It will help you be motivated to push through interesting challenges.

Software engineering is very mentally demanding and it’s often hard to find a good work-life balance… So keep this one in mind throughout your career.

What would you add or change? If you found this insightful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Dev Leader Weekly | Substack

    <div class="color-secondary fs-s flex items-center">
        <img
          alt="favicon"
          class="c-embed__favicon m-0 mr-2 radius-0"
          src="proxy.php?url=https://substackcdn.com/image/fetch/$s_!zfLf!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4a947694-4ddd-4cc0-befa-83c12c83141d%2Ffavicon.ico"
          loading="lazy" />
      weekly.devleader.ca
    </div>
  </div>
</div>

Want More Dev Leader Content?

Follow along on this platform if you haven’t already!
Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
Looking for courses? Check out my offerings: VIEW COURSES
E-Books & other resources: VIEW RESOURCES
Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY

The Impact of Lazy Evaluation of Iterators

Dev Leader — Sun, 21 Apr 2024 06:59:22 +0000

Hey friends! I post TONS of videos on YouTube... Do you want me to cross-post my videos here to Dev.to?!