The art of simplicity

After updating SignalR my program started to fail with the following error message: Access to XMLHttpRequest at 'http://localhost:22135/chat/negotiate?jwt=<removed the jwt key>' from origin 'http://localhost:53150' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute. To fix it I had to update the CORS policy by adding the AllowCredentials() method:

Tuesday I blogged about some breaking changes when updating the SignalR backend in ASP.NET Core. Later on I noticed I had to do some changes on the frontend as well: From: To:

Integration Testing can be quite cumbersome, especially when you have a lot of moving parts involved. To test my ElasticSearch code I was used to spin up a docker instance and discard it after the tests ran. Recently I changed my approach after receiving the following tip from a colleague(thanks Jasper!): https://github.com/poulfoged/elasticsearch-inside   ElasticSearch Inside is  a fully embedded version of Elasticsearch for integration tests. When the instance is created both the JVM and Elasticsearch itself is extracted to a temporary location and started. Once disposed everything is removed again. And despite what you may think, this happens really fast(a few seconds on my machine). How to Install the Nuget package: Install-Package elasticsearch-inside After that you have to create a new instance of the ElasticSearch class and wait for the Ready() method. using (var elasticsearch = new Elasticsearch()) { await elasticsearch.Ready(); } ...

I had to do some changes to one of our applications and noticed that it was still using the beta release of SignalR. So I thought it would be a good idea to quickly do an update to the release version. There were some breaking changes I was able to fix quite easily: From: To: From: To: From: To: From: To:

I’m spending a lot (read: “waaay to many”) time learning GraphQL. One of the things I had to figure out was how to use nullable types inside my GraphQL schema. By default when you use a nullable type inside your GraphQL schema, you get the following error message: ArgumentOutOfRangeException: Explicitly nullable type: Nullable<DateTime> cannot be coerced to a non nullable GraphQL type. To fix this, you have to expliclity specify the field as nullable in you GraphQL type definition:

I’m spending a lot (read: “waaay to many”) time learning GraphQL. One of the things I had to figure out was how to use Guids inside my GraphQL schema. On one of my projects we are using Guids. Here is the mapping I tried to use: When loading my GraphQL endpoint this resulted in the following error message: The type: Guid cannot be coerced effectively to a GraphQL type To fix it I had to explicitly specify the FieldType as IdType:

I’m spending a lot (read: “waaay to many”) time learning GraphQL. One of the things I had to figure out was how to expose exceptions. Out of the box you get a generic GraphQL exception, but if you want to drill down into what is going on, you have to change some configuration: I’m using https://github.com/graphql-dotnet/server to serve my ASP.NET Core GraphQL endpoint. When configuring the middleware you have to add a specific setting to activate exception details: