Caching your static files in ASP.NET Core

In ASP.NET Core static files(images, css,…) are typically served using the Static file middleware. The static file middleware can be configured by adding a dependency on the Microsoft.AspNetCore.StaticFiles package to your project and then calling the UseStaticFiles extension method from Startup.Configure:

Unfortunately this code will not do its job in the most efficient way. By default, no caching is applied meaning that the browser will request these files again and again increasing the load on your server.

Luckily it’s not that hard to change the middleware configuration to introduce caching. In this example we set the caching to one day:

Remark: An alternative approach would be to let your proxy server(IIS,…) handle the static file requests as discussed here.

Guaranteeing “exactly once” semantics by using idempotency keys

A few weeks ago I had a discussion with a colleague about the importance of idempotency.

From http://www.restapitutorial.com/lessons/idempotency.html:

From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (no side effects), the response itself may not be the same (e.g. a resource's state may change between requests).

A good example where you can get into trouble is when your API withdraws some money from a customer account. If the user accidently calls your API twice the customer is double-charged, which I don’t think they’ll like very much…

A solution for this problem is the usage of idempotency keys. The idea is that the client generates a unique key that is send to the server along with the normal payload. The server captures the key and stores is together with the executed action. If a second requests arrives with the same key, the server can recognize the key and take the necessary actions.

What are situations that can happen?

• Situation 1 – The request didn’t made it to the server; in this case when the second request arrives the server will not know the key and just process the request normally
• Situation 2 –The request made it to the server but the operation failed somewhere in between; in this case when the second request arrives the server should pick up the work where it failed previously. This behavior can of course vary from situation to situation.
• Situation 3 – The request made it to the server, the operation succeeded but the result didn’t reach the client; in this case when the second request arrives the server recognizes the key and returns the (cached) result of the succeeded operation.

Note: Idempotency keys get important when you are running systems that are not ACID compliant. If you are running an ACID transactional system, you can just re-execute the same operation as the previous operation should be rolled back(or at least that’s the theory ).

Check compatibility between .NET versions

Compatibility is a very important goal of the .NET team at Microsoft. The team always made a great deal to guarantee that newer versions will not break previous functionality. However sometimes this is unavoidable to address security issues, fix bugs or improve performance.

To understand the consequences you have to make a difference between runtime changes and retargeting changes:

• Runtime changes: Changes that occur when a new runtime is placed on a machine and the same binaries are run, but expose different behavior
• Retargeting changes: Changes that occur when an assembly that was targeting .NET FW version x is now set to target version y. 

To help you identify possible compatibility issues, Microsoft created the .NET Compatibility Diagnostics, a set of Roslyn based analyzers.

Here is how to use them:

• First you have to choose if you want to check for Runtime changes or for Retargeting changes
• Now you need to select the ‘From .NET Framework version’ and the ‘To .NET Framework version’:

• After making your selection, you’ll get a list of all changes classified by their impact:

The state of Developer Ecosystem in 2017

JetBrains did a survey among 5000 developers to identify the current state of the Developer Ecosystem.

Here are some interesting facts that came out of it:

• Java is the most popular primary programming language
• JavaScript is the most used programming language
• Go is the most promising programming language
• Only 55% of the participants write unit tests
• 50% are full stack developers
• Of the C# developers 66% are using ASP.NET MVC
• Of the C# developers 92% use Visual Studio and only 3% use VS Code

Go explore all the results yourself at https://www.jetbrains.com/research/devecosystem-2017/

Improve your HTML and CSS editing skills in Visual Studio by using Emmet

Last week I discovered a great feature in VS Code that made my life so much easier; the support for Emmet snippet extension.

If you don’t know Emmet I suggest having a look at the demo at https://docs.emmet.io/first……………………… convinced? Let’s show you how this works in VS Code:

• Open an HTML file inside VS code:

• Type a snippet using the Emmet abbrevations:

• Hit ‘Tab’ and let the magic happen:

Type check your JavaScript files

Starting from TypeScript 2.3 you can not only use the type checking and error reporting features of TypeScript in your .ts files but also in your .js files as well.

This new feature is an opt-in option that can be enabled by adding the --checkJs flag. this will enable type checking for all .js files by default.  Open your tsconfig.json file and add the following line “checkJs”:true :

If you now create a JavaScript file and introduce a type checking error, you’ll get a nice error message from the TypeScript transpiler;

By default setting this flag will enable this feature for all your .js files. It is still possible to selective include/exclude specific files/lines by using any of the following comments;

• Use // @ts-check to enable type checking for a single file.
• Use // @ts-nocheck to disable type checking for a single file.
• Use // @ts-ignore to disable type checking for a single line.

SwashBuckle: Add support for operation overloading

By default SwashBuckle, doesn’t handle overloaded controller methods very well. A solution is the usage of an OperationFilter that changes the operationname in the UI:

Next step is to add this OperationFilter to your Swagger configuration: