The art of simplicity

While browsing through Github, I discovered the following project: Data API builder for Azure Databases (DAB). With data API builder, database objects can be exposed via REST or GraphQL endpoints so that your data can be accessed using modern techniques on any platform, any language, and any device. With an integrated and flexible policy engine, native support for common behavior like pagination, filtering, projection and sorting, the creation of CRUD backend services can be done in minutes instead of hours or days, giving developers an efficiency boost like never seen before. Sounds cool and a perfect fit for a small application where you only need an API to expose some data. Let’s give it a try! Setup Data API builder provides a CLI tool to help us with the configuration and the setup of our project. Install the tool using the following command: dotnet tool install --global Microsoft.DataApiBuilder Now that the tool is installed successfully, we need to create a co

Although not everyone in my team would agree, I dare to say that building software is easy. The difficult part starts AFTER your first release when you need to start maintaining the application you've build while at the same time introducing new features, keeping the technical debt under control, evolve the application architecture under ever changing business needs and all of this at a minimal cost. Building software is easy During the lifetime of our application failures will happen. Although this is difficult to explain to our business stakeholders, failure in software is inevitable; people make mistakes, requirements are misunderstood, business needs change, … Rather than engaging in a man hunt to avoid failure, we embrace it and focus on learning from our mistakes. Embrace failure An important tool in our toolbox here is incident analysis ; we need to figure out what happened, what caused a failure and most important how we can improve. In the complex (distribu

While doing a code review I noticed the following code: In the code above we handle 2 exceptional cases. One specific case when the Task is cancelled and an OperationCancelledException is thrown. In that case we ignore the exception and decide to not log it anywhere (we can discuss if this is a good idea or not, but that is not what I want to talk about). And a second exceptional case when any other error type occurs we write it to our logs. Although there is nothing wrong with the code above, we can further simplify it by introducting an Exception Filter . This allows us to catch and handle exceptions based on requirements you define for the exception. These filters use the catch statement with the when keyword: Nice! Another trick I noticed in the documentation where exception filters are useful is when you want to examine all exceptions but not handle them. This is useful for example when you want to log the exception:

One ASP.NET Core feature that I really like and most people are not aware of it existence are Razor Class libraries (RCL). With RCL you can package Razor views, pages, Razor components and view components and reuse them in different applications. I blogged about RCL before and although I really like the feature I got feedback from my development teams that the behavior was not consistent and they sometimes couldn’t get it working. I never had time to really investigate the root cause until now. So this blog post is here to explain my findings. The development environment First of all it is important to understand that the behavior of RCL is different in Development compared to other environments. When running the app that uses the RCL from build output ( dotnet run ), static web assets are enabled that allow ASP.NET Core to load static web assets from locations outside the wwwroot. This is required because ASP.NET Core will load the assets directly from the RCL NuGet location.

These days, with Entity Framework Core being so good, it became rare that developers had to write their own SQL queries. Of course this is a great productivity one and even helps us to avoid security issues like SQL injection but this all comes with a cost. I noticed that most (junior) developers no longer are able to write anything but the most trivial SQL queries.  Time to fix that! If you want to sharpen your SQL skills, have a look at https://www.sql-practice.com/ . Here you  get a whole list of exercises that require writing SQL queries. If you get stuck hints are available that help you get on the right track:  

In Visual Studio 2022 v17.5, a new feature was introduced that allowed you to execute HTTP requests directly from the Visual Studio IDE. This is great of you want to test an API endpoint without leaving your IDE. To use this feature, open a Visual Studio project, right click on it and choose Add –> New Item . Search for http to find the HTTP file template , specify a name and click on Add . Now we can start writing our HTTP requests inside this file. You even get Intellisense while building up your requests. Once you are done, you can either click on the play icon next to the line or right click on the line and choose Send Request from the context menu. It is possible to have multiple calls in the same file, therefore separate your requests with a comment line using three hashes: You can also create variables by prefixing them with an @ and use these variables using double curly braces: