I’m pretty late to the C# source generator party, but hey, better late than never 😅. In this post, let’s take a look at how we can automagically map minimal API endpoints using C# source generators
I’ve been using C# records a lot since the feature was introduced. However, when using them, we really need to understand how they work, otherwise we might face unexpected surprises.
Another video on using change data capture (often referred to as CDC), to hook up into the database transaction log, forwarding incoming entries to the outbox table.
I’ve been noticing in recent chats that folks have difficulty explaining why do we use async/await, tasks and related, when building ASP.NET Core applications.
Wanted to very briefly share a tool I’ve come across a couple of months ago: DevToys.
Time for one more video on messing with System.Text.Json, this time to get polymorphic (de)serialization going.
Let’s take a quick look at OpenAPI extensions (which I discovered were a thing last week 😛) and how to add them to our API description using ASP.NET Core and Swashbuckle.
Ah, the joys of integrating with third-party APIs… We always end up having to hammer something to get things working 🤣. This is a post about one of such situations, resorting to some JSON deserialization trickery (via JsonConverter) to be able to get things working.
Quick video with an interesting approach to implement the publisher part of the outbox pattern. Using change data capture (often referred to as CDC), we hook up something to the database transaction log, forwarding incoming entries to the outbox table. In this example, we’ll make use of Debezium, hooked up into a PostgreSQL database, forwarding messages to Kafka.
This is a tale of a good amount of hours of wasted time, so I’m going to document it so I remember it in the future. The idea is simple: when building an API, how can we treat a complex type as a simple type, to avoid things like primitive obsession, implement strongly typed ids and other related patterns? Let’s find out! 🙂