Roundup #65: CASPaxos, HealthChecks & Serilog, Fallback Policies, Playwright, F# Path to Relaxation

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

CASPaxos: Linearizable databases without logs

Recently I’ve been playing around with a new algorithm known as CASPaxos. In this post I’m going to talk about the algorithm and its potential benefits for distributed databases, particularly key-value stores.

Link: https://reubenbond.github.io/posts/caspaxos

Excluding health check endpoints from Serilog request logging

In this post I show how to skip adding the summary log message completely for specific requests. This can be useful when you have an endpoint that is hit a lot, where logging every request is of little value.

Link: https://andrewlock.net/using-serilog-aspnetcore-in-asp-net-core-3-excluding-health-check-endpoints-from-serilog-request-logging/

Globally Require Authenticated Users By Default Using Fallback Policies in ASP.NET Core

You can use Fallback Policies in ASP.NET Core 3.0+ to require an Authenticated User by default. Conceptually, you can think of this as adding an [Authorize] attribute by default to every single Controller and Razor Page ONLY WHEN no other attribute is specified on a Controller or Razor Page like [AllowAnonymous] or [Authorize(PolicyName="PolicyName")]).

Link: https://scottsauber.com/2020/01/20/globally-require-authenticated-users-by-default-using-fallback-policies-in-asp-net-core/

Playwright

Playwright is a Node library to automate the Chromium, WebKit and Firefox browsers. This includes support for the new Microsoft Edge browser, which is based on Chromium.

Link: https://github.com/microsoft/playwright/blob/master/README.md

The F# Path to Relaxation – and what it means for .NET

After all the talk this week about .NET and it’s liveliness, I recommend watching this talk, re: memetic independence

Link: https://www.youtube.com/watch?v=ZTbyKsw7uIU

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Event Versioning Guidelines

Event Versioning Guidelines

This post serves as a guideline for how to handle versioning for messages, specifically in most cases, events. This Event Versioning Guidelines post is in a series related to messaging. You can find the overview in my Message Properties post.

Backward Compatible

Generally, adding additional properties to an event will not cause a versioning conflict with the event consumer.

Meaning if we have a contract that defines the shape of our event, as long as we don’t break that contract, the existing event consumers will be able to process our new event and will ignore the additional properties.

Also, if you are persisting events to an event/data store, you must be able to upcast an old stored event to our new version.

This isn’t that crazy of a concept. If you think about a relational database, when you need to add a new column, you generally will create the new column as having a default NULL value. The difference is you won’t backfill the existing events by replacing NULL with an actual value. Rather you handle the NULL value in your application code.

If you must change the contract, then you must create a new version of that event and cause a breaking change.

Version Number

One option for defining a new event is to include a version number within the event itself. Event consumers can then use this version number to determine how they should handle or process the event.

Regardless of backward compatibility, you can use a version number alongside your event name to indicate to consumers which contract to an event they are processing.

As an example using Semantic Versioning to define our events:

New Event

Most of the time if an event is not backward compatible, you likely have an entirely new event. And because of this, the name of the new event is likely different from the old event.

What’s tricky is to determine if this new event replaces the old event. Is the new event a discovery of an actual business event or is it simply a new understanding that replaces an existing concept?

Double Publish

If an event isn’t backward compatible, you might want to publish both v1 and v2 of the event that occurred.

Meaning the publisher writes both versions (v1 and v2) to the message queue or event stream.

One issue with this approach is consumers must understand this. They must understand they should only process one or the other. They either must process v1 and ignore v2, or process v2 and ignore v1.

This isn’t that big of a deal when the consumers aren’t replaying (re-processing) existing events from an event store. If you are using an event store and replaying events for a projection, you likely do not want to double publish. The reason being is processing both could have a negative impact.

If you’re not replaying events, then you’re consumers have to implement the new version you’re publishing. At the same time, they can remove the handling of the old event.

It’s not that odd to double publish by creating a new event and deprecate an old event and remove it once all consumers have handled the new event.

Event Versioning Guidelines

If you have any additional event versioning guidelines that I have omitted, please let me know on Twitter or in the comments.

Related Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #64: Migrate from JSON.NET to System.Text.Json, Endpoint Debugging, ToQueryString, CreateDbCommand

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

How to migrate from Newtonsoft.Json to System.Text.Json

This article shows how to migrate from Newtonsoft.Json to System.Text.Json.

System.Text.Json focuses primarily on performance, security, and standards compliance. It has some key differences in default behavior and doesn’t aim to have feature parity with Newtonsoft.Json. For some scenarios, System.Text.Json has no built-in functionality, but there are recommended workarounds. For other scenarios, workarounds are impractical. If your application depends on a missing feature, consider filing an issue to find out if support for your scenario can be added.

Link: https://docs.microsoft.com/en-gb/dotnet/standard/serialization/system-text-json-migrate-from-newtonsoft-how-to

Endpoint Debugging in ASP.NET Core 3 Applications

Nothing can be more frustrating than going into a situation “thinking” you know how a framework works, only to spend the next several hours pulling your hair out and stewing in a pot of unhealthy feelings. I like to consider myself an ASP.NET routing expert with my experience dating back to MVC 1.0. Recently, I’ve started using ASP.NET Core Razor Pages mixed in with MVC and API approaches. I find the combination of all this technology to be a winning one, but it can also add complexity when building views. In this post, I’ll show you a simple one page Razor Page that can help diagnose route resolution issues quickly. Quickly see what your ASP.NET Core application sees and what it requires to resolve routes.

Link: https://khalidabuhakmeh.com/endpoint-debugging-in-asp-dot-net-core-3-applications

Introducing EF Core 5 Features: Using ToQueryString to get generated SQL

EF Core 5.0 introduces the ToQueryString extension method which will return the SQL generated by EF Core when executing a LINQ query.

Link: https://blog.oneunicorn.com/2020/01/12/toquerystring/

CreateDbCommand: I’ll see your string and raise you a command…

Instead, EF Core 5.0 introduces CreateDbCommand which creates and configures a DbCommand just as EF does to execute the query.

Link: https://blog.oneunicorn.com/2020/01/15/createdbcommand/

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.