The art of simplicity

Yesterday I shared how to create your C# data contracts from an available JSON schema. In that post I demonstrated Quicktype as a way to generate those contracts. There was only one disadvantage when using Quicktype; it only supports Newtonsoft.Json . Today I want to have a look at an alternative that does have support for System.Text.Json. Introducing NJsonSchema After looking around on Github I found NJsonSchema for .NET : NJsonSchema is a .NET library to read, generate and validate JSON Schema draft v4+ schemas. The library can read a schema from a file or string and validate JSON data against it. A schema can also be generated from an existing .NET class. With the code generation APIs you can generate C# and TypeScript classes or interfaces from a schema. It offers multiple features: Read existing JSON Schemas and validate JSON data Generate JSON Schema from an existing .NET type Generate JSON Schema from sample JSON data Generate C# and TypeScript cod

I’m having fun creating a small open-source project(more about that later). In a part of this project I need to integrate with an existing API. I first started by browsing through the API documentation and use that to build my data contract classes in C# until I discovered that a JSON schema document was provided. In this post I want to show you can use this JSON schema document to generate the C# classes instead of writing them from scratch JSON schema Before I show you how to generate the C# code, I want to take a small detour and give you some more details about JSON schema itself. Let’s have a look how it is explained on the json-schema.org website itself: JSON Schema is a vocabulary that allows you to annotate and validate JSON documents. If you have ever used SOAP services in a previous life, JSON Schema can be compared to the WSDL documentation that was available there. It gives you an concise and easy way to describe your data format, provides you all the meta

I'm having fun creating a small open-source project(more about that later). In a part of this project I need to integrate with an existing API. Of course I want to have the necessary integration tests that help me verify if the integration with this API works correctly. There is only one problem, I need to pass an API key to call this API. How can I safely use and store this API key in my tests without checking the key in as part of my source code? ASP.NET Core Secret Manager In your ASP.NET Core application self you can use the Secret Manager Tool. This tool allows you to store your secrets in a separate location from the project tree. This guarantees that the app secrets aren’t checked into source control. The Secret Manager tool hides implementation details, such as where and how the values are stored. The values are stored in a JSON file in the local machine's user profile folder. For example on Windows: %APPDATA%\Microsoft\UserSecrets\<user_secrets_id>\secret

As an architect, I want to give my teams as much freedom as possible and trust them to take responsibility. Of course this should be balanced with the business and architectural goals. So how can you achieve this? Let me explain on how I like to tackle this... The paved road The way I use to lead my teams in the right direction is through a ‘paved road’. This means I’ll provide them a default stack that is easy to use with a lot of benefits, tools, documentation, support, … that help them during there day-to-day job. They can still go offroad if they want to, but I found out it is a good way to create alignment as much as possible without the teams losing their autonomy. It is also a good way to avoid the ‘ivory tower architecture’ and it leaves space for experimentation and improvements. Some things I typically provide as part of the paved road: A default application architecture: a template solution, starter kit or code generator that helps you to setup a default

I'm having fun creating a small open-source project(more about that later). In a part of this project I need to integrate with an existing API. Here is (part of) the JSON schema that describes the data contract: As you can see I need to specify a timestamp value which should be provided as a number. The description adds some extra details: A number representing the milliseconds elapsed since the UNIX epoch. Mmmh. The question is first of all what is the UNIX epoch and second how can I generate this number in C#? Let’s find out! The UNIX epoch The Unix epoch is the time 00:00:00 UTC on 1st January 1970. Why this date? No clue, it seems to be just an arbitrary date. It is used to calculate the Unix time. If you want to learn more, check out Wikipedia . Get number of milliseconds since Unix epoch in C# Now that we now what the UNIX epoch is, what is the best way to calculate the number of milliseconds since Unix epoch in C#? You can start to calculate this

Last week I introduced RabbitMQ streams and how you could produce and consume streams through the RabbitMQ.Stream.Client in .NET. Yesterday I showed how you can improve and simplify producing messages by using a Reliable Producer. Today I want to introduce its counterpart on the consumer side; the Reliable Consumer. Introducing Reliable Consumers Reliable Consumers builts on top of Consumer and adds the following features: Auto-Reconnect in case of disconnection Auto restart consuming from the last offset Handle the metadata Update Auto-Reconnect The Reliable Consumer will try to restore the TCP connection when the consumer is disconnected for some reason. Auto restart consuming from the last offset The Reliable Consumer will restart consuming from the last offset stored. So you don’t have to store and query the last offset yourself. Handle the metadata update If the streams  topology changes (ex:Stream deleted or add/remove follower), the client receiv