Welcome to Dev Leader Weekly!

TL;DR:

I’m trimming up my newsletter. Most issues have taken me ~4-6 hours and it’s not sustainable. They’ll be more streamlined.
The coding challenges are moving to my Discord community. They’ll run on a 3-week rotation.
I’ve launched loyalty rewards so you can earn chances for future giveaways. I’ll add to how you can earn, including submitting coding challenges!
I’m working on TWO Dometrain courses right now. These will be released in a couple of months.

If you enjoy my content, you’ll love premium membership access to my site! This includes:

Access the newsletter archive (and an ad-free experience on my website)
Behind The Screen weekly vlogs
Access to the Discord Community

Let’s dive in!

Blazor Plugins for Quartz Jobs

Where We Left Off With Quartz

If you’ve been following along in the Blazor build series, then you’ll know that in the last update, we reached a point in our plugin API design where we hit a bit of a roadblock. Originally, I had suggested that we might be able to work with a plugin facade, and this would allow us to hide the fact we have many plugins and then ask to query for the relevant data all at once through a common interface. However, this would fall apart when we started to look at Quartz and how to set it up.

Here’s what things were looking like where we last left off:

Blazor Plugins with Quartz Job Scheduler - Old Relationship

In the picture above, we have Quartz inside of the Blazor app and then a Facade layer that sits in front of the plugins. That meant that the one Quartz job we’d go to create would (unknowingly) go pull data from each plugin. To the job, it only looks like one data fetching API thanks to the facade.

The Quartz API Constraints

After getting Quartz dropped in and checking out what we had to work with, it made a lot more sense to consider a job that could be scheduled for each plugin. This meant that instead of the plugin API strictly providing an interface for fetching data, it could expose some job information. However, the way that we needed to load that into Quartz was feeling awful due to the plugin needing to expose a type object.

And… that’s gross for a couple of reasons:

It’s just a type object! There’s no enforcement at compile time as to what type it will refer to so it would be easy to do incorrectly.
It meant that the plugins would need to know about Quartz because the type they expose would need to be an IJob from Quartz.

These two things alone were enough for me to want to move away from the paradigm we started with.

The New Plugin Relationship

With these constraints in mind, going to a 1:1 relationship of Quartz job to plugin made more sense. But it wasn’t going to be without its challenges. Here’s what I wanted the new relationship to look like instead, where we resolve from the dependency container and skip the facade:

Blazor Plugins with Quartz Job Scheduler - 1 to 1

This meant that we did away with the facade class altogether and the plugins would no longer need to expose a gross API like this:

public sealed record SocialJobProvider(
    string JobTypeId,
    Type JobType, // FIXME: this is so gross :(
    TimeSpan Interval);

But instead, we could move towards this:

public sealed record SocialJobProvider(
    string JobTypeId,
    ISocialDataFetcher DataFetcher,
    TimeSpan Interval);

This is much closer to what we started with where a plugin just implemented an ISocialDataFetcher.

Dependency Injection & Job Scheduling

These two things had to change up a little bit from what I expected in the beginning — but I should have anticipated some change. I came from using Autofac for all of my dependency injection and wanted to ensure I could focus on the built-in dotnet DI framework. As a result, I had to move the job scheduling logic to be later than I anticipated, but the DI code is still pretty simple:

builder.Services.AddSingleton<TwitterDataFetcher>();
builder.Services.AddSingleton(x => new TwitterConfig(
    "Consumer Key Here",
    "Consumer Secret Here",
    "DevLeaderCA"));
builder.Services.AddSingleton(x => new SocialJobProvider(
    "Twitter",
    x.GetRequiredService<TwitterDataFetcher>(),
    TimeSpan.FromHours(1)));

I’ll need to adapt this to pull from other assemblies later on — but I haven’t done this yet for the built-in framework. I have extensive experience with this in Autofac, but we’ll cross that bridge when we get there!

As for the job scheduling, I can resolve all of the SocialJobProvider instances that come off of the DI framework and schedule jobs with the following code:

var schedulerFactory = app.Services.GetRequiredService<ISchedulerFactory>();
var quartz = await schedulerFactory.GetScheduler();
foreach (var socialJobProvider in app
    .Services
    .GetRequiredService<IEnumerable<SocialJobProvider>>())
{
    var jobKey = new JobKey(socialJobProvider.JobTypeId);
    var jobDetail = JobBuilder
        .Create<FetchingJob>()
        .SetJobData(new JobDataMap
        {
            [nameof(ISocialDataFetcher)] = socialJobProvider.DataFetcher
        })
        .WithIdentity(jobKey)
        .Build();
    var jobTrigger = TriggerBuilder
        .Create()
        .WithIdentity(socialJobProvider.JobTypeId + "-trigger")
        .WithSimpleSchedule(x => x
            .WithInterval(socialJobProvider.Interval)
            .RepeatForever())
        .Build();
    await quartz.ScheduleJob(jobDetail, jobTrigger);
}

Next Steps in Our Blazor App

The next steps are going to include wiring up Entity Framework! We’re at the point where we can likely pull Twitter data if we have the authentication properly configured, but we don’t have a spot to store it. I think it will be helpful for us to spec out some thoughts about what we need to store and how to store it so we can work on extending our prototype.

If you want to see a video walkthrough of this article, check out this early-access video here:

Weekly Recap

Unlock the Power of Quartz Job Scheduler in ASP.NET Core Blazor

In our ASP.NET Core Blazor build series, we’ve discussed the need for a dotnet job scheduler. Lucky for us, we can use Quartz for C# which allows us to schedule jobs! Join me as we explore building our ASP.NET Core Blazor web app and experiment with integrating Quartz .NET for job scheduling!

Avoid This Collaboration KILLER In Software Engineering

As a developer, it’s important to focus on your ability to collaborate. This is especially important because, in software engineering, we’re focused on solving problems… And the most effective way that we do that is by working in teams. Check out this video for advice on how to avoid killing collaboration. This is especially important as a more senior software engineer!

Epic Fail or Promising Attempt – Auto Pipeline Config in C#

The pipeline design pattern is an awesome way for us as C# developers to be able to process data. We can configure stages to wire up and pass data from one to the next. However, one of the challenges is setting this design pattern up! Nobody wants to configure it by hand… Will this thought experiment lead to an easier way for us to configure pipelines in dotnet?