DEV Community: David Guida

OpenSleigh: tackling state persistence

David Guida — Tue, 02 Mar 2021 14:01:56 +0000

Hi All! Here we go with another article about OpenSleigh. Today we’re going a bit deeper into the rabbit hole and see how it is dealing with state persistency.

The last time we introduced the library, discussed a bit about what the Saga pattern is and what’s the general idea behind Orchestration and Choreography.

Now. Sagas are all about messages. Commands get issued and events get published. At the same time though, we have to make sure that changes to the internal state of the Saga are being persisted safely. Also, we want outgoing messages to be dispatched only when the local state is saved.

In an ideal world, we wouldn’t have to worry about this, but unfortunately, we have to deal with a bunch of nasty stuff like concurrency and horizontal scalability.

For example, let’s suppose that our application is composed of 2 services: a Web API and a background worker service. Let’s call them “Orders API” and “Orders processor“, that should help you get the picture.

The Web API is responsible for receiving client requests, packing them into nice messages, and pushing them to a service bus. The worker subscribes to those messages and uses OpenSleigh to handle Saga execution.

This is a pretty nice and standard way of handling long-running operations asynchronously. Works pretty well and, most importantly, scales pretty well.

But what happens if we have more instances of the worker help handling the load? Suppose for a moment that the Orders API pushes a _ProcessOrder ****_command for the same order “123” twice. It had a hiccup, a network glitch. Sh*t happens.

Now, this quite unfortunate event means that the same order will probably be processed twice. Moreover, if we have more worker instances, it might happen that both the messages will be dispatched and processed concurrently.

How does OpenSleigh handle these situations?

First of all, we can assume that the ProcessOrder command starts the ProcessOrderSaga. Each OpenSleigh Saga has a configurable unique ID, which is used also as correlation ID. In this case, I think it’s safe to use the Order ID to populate this value.

When the Orders processor service receives a message, OpenSleigh will extract the correlation id and use it to fetch the right Saga state from the persistence storage.

If no existing Saga State is available, we check if that message is capable of starting a new Saga. If so, we’ll get a shiny new instance and we can finally get down to business.

That’s all for today. The next time we’ll continue analyzing the flow and we’ll see some code. Ciao!

Dynamic method invocation with .NET Core

David Guida — Fri, 05 Feb 2021 20:22:05 +0000

Hi All! Today we're going to explore few ways to perform "dynamic method invocation" with .NET Core.

As some of you know already, a while ago I started working on an open-source project, OpenSleigh. It's a Saga management library for .NET Core applications.

I have been focusing on it a lot in the last period, and this, unfortunately, led me to be less diligent with my blog. I have several articles in my backlog, looking for the right time to jump off the hat.

Anyways, while working on the first prototypes of OpenSleigh (BTW, make sure to at least fork or star the repository!), I had to face a bunch of times an interesting problem.

Let me try to summarize it very quickly:

What if we have to call a method on some instance, but the only thing we know is the method signature and not the class type?

It's a tricky situation, but luckily for us, .NET has a few ways to get to the destination.

The problem now is: which one is the best?

So I decided to give it a try and write some benchmarks. I've tested:

direct method invocation
MethodInfo.Invoke
Delegate.DynamicInvoke
Func<> invocation
dynamic cast

Of course, *direct method invocation *is used as a comparison, a baseline for all the other techniques.

Let's suppose we have this small class here:

public class Foo
{
    public int Bar(int a, int b, bool c) => a + (c ? b : 0);
}

And we want to call Bar() *on an instance, but all we have is an *object. Let's take a look at each technique.

MethodInfo.Invoke

We simply start by storing a MethodInfo reference to Bar() and then we simply invoke it:

object fooInstance = ...; // we get this from somewhere else
MethodInfo barMethod = ClassType.GetMethod(nameof(Foo.Bar));
barMethod.Invoke(fooInstance, new[] { (object)1, (object)2, (object)false });

Delegate.DynamicInvoke

In this case, instead, we start off by getting a MethodInfo *reference, but we wrap it into a typed *Delegate:

object fooInstance = ...; // we get this from somewhere else
MethodInfo barMethod = ClassType.GetMethod(nameof(Foo.Bar));
var delegateType = Expression.GetDelegateType(typeof(Foo), typeof(int), typeof(int), typeof(bool), typeof(int));
var @delegate = Delegate.CreateDelegate(delegateType, barMethod);
@delegate.DynamicInvoke(new[] { fooInstance, (object)1, (object)2, (object)false });

Func<> invocation

Similar to the previous one, but we also cast the Delegate *to a *Func<>:

object fooInstance = ...; // we get this from somewhere else
MethodInfo barMethod = ClassType.GetMethod(nameof(Foo.Bar));
var delegateType = Expression.GetDelegateType(typeof(Foo), typeof(int), typeof(int), typeof(bool), typeof(int));
var func = (Func<Foo, int, int, bool, int>)Delegate.CreateDelegate(delegateType, barMethod);
func(fooInstance as Foo, 1, 2, false);

This one seems a little bit "shady", since we actually know that the instance is of type Foo. But still, I decided to add it to the group since it might still come useful.

Dynamic cast

This one is the easiest to code (after the direct invocation of course), as it's basically just a cast to dynamic and a method call:

object fooInstance = ...; // we get this from somewhere else
dynamic dynamicFoo = fooInstance as dynamic;
dynamicFoo.Bar(1, 2, false);

So, after all this fuss, who's the winner? I guess an image is worth thousand words:

So as you can see, calling a method directly, is definitely the fastest way. Followed immediately by the "shady" *Func<> *call and then the *dynamic *cast.

As usual, I've pushed the code to GitHub, so feel free to run your experiments and let me know!

How to do Document-level locking on MongoDB and .NET Core

David Guida — Mon, 11 Jan 2021 22:04:00 +0000

Hi All! Today we're going to see how MongoDB handles locks and how we can achieve Document-level locking.

The default MongoDB storage engine, WiredTiger, uses optimistic concurrency control, or OCC. In a nutshell, it assumes that

multiple transactions can frequently complete without interfering with each other.

WIKIPEDIA

This basically means we're somewhat sure that nobody else is going to update our data while we're working on it.

In case that happens, one operation is going to succeed, while the others will fail, entering some kind of retry loop.

We're relying on the nature of the data and the operations available on the Domain. In short, we're being optimistic that things will end up just fine.

When we want to be absolutely sure that only one consumer will be able to operate a specific set of data, we could use some form of locking.

This falls into the realm of Pessimistic Locking: we block access to the data till we're done with it. The drawback is simple: what if we never release a lock? The other consumers will deadlock, so we need a proper strategy (for example timeouts) to handle those cases.

It can get complicated and ugly pretty quickly so be careful.

There might be some situations, however, where you need more fine control over the locking strategy, for example when you're dealing with Sagas and Distributed Transactions.

Now, WiredTiger allows locking only at the global, database or collection levels. This means that we cannot lock a single document.

Luckily for us, operations on MongoDB are atomic, so we can "fake" some sort of pessimistic locking and handle part of the complexity on the application side.

The idea is to decorate every document with two additional properties, something like:

{
    "LockId" : UUID("6ca9d76f-01ac-42cc-88ca-b2ecd5b286c3"),
    "LockTime" : ISODate("2020-12-28T04:42:13.528Z")
}

When we want to lock a document, we fetch it by ID but we also make sure that LockId is null. Additionally, we can also check that LockTime is after a specific window: this way we can discard previous locks if they're expired.

Using the FindOneAndUpdateAsync API, we can fetch the document and in the same operation, we can set both LockId and LockTime.

We'll also configure the call to be an upsert: this way if the document is not in the DB yet, we can also create it. Moreover, the next time someone is trying to access it, the engine will throw a MongoCommandException instead.

When we're done with the document, we can release it by simply setting to null both LockId and LockTime.

Just for you to know, a while ago I started working on OpenSleigh, a distributed saga management library for .NET Core. It uses the same technique in its MongoDB persistence driver.

The next time we'll see a small demo and dig a bit more into the details. Stay tuned!

OpenSleigh: a Saga management library for .NET Core

David Guida — Mon, 11 Jan 2021 19:55:32 +0000

Hi All! Today I want to talk a bit about a pet project of mine I've been working on in the last few weeks. I called it OpenSleigh, it's a Saga management library for .NET Core.

For those who don't know what the Saga Pattern is, Chris Richardson has a very good introduction on his website.

The basic idea is quite interesting: in a micro-service architecture, it often happens that we need to handle several long-running operations that span multiple services. Distributed transactions are a nasty little beast and we also need a way to keep track of the global status and manage the whole flow.

There are two main schools of thought for this: Choreography and Orchestration.

With Choreography the logic is decentralized, scattered and shared amongst the participants. They usually communicate using a Message Broker, like RabbitMQ or Kafka, which makes definitely easier adding and removing message publishers and consumers.

With Orchestration instead, the logic is centralised in a single component, which is in charge of the entire workflow. Once the process is triggered, this orchestrator will take care of calling each microservice (directly or via messaging) and handling responses and faults.

OpenSleigh falls into the realm of the orchestrators. It can be added to regular Console or Web applications, will spin up a bunch of BackgroundServices, and do its magic.

The Core module of OpenSleigh can be installed from NuGet. However, Transport and Persistence packages are necessary to properly use the library.

These are the packages available at the moment:

Now, there are already several valuable alternatives on the market, like MassTransit and NServiceBus. So why did I started this project?

Because I was curious. And I'm pretty damn sure many of you can relate.

I wanted to see how a Saga system works from the inside. Also, I wondered if I could build one myself from scratch. I wanted to create an open-source project and create a community around it.

So don't hesitate! Take a look at the repository on GitHub, download the packages, play with them, and send me your feedback!

ASP.NET Core structured logging - introduction

David Guida — Tue, 08 Dec 2020 14:52:13 +0000

Hi All! In this post, we'll see what's the difference between "standard" and "structured" logging and how the latter can help us tracing down issues in our systems.

But first, let's begin with a question. Ever had to go through countless log messages to find a single tiny entry?

Then you know how it feels like.

*Standard *logging represents the simplest form possible. It's just a simple message, possibly correlated with a timestamp and probably a few other pieces of data.

"creating customer 123..."
"an exception has been thrown by..."
"something, somewhere, went terribly, terribly wrong"

Maybe, if you're lucky you also get a bit of stack trace.

Adding logging to an ASP.NET application is quite easy, although configuring it properly can be sometimes tricky.

Knowing what to log instead is the real deal. We don't want to lose important information but at the same time, we have to avoid polluting the system with unnecessary messages.

Now, the problem with *standard *logging is that searching for specific entries can become difficult. Very difficult, especially when our system has been online and used for a while.

Filtering and potentially doing some aggregation is doable but the quality of results is questionable. There are multiple tools that can help us with this, like Grafana and Splunk (and do much more than that, to be fair).

So what other option do we have? Well, we can move to structured logging instead. What's the difference? Well, basically we're enriching the log entry with some additional data, regardless of the actual text message.

These fields can then be used later on to filter the entries, create aggregation, stats and charts. All this data is of course extremely useful, helping us monitoring and keeping under control the health of our systems.

Now, obviously, if your application is creating just a hundred messages per day, you won't find much benefit from all of this. Just come up with a decent Regexp and you're good to go.

This, of course, doesn't mean that you'll have to start throwing more messages just for the sake of it. All the opposite.

But if you're orchestrating a large microservice application, with a lot of moving parts, possibly with complex architectures like Event Sourcing, then you want to be careful.

If we're being diligent and keeping field naming consistent, structured logging will help us track down the flow of our transactions amongst the different services. Yes, it can be hard, especially when there are multiple teams working on separate microservices.

In this case, things like Trace identificators are the key solution to our problem.

That's all for today. In another article we'll see some examples and how to leverage structured logging in our ASP.NET Core application.

Blazor and 2D game development – part 1: intro

David Guida — Tue, 01 Dec 2020 13:48:41 +0000

Every now and then I go back to game development. It's literally what brought me into this world of coding, something like 32 years ago. This time I decided to do some experiments with Blazor and 2D graphics.

I don't have a precise goal in mind right now, just playing around.

Probably this late-night fever started when I wrote about D&D, Blazor and gRPC services.

For those interested, on GitHub you can find a repository with all the examples I'll be able to come up with.

For now, I decided to proceed at incremental steps and write small features, one on top of the other. As of today, this is the current list:

Example 1 shows how to initialize the 2d canvas
in example 2 we see how to render a sprite and react to the window resize event
Example 3 shows how to move a sprite on the screen
Then in example 4, we build on top of the previous one, refactoring and cleaning up the code
Example 5 shows how to handle mouse inputs
Example 6 shows how to animate a sprite. I downloaded the spritesheets from here and combined them using a custom tool

I will try to write an article for every example, it will also serve as reminder of my train of thought and how I managed to get the code in that shape.

As I wrote previously, I don't have a precise goal at the moment. I *might *end up with something playable, although I tend to change idea quite often on this matter. As many of us, I can get distracted quite easily by new shiny toys. Or simply by life

The next time we'll start by initializing the Canvas and rendering some text.

How to migrate Blazor Webassembly to .NET 5

David Guida — Mon, 30 Nov 2020 02:34:01 +0000

.NET 5 is out today! It's a big milestone and comes with a huge list of improvements. I've been working a bit with Blazor lately, trying to brush up my gamedev skills again. So I took the chance and decided to upgrade my little pet project to the latest version :)

The first thing to do is to install or update Visual Studio 2019 to version 16.8.0. For those interested, the release notes are available here. In case you're using a different IDE (or you're on Linux/Mac), you can directly download the .NET 5 SDK instead.

Once you've done installing, fire up your Blazor project and open the .csproj file. We're going to change few little things:

At the very top, update the SDK from Microsoft.NET.Sdk.Web to Microsoft.NET.Sdk.BlazorWebAssembly

<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">

2. Set the TargetFramework to net5.0

3. In case you have it, remove the package reference to Microsoft.AspNetCore.Components.WebAssembly.Build

4. Update your Nuget dependencies

Now make sure you Clean your entire solution, otherwise, the build engine won't be able to re-generate all the required files with the updated framework.

Enjoy!

Write a WordPress blog with…Blazor!

David Guida — Mon, 30 Nov 2020 02:31:25 +0000

Yeah, I'm not getting crazy. It is 100% possible to replace your WordPress theme with a Blazor Webassembly application.

How? Well, it's not that hard actually. It's been a while now since WordPress has started exposing a quite nice REST API. The first draft was added with version 4.4, but it's with version 4.7 that it gained full momentum.

The API itself is definitely easy to use. The base endpoint looks something like "yoursite.com/wp-json/wp/v2".

From that you can start managing posts, users, comments...well you got the idea.

This opens the door to a wide range of scenarios, for example, we could use WordPress as a headless CMS and write multiple frontends based on our needs. Mobile apps, SPAs, PWAs and so on.

Just to showcase how easy it is, let's see how we can quickly write a frontend blogging app using Blazor.

Now, CORS should be enabled by default. If it isn't, a quick search on google should give you the answer. For the sake of the exercise, let's suppose it is, so we can safely use Blazor in Webassembly mode.

Once we've created our project, the next step is to add a reference to the WordPressPCL Nuget library. It's a handy project, that will spare us the time to write the API client ourselves.

Once it's installed, we can register the client on the Composition Root in the Program.cs file:

var wpApiEndpoint = builder.Configuration["WP_Endpoint"];
var client = new WordPressClient(wpApiEndpoint);
builder.Services.AddSingleton(client);

Now, we're basically done! Every time we want to, for example, read posts or anything, all we have to do is inject the WordPressClient instance and use it:

var postsQuery = new PostsQueryBuilder()
    {
        Page = 1,
        PerPage = 10,
        Order = Order.DESC,
        OrderBy = PostsOrderBy.Date
    };
var posts = await WPClient.Posts.Query(postsQuery);

I have created a small repo on GitHub as usual with some handy examples. I also added a GitHub Action pipeline that will deploy the code to GitHub Pages, so you can see how it would look like.

For detailed instructions on how to host a Blazor Webassembly application on GitHub Pages, you can take a look at my previous post.

See ya!

How to deploy Azure Function Apps with Powershell

David Guida — Tue, 24 Nov 2020 15:23:42 +0000

Hi All! Today I want to show a quick'n'dirty way to easily deploy your projects to Azure using Powershell.

I've been working a lot recently with Azure Functions and Web Apps. And of course, each time I'm confident with my code, I want to see it deployed on the Cloud.

Of course in an ideal world, we all would have a nice CI/CD pipeline, potentially on Azure DevOps. It might happen, however, that for one reason or another, you can only get up to CI, without being able to deploy.

So the only option you have is to manually handle deployments, most likely from your local machine. But what happens if you have to deploy it to multiple destinations?

In my case, for example, I had to deploy a Function App and a Web App to multiple client subscriptions. Of course, you can always do this directly from Visual Studio, but it still feels like a lot of manual work.

What if instead you can have a very nice script that handles all the grunt work for you?

Moreover, you could potentially reuse it when you finally manage to get to the Continuous Deployment part.

So, the first step is to create the Release Artifact. I am assuming, of course, that you've run already your Tests and everything went fine.

My weapon of choice for these scripts today, will be Powershell:

function publish{
    param(
        $projectName        
    )

    $projectPath="src/$($projectName)/$($projectName).csproj"
    $publishDestPath="publish/" + [guid]::NewGuid().ToString()

    log "publishing project '$($projectName)' in folder '$($publishDestPath)' ..." 
    dotnet publish $projectPath -c Release -o $publishDestPath

    $zipArchiveFullPath="$($publishDestPath).Zip"
    log "creating zip archive '$($zipArchiveFullPath)'"
    $compress = @{
        Path = $publishDestPath + "/*"
        CompressionLevel = "Fastest"
        DestinationPath = $zipArchiveFullPath
    }
    Compress-Archive @compress

    log "cleaning up ..."
    Remove-Item -path "$($publishDestPath)" -recurse

    return $zipArchiveFullPath
}

Here I'm building a temporary path using a GUID and calling *dotnet publish *to compile the Project and output the binaries to it. Then we generate a Zip archive and get rid of the publish folder.

The log *function is just a simple wrapper over *Write-Host, I just added some fancy colors to highlight the text:

function log{
    param(
        $text
    )

    write-host $text -ForegroundColor Yellow -BackgroundColor DarkGreen
}

Now that we have our Artifact, the next step is to deploy it to Azure. If you, like me, are working with Azure Functions, this is the script for you:

function deploy{
    param(
        $zipArchiveFullPath,
        $subscription,
        $resourceGroup,
        $appName
    )

    log "deploying '$($appName)' to Resource Group '$($resourceGroup)' in Subscription '$($subscription)' from zip '$($zipArchiveFullPath)' ..."
    az functionapp deployment source config-zip -g "$($resourceGroup)" -n "$($appName)" --src "$($zipArchiveFullPath)" --subscription "$($subscription)"
}

It simply takes the full path to the zip archive we produced before and the name of the destination Azure Subscription, Resource Group and Application. Easy peasy.

Now, I've found particularly handy to set some basic application settings, right after the deployment. For this, I keep a simple JSON file with key/value pairs and deploy it using this script:

function setConfig{
    param(
        $subscription,
        $resourceGroup,
        $appName,
        $configPath
    )
    log "updating application config..."
    az functionapp config appsettings set --name "$($appName)" --resource-group "$($resourceGroup)" --subscription "$($subscription)" --settings @$configPath
}

The config file can be something like this:

{
  "FUNCTIONS_WORKER_RUNTIME": "dotnet",
  "ASPNETCORE_ENVIRONMENT": "DEV",
  "Foo": "bar"
}

The last step is to put everything together and call it. I would suggest creating a separate script with all the previous functions. We can use it as a "library" and if we're lucky enough, it won't even change much when we move to CD.

For our local deployment script we will instead need two more helper functions. The first one will take care of the Artifact:

function createArtifact {
    param(
        $appName
    )
    $zipPath = publish $appName
    if ($zipPath -is [array]) {
        $zipPath = $zipPath[$zipPath.Length - 1]
    }
    return $zipPath
}

We can't, unfortunately, call directly the publish *function because seems that the output from the *dotnet publish command will mess a bit with the return value. So we'll need to do some magic tricks, but not that much.

Then we can send the artifact to the cloud:

function deployInstance {
    param(
        $zipPath,
        $subscription,
        $resourceGroup,
        $appName,
        $configPath
    )

    deploy $zipPath $subscription $resourceGroup $appName

    if(![string]::IsNullOrEmpty($configPath)){
        setConfig $subscription $resourceGroup $appName $configPath
    }
}

If you remember, at the top of the post I said that we might have to deploy the same artifact to multiple destinations. Now that we have everything in place, all we have to do is just put the pieces together:

$zipPath = createArtifact "MyAwesomeProject"
deployInstance $zipPath "MyFirstSubscription" "MyFirstResourceGroup" "MyAwesomeProject1" "DEV.settings.json"
deployInstance $zipPath "MySecondSubscription" "MySecondResourceGroup" "MyAwesomeProject2" "DEV.settings.json"
deployInstance $zipPath "MyThirdSubscription" "MyThirdResourceGroup" "MyAwesomeProject3" "DEV.settings.json"

...and so on and so forth. I think you got the idea.

This should cover all the basic steps to deploy your code to Azure from your machine. Most of these scripts can be adapted quite easily to be executed on Azure DevOps. And that should be, ultimately, your goal: don't let this task sit on you for too long! They will create unnecessary clutter and noise, distracting from the real project!

Event Sourcing on Azure

David Guida — Tue, 24 Nov 2020 15:07:18 +0000

Hi All! With this post, we'll start a new Series about Event Sourcing on Azure. We're going to talk a bit about the pattern, general architecture, and the individual building blocks. Then in the next posts, we'll dig more and see each one in detail.

If you're a regular reader of this blog, you might know that I wrote already about Event Sourcing in the past. It's a complex pattern, probably one of the most complex to get right. I enjoy the challenges it gives and how it causes a whole plethora of other patterns to be evaluated in conjunction (CQRS anyone?).

And like any other pattern, there are no silver bullets. Architecture and implementation will change based on the Domain needs.

But we can "quickly" lay out the general idea, and then diverge from it based on our necessities (or should I say the business necessities).

So let's start with the architecture!

On the left we have the Commands (or Write Side), let's begin with that. The Commands our system exposes will be accessed via REST endpoints through a Web API. We could use Azure Functions with an HTTP trigger as well, but we'll talk more about this in another post of the Series.

Whatever way we pick to communicate with the outer world, the commands will first go through a validation phase against the business rules. This usually happens by re-hydrating the Aggregate Root from past events and performing a set of operations on it.

Then, if everything is fine, the commands be translated into Domain Events and persisted in our Event Store. We will be using CosmosDB for this.

Then we have to publish Integration Events to inform other parts of the system that "something" happened. This will be handled by Azure Service Bus Topics. We'll use Topics instead of simple Queues because we might have different consumer types interested in a particular event type. And of course, we want to deploy, operate, and scale those consumers independently.

One of these consumers will be an Azure Functions App with a very important role: materializing our Query Models. When querying data, we can't, of course, rehydrate the Aggregates each time. Yes, we would get consistent data each time, but it would be overkill, even if we were using snapshots.

So we subscribe to the Topics and each time we receive an event, we refresh a query-specific version of the data and we store it in another storage. We will still be using CosmosDB in our example.

Materialized views have the great benefit of being exactly what our calling application needs, including all the possible aggregated data. Moreover, in case our requirements change, we can always add new views or update the existing ones. As long as we have the original events stream, we can flush all the views and rebuild them from scratch with little cost.

That's all for today. Next time we'll see how we can handle events persistence. Ciao!

Blazor and Dragons! How to Consume gRPC-web From Blazor

David Guida — Tue, 14 Jul 2020 13:43:30 +0000

Hi All! Today we’re going to talk about how to consume a gRPC service from a Blazor client. And we’re going to do it with Dungeons & Dragons!

People who know me, know that deep down, I’m a big nerd. I started playing D&D when I was a freshman in college and kept going for years. Eventually, I began writing my own campaigns, holding sessions as Dungeon Master, and even participating in competitions. And winning.

I play Baldur’s Gate 2 at least once a year. Each time with a different class/race. Oh boy, that game is massive!

The last game I bought on Steam? Icewind Dale. Of course, I played it in the past but never had the pleasure of “owning” it.

So what does all of this with Blazor and gRPC? Well, a few days ago I was looking for a fun way to study them both. And I thought: is there anything out in the interwebz that I can leverage?

And the answer, of course, was yes: the D&D 5e REST API! It’s free and doesn’t require any auth so it’s a perfect way to feed some data in our app.

My goal? Well as I said, I just wanted to play with Blazor and gRPC. And have some fun in the meantime.

So I wrote a simple Blazor webassembly gRPC client to display an archive of D&D classes. You can click on a row and get redirected to a detail page. Easy peasy.

The data is coming from a separate application, exposing a gRPC service. This server is basically just a simple proxy over the D&D REST API. I deliberately decided to not add any caching or other fancy things, just to focus on the transport.

Now, due to browser limitations, we can’t really use gRPC here, but we can rely on gRPC-web instead. Let me quote James Newton-King:

It is impossible to implement the gRPC HTTP/2 spec in the browser because there is no browser API with enough fine-grained control over HTTP requests. gRPC-Web solves this problem by being compatible with HTTP/1.1 and HTTP/2.

For those interested, the full article is here.

As usual, the code is available on GitHub, help yourself.

Let’s explore the client today. The first step is to add our .proto file, defining the layout of our messages:

syntax = "proto3";
import "google/protobuf/empty.proto";
option csharp_namespace = "BlazorAndDragons.Client";

package classes;

service Classes {
    rpc GetAll (google.protobuf.Empty) returns (GetAllResponse);
    rpc GetDetails(GetDetailsRequest) returns (GetDetailsResponse);
}

message GetAllResponse {
    message ClassArchiveItem{
        string id = 1;
        string name = 2;
    } 

    repeated ClassArchiveItem data = 1;
}

message GetDetailsRequest{
    string id = 1;
}

message GetDetailsResponse{
    string id=1;
    string name=2;
    int32 hitDie=3;
    repeated Proficiency proficiencies=4;

    message Proficiency{
        string name=1;
    }
}

Not much to say here. We have two methods, one returning all the available classes (and taking no parameter: thank you google.protobuf.Empty ). The other one instead returns the class details given the id.

Notice how I’ve leveraged the repeated keyword to define arrays of complex objects.

Now, an extremely important step is to make sure our .proto definition is properly referenced in our .csproj file:

<ItemGroup>
    <Protobuf Include="Protos\classes.proto" GrpcServices="Client" />
</ItemGroup>

That GrpcServices=”Client” will basically tell Visual Studio to generate the client proxy classes for us. Quite handy indeed.

Now we have to plug the client in our DI container in our Program.cs:

var builder = WebAssemblyHostBuilder.CreateDefault(args);           
builder.Services.AddSingleton(sp =>
{
    var config = sp.GetRequiredService<IConfiguration>();
    var serverUrl = config["ServerUrl"];
    var channel = GrpcChannel.ForAddress(serverUrl, new GrpcChannelOptions
                {
                    HttpHandler = new GrpcWebHandler(GrpcWebMode.GrpcWeb, new HttpClientHandler())
                });
    var client = new Classes.ClassesClient(channel);
    return client;
 });

As you can see, I’m using GrpcWebMode.GrpcWeb here. I’m not doing any streaming, just unary calls so no need to use GrpcWebMode.GrpcWebText. This gives me the benefit of smaller messages:

For those interested, here’s a nice article explaining the difference between unary and streamed calls.

Now the last step: let’s call our service! That’s actually the easy part:

@page "/"
@using Google.Protobuf.WellKnownTypes
@inject Classes.ClassesClient Client

<h1>Classes</h1>

@if (_classes == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Name</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var item in _classes)
            {
                <tr>
                    <td><a href="/class/@item.Id">@item.Name</a></td>
                </tr>
            }
        </tbody>
    </table>
}
@code {
    private GetAllResponse.Types.ClassArchiveItem[] _classes;
    protected override async Task OnInitializedAsync()
    {
        var results = await this.Client.GetAllAsync(new Empty());
        this._classes = results?.Data?.ToArray();
    }
}

As you can see, the Client is injected and invoked during page initialization. Stop. No strings attached. Told you t’was easy.

In another article we’ll take a look at our server instead. Thanks for reading!

Conway’s Game of Life with Blazor

David Guida — Wed, 10 Jun 2020 19:51:51 +0000

Hi All! In this article, we’re going to see an easy way to implement Conway’s Game of Life using Blazor.

I’ve been spending some time these days working with Blazor. It’s quite an interesting technology, and definitely an excellent alternative to Angular or React or WhateverFancyLibraryJs kids are using these days.

Blazor’s has a lot of nice features and there are few good reasons why could be a good technology to adapt:

model classes can be shared between client and server. No need to write them twice
very low learning curve (if you know already .NET and possibly a bit of Razor)
it’s an open source project, there’s a big community and the documentation is growing as we speak
I’m using it for one of my personal night-time projects and frankly, I’m quite happy. It’s easy to use, performances are good and there’s a nice support for DI, which makes code a lot cleaner.

Moreover, the fact that I can keep my entire codebase in C#, makes me way more comfortable and speeds up the development.

Anyways, a few days ago I learned (a bit late, yes) that John Conway passed away from COVID-19 complications.

For those who don’t know, Conway was one of the most famous mathematicians, active in fields like number theory and combinatorial game theory.

He was also the inventor of a lot of funny math riddles, like the Wizard’s age puzzle, and the famous cellular automaton Game of Life.

It’s an interesting simulation, with incredibly simple rules. Straight from Wikipedia:

Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

Any live cell with fewer than two live neighbours dies, as if by underpopulation.

Any live cell with two or three live neighbours lives on to the next generation.

Any live cell with more than three live neighbours dies, as if by overpopulation.

Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

It’s not super complex to code and it’s a good exercise for those interested in 2D graphics. It’s actually one of the first things I coded for Windows Phone, replying to an article by Shawn Hargreaves in 2012 (phew!).

The code is as usual available on GitHub. The gist of it is in the World class.

The idea is to initialize two grids of booleans and swap them at each iteration. The current grid holds the state that will be used for rendering. Each update step will loop over the cells and compute the new state based on its neighbours. This will then set as the new value in the corresponding cell of the other grid.

And voilà, our simulation is complete!