Azure Service Bus Explorer in Azure Portal

Until recently I used the Service Bus Explorer to debug and manage Azure Service Bus. But last week I noticed the following new menu item in Azure Service Bus:

To use the Azure Service Bus explorer, you need to navigate to the Service Bus namespace on which you want to perform send, peek, and receive operations. Then select either ‘Queues’ or ‘Topics’ from the from the navigation menu. After doing that you should see the ‘Service Bus Explorer’ option.

Following operations are supported:

• Queues
  • 'Send' to a queue
  • 'Receive' from a queue.
  • 'Peek' from a queue.
  • 'Receive' from DeadLetterQueue.
  • 'Peek' from the DeadLetterQueue.
• Topics
  • 'Send' to a topic.
• Subscriptions
  • 'Peek' from a subscription on a topic.
  • 'Receive' from a subscription.
  • 'Peek' from the DeadLetter subscription.
  • 'Receive' from the DeadLetter subscription.

To learn more about the Service Bus Explorer tool, please read the documentation.

Application Insights - Stop tracking 404 errors

By default Application Insights will log every 404 error in your web app as an error. I think this is a good default, but what if you don’t want to see these 404 errors?

There are 2 options to solve this:

• Through a Telemetry Processor
• Through a Telemetry Initializer

Telemetry Processor

A telemetry processor gives you direct control over what is included or excluded from the telemetry stream.

We can register our new TelemetryProcessor by using the AddApplicationInsightsTelemetryProcessor extension method on IServiceCollection, as shown below:

Telemetry Initializer

Telemetry initializers allow you to enrich telemetry with additional information and/or to override telemetry properties set by the standard telemetry modules. By default, any request with a response code >= 400 is flagged as failed. But if we want to treat a 404 as a success, we can provide a telemetry initializer that sets the Success property:

We can register the TelemetryInitializer in our Startup.cs:

Advantage of the Telemetry Initializer is that we still log the 404 event but no longer as an error.

More information: https://docs.microsoft.com/en-us/azure/azure-monitor/app/api-filtering-sampling

Sharing authentication ticket between .NET Core and ASP.NET (Owin)

By default authentication tickets cannot be shared between .NET Core and OWIN. The good news is that it is possible but we have to take some extra steps:

.NET Core App

On .NET Core side we have to change the cookie authentication middleware:

• The cookie name should match the name used by the OWIN Cookie Authentication Middleware (.AspNet.SharedCookie for example).
• An instance of a DataProtectionProvider should be initialized to the common data protection key storage location.

ASP.NET (OWIN) App

On ASP.NET (OWIN) side we have to install the Microsoft.Owin.Security.Interop package first.

Then we can change the cookie authentication middleware:

• The cookie name should match the name used by the ASP.NET Core Cookie Authentication Middleware (.AspNet.SharedCookie in the example).
• An instance of a DataProtectionProvider should be initialized to the common data protection key storage location.

ASP.NET Core–Set environment through the commandline

ASP.NET Core has built-in support for multiple environments. This makes it easy to load different configuration and apply different middleware depending on the environment.

The typical to control the environment we want to use is through the ASPNETCORE_ENVIRONMENT environment variable.

It is also possible to set the environment variable by passing it to the dotnet run command as an argument.

To set this up, we have to modify the Program.cs:

The AddCommandLine method allows us to read configuration values from the command line.

Now we can start the app with dotnet run --environment Development.

Using YARP to create a reverse proxy server

So far I’ve always used ProxyKit to create a reverse proxy in ASP.NET Core. But with the announcement of Yarp, it is time to try this alternative…

• I created a new ASP.NET Core “empty” project:

dotnet new web -n ProxyTest -f netcoreapp3.1
The template "ASP.NET Core Empty" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on ProxyTest\ProxyTest.csproj...
  Restore completed in 278,54 ms for C:\Projects\test\yarptest\ProxyTest\ProxyTest.csproj.

Restore succeeded.

• Next step is to reference the Microsoft.ReverseProxy preview nuget package:

<ItemGroup> 
  <PackageReference Include="Microsoft.ReverseProxy" Version="1.0.0-preview.1.*" /> 
</ItemGroup>

• Now it is time to update our Startup.cs. This is what I had when using Proxykit:

• And here is the updated Startup.cs after switching to Yarp:

• In Yarp everything is handled through configuration right now, so the real magic is there:

I'm curious on how this will evolve in the future...

GraphQL Inspector

While in traditional REST API’s versioning is a hot topic, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema. As GraphQL only returns the data that is explicitly requested, it becomes easier to introduce new functionality by adding new types and fields without introducing breaking changes. As you know what fields are used by which clients you can have a lot more knowledge in your hands to prevent breaking your clients.

For small schema’s it can be feasible to inspect your schema for changes manually but for larger schemas or federated schema’s good tooling becomes a necessity.

A tool that can help you to achieve this is GraphQL Inspector.

It offers the following (free) features:

• Compares schemas
• Detect breaking or dangerous changes
• Schema change notifications
• Use serverless functions validate changes
• Validates Operations and Fragments against a schema
• Finds similar / duplicated types
• Schema coverage based on Operations and Fragments
• Serves a GraphQL server with faked data and GraphiQL
• Docker Image

Getting started

To get started you have multiple items. You can use it as a Github application, a Github action but also as a commandline tool.

Let’s see how to use the commandline tool:

npm install --global @graphql-inspector/cli graphql

Now we can compare two schema’s:

graphql-inspector diff old.graphql new.graphql

Detected the following changes (2) between schemas:

√  Description was removed from field Post.createdAt
√  Field Post.createdAt changed type from String to String!
success No breaking changes detected

It is a must have for every GraphQL developer!

Hands-on-labs: App modernization

A colleague shared the following hands-on-lab with me: https://github.com/microsoft/MCW-App-modernization

It’s a great starting point to learn about the cloud and take your first steps towards it. It combines a whiteboard design session and a hands-on-lab.

This is wat you will design and build: