Roundup #61: .NET Core 3.1, AWS CDK, JetBrains Space, How Buildings Learn

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.

Announcing .NET Core 3.1

We’re excited to announce the release of .NET Core 3.1. It’s really just a small set of fixes and refinements over .NET Core 3.0, which we released just over two months ago. The most important feature is that .NET Core 3.1 is an long-term supported (LTS) release and will be supported for three years. As we’ve done in the past, we wanted to take our time before releasing the next LTS release. The extra two months (after .NET Core 3.0) allowed us to select and implement the right set of improvements over what was already a very stable base. .NET Core 3.1 is now ready to be used wherever your imagination or business need takes it.

Link: https://devblogs.microsoft.com/dotnet/announcing-net-core-3-1/

AWS Cloud Development Kit (CDK) – Java and .NET are Now Generally Available

Today, we are happy to announce that Java and .NET support inside the AWS Cloud Development Kit (CDK) is now generally available. The AWS CDK is an open-source software development framework to model and provision your cloud application resources through AWS CloudFormationAWS CDK also offers support for TypeScript and Python.

Link: https://aws.amazon.com/blogs/aws/aws-cloud-development-kit-cdk-java-and-net-are-now-generally-available/

JetBrains: Welcome to Space!

Today at KotlinConf, we announced our brand new product Space, and we have already opened the Early Access Program.

Space is an integrated team environment that provides teams and organizations with the tools they need to collaborate effectively and efficiently. It has Git-based Version Control, Code Review, Automation (CI/CD) based on Kotlin Scripting, Package Repositories, Planning tools, Issue Tracker, Chats, Blogs, Meetings, and Team Directory, among other features.

Link: https://blog.jetbrains.com/blog/2019/12/05/welcome-to-space/

How Buildings Learn

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

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Message Properties

Message Properties

Over the years I’ve learned various aspects of messaging either through using various products, reading other blogs, or unfortunately in a lot of cases, discovering them myself. One of those aspects is is message properties.

Specifically, (meta) data that you might want to include in your messages to solve some common problems.

My plan is to dive deeper with implementation examples for each topic listed in this post. Hopefully, this post can serve as a reference point to your adventures in messaging or possibly gain some insight that provides a solution for a pain point you may (already) be experiencing.

I was inspired to write this post after seeing this tweet:

Type/Name

The naming of messages is incredibly important for a variety of reasons. When talking about events, it’s important to name them in the past tense because it conveys that they are statements of fact.

Most often the name of an event is used to determine how to deserialize into a specific type. Where I’ve personally run into problems, in .NET specifically, is using the CLR type name as the event name to determine how to deserialize. The issue with this is you’re very likely to change the name of your CLR type.

Prefer to having a static name for an event and not using the CLR type name at runtime to create the event name.

Message Version

Most often when needing to version a message is to simply create a new type/name. With events, I think this approach works fairly well when you discover a better way to describe the event and along with it the data to expose.

When a new event isn’t required, but rather a slight change in data is to specify the version in the message. Consuming clients can use the message name along with the version to determine how to process the body of the message.

Message ID

A unique identifier of a message. This can be used for idempotency and concurrency. Message Handlerscan keep track of which messages IDs they have processed and determine if they should act upon receiving a message.

This is important because message handlers should be reentrant and messages can be delivered more than once.

Correlation ID

A unique identifier that allows you to reference the flow of events (event chain) or a transaction. Also, often called a Trace ID. Assigning a correlation ID as soon as possible and any message handler that receives a message with a correlation ID then uses that same ID for any messages it outputs.

This is very useful for logging and error handling in asynchronous and distributed environments.

Contract Owner

Who owns the message contract can be important. Depending on how messages are distributed, there may be many messages from various owners. Knowing who owns a message contract is helpful for troubleshooting as well as how to handle that message.

An OrderPlaced event seems like it could be unique across all services, however, in a distribution domain, is that a Sales OrderPlaced from the Sales service or a Purch OrderPlaced from the purchasing service?

Having the owner of the message provides the ability to distinguish how to handle the message when the name alone doesn’t provide enough distinction.

UTC Timestamp

This seems obvious but it gives more context to when the message was created. A useful is keeping track of latency between a message being created to how long it’s taking a given service to process it.

Sender

Who originated the message. Not the service, but rather the user. This could be an access token that is then used to determine if the sender has the correct permissions or is authorized to perform the given request.

Resource/Entity Version

The version of the resource/entity that you are performing an action on. Similar to the message ID this can be used for concurrency. A wonderful example of this is Azure Cosmos DB which uses an ETag as the resource version which is then used with an If-None-Match header for optimistic concurrency. If you’re using Cosmos DB check out my post on Optimistic Concurrency in Azure Cosmos DB

Message Properties

I’ll be going in-depth in each of the above topics with code examples for the actual implementation of how you would use these message properties. Stay tuned.

If you’d like to add to the list, let me know in the comments or on Twitter.

Related

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #60: gRPC vs HTTP APIs, .NET Perception, Rider, WebWindow

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.

gRPC vs HTTP APIs

ASP.NET Core now enables developers to build gRPC services. gRPC is an opinionated contract-first remote procedure call framework, with a focus on performance and developer productivity. gRPC integrates with ASP.NET Core 3.0, so you can use your existing ASP.NET Core logging, configuration, authentication patterns to build new gRPC services.

Link: https://devblogs.microsoft.com/aspnet/grpc-vs-http-apis/

Perception of .NET

I thought this thread was fascinating. Very interesting to read some of the responses.

Link: https://twitter.com/joepetrakovich/status/1195941775342493696

Rider with Kirill Skrygan

In this episode I interviewed Kirill about Rider and ReSharper from JetBrains. Some of you may know Kirill from his work on both the ReShrarper and Rider projects, and some of his work on the JetBrains open source projects.

Link: https://dotnetcore.show/episode-38-rider-with-kirill-skyrgan/

Meet WebWindow, a cross-platform webview library for .NET Core

My last post investigated ways to build a .NET Core desktop/console app with a web-rendered UI without bringing in the full weight of Electron. This seems to have interested a lot of people, so I decided to upgrade it to newer technologies and add cross-platform support.

The result is a little NuGet package called WebWindow that you can add to any .NET Core console app. It can open a native OS window (Windows/Mac/Linux) containing web-based UI, without your app having to bundle either Node or Chromium.

I’ve also decoupled it from Blazor. You can now host any kind of web UI inside the window. The repo contains a sample that uses Vue.js, and another that uses Blazor.

Link: https://blog.stevensanderson.com/2019/11/18/2019-11-18-webwindow-a-cross-platform-webview-for-dotnet-core/

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.