In Azure Service Bus scenarios, a descriptive IAzureServiceBusMessageRouter implementation can be injected into your function, which gives you access to the message routing and by extension your registered message handlers.
The code described here is an exact implementation of what is available in the new Arcus Azure Functions Service Bus project templates. We have one for both Azure Service Bus queue and Azure Service Bus topic subscription.
Remove exception details from health report in Web API project template
The OpenAPI documentation is by default available in the Web API project template (but can be excluded if needed). Adding the OpenAPI documentation to your API also means that the API models used during request/response will be externalized in the OpenAPI endpoint JSON. It was by inspecting this OpenAPI documentation that we saw a problem with the default application health endpoint that is available in the Web API project template. This endpoint used Microsoft’s HealthReport model which can include exception details when the application is unhealthy. Generating the OpenAPI document caused failures because the exception details could contain possible internal type information which resulted in an enormous amount of types that needed to be included in the document. Moreover, from a security perspective, this is not a good approach because it leaks information about the internal system. It could even leak application types that aren’t used in the API.
We solved this problem by adding a custom API model to the template. This custom model is an exact copy of Microsoft’s HealthReport except that it doesn’t contain any exception details. It still has a description, data and tags to inform the user why the application is healthy or not, but it doesn’t burden the recipient with internal information.
The health endpoint available in the Web API project template uses this new API model as a way to expose the application’s health. For more information on the Web API project template, see our official documentation.
If we decide to change this strategy, we couldn’t provide support to consumers who already ran the template in their project. A previous Web API release made sure that our JSON serialization strategy is accessible through the MVC options, which makes it not only cleaner but more maintainable.
The code sample is the actual result of how the Web API project template now handles JSON serialization. As you can see, it is a much cleaner and safer approach. For more information on the Web API project template, see our official documentation.
.NET 6 support
The v0.8 Templates end the long journey of adding .NET 6 support to Arcus. All of the dependent libraries were already targeting both .NET Core and .NET 6, but now the template projects are also fully .NET 6 compatible. Unlike the libraries, the templates don’t require multi-target support, so the .NET 6 features can be used freely.
We’ve learned a lot by adding this kind of widespread support to Arcus and plan to use that knowledge in the future when .NET 7 arrives.
Conclusion
The Templates v0.8 release was much-requested. It took us some time to fully make these project templates not only .NET 6 compatible, but to use the latest features and Arcus changes from dependent libraries. Now, these templates are finally finished and can be used in your next project.
See our official documentation for more information on all the currently-supported features. If you have any questions, remarks, comments, or just want to discuss something with us, feel free to contact the Arcus team at Codit.
Thanks for reading!
-Arcus team
Subscribe to our RSS feed