Roundup #37: .NET Core 1.x End of Life, gRPC, GraphQL, Benchmarking, Life Beyond Distributed Transactions

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

.NET Core 1.0 and 1.1 will reach End of Life on June 27, 2019

.NET Core 1.0 was released on June 27, 2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reach end of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.

After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.

Link: https://devblogs.microsoft.com/dotnet/net-core-1-0-and-1-1-will-reach-end-of-life-on-june-27-2019/

gRPC for dotnet

https://twitter.com/davidfowl/status/109287056804556800

We plan to implement a fully-managed version of gRPC for .NET that will be built on top of ASP.NET Core HTTP/2 server. Here are some key features:

– API compatible with the existing gRPC C# implementation (your existing service implementations should work with minimal adjustments)
– Fully interoperable with other gRPC implementations (in other languages and other platforms)
– Good integration with the rest of ASP.NET Core ecosystem
– High-performance (we plan to utilize some of the cutting edge performance features from ASP.NET Core and in .NET plaform itself)
– We plan to provide a managed .NET Core client as well (possibly with limited feature set at first)

We are committed to delivering the managed server experience Microsoft.AspNetCore.Server functionalities in ASP.NET Core 3.0 timeframe. We will strive to also deliver the mananged client experience in 3.0.

Link: https://github.com/grpc/grpc-dotnet/

Adding a GraphQL Endpoint to Your ASP.NET Core API

Since GraphQL support is not provided within ASP.NET Core, you need a Nuget package. The one most commonly used is simply called GraphQL .NET. Which is available as open source thanks to Joe McBride and all contributors. When you install the package GraphQL.Server.Transports.AspNetCore you’ll get it as a dependency as well as everything you need to hook in into ASP.NET Core. Now that we’re here I also install GraphQL.Server.Ui.Playgroundwhich will enable me to test the API in the way I did when I showed you the products query.

Link: https://rolandguijt.com/adding-a-graphql-endpoint-to-your-api/

Introduction to Benchmarking C# Code with Benchmark .NET

Once you have narrowed your focus to particular areas of your code you start to get down to the method level. At this point, it’s useful to begin recording more accurate and specific benchmarks for your existing methods and code. This is where benchmarking should become your tool of choice. In C# we have a fantastic option in the form of Benchmark.NET. This library provides a vast array of benchmark tooling that can be used to measure and benchmark .NET Code. Benchmark .NET is now regularly used by the teams at Microsoft to measure their code.

Link: https://www.stevejgordon.co.uk/introduction-to-benchmarking-csharp-code-with-benchmark-dot-net

Life Beyond Distributed Transactions: An Apostate’s Implementation – Jimmy Bogard

Over a decade ago, Pat Helland authored his paper, “Life Beyond Distributed Transactions: An Apostate’s Opinion” describing a means to coordinate activities between entities in databases when a transaction encompassing those entities wasn’t feasible or possible. While the paper and subsequent talks provided great insight in the challenges of coordinating activities across entities in a single database, implementations were left as an exercise to the reader!

Fast forward to today, and now we have NoSQL databases, microservices, message queues and brokers, HTTP web services and more that don’t (and shouldn’t) support any kind of distributed transaction.

In this session, we’ll look at how to implement coordination between non-transactional resources using Pat’s paper as a guide, with examples in Azure Cosmos DB, Azure Service Bus, and Azure SQL Server. We’ll look at a real-world example where a codebase assumed everything would be transactional and always succeed, but production proved us wrong! Finally, we’ll look at advanced coordination workflows such as Sagas to achieve robust, scalable coordination across the enterprise.

Link: https://www.youtube.com/watch?v=IMvrg0bN9-o

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #36: Server GC in a Small Containers, Simple-Exec, Why your ASP.NET Core Application Won’t Scale

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Running with Server GC in a Small Container Scenario Part 1 – Hard Limit for the GC Heap


I’ve checked in 2 configs related to specifying a hard limit for the GC heap memory usage so I wanted to describe them and how they are intended to be used. Feedback would be greatly appreciated.

In order to talk about the new configs it’s important to understand what consists of the memory usage in a process. When it comes to memory the terminology can be very confusing so it’s worth pointing out that by “memory” I meant private commit size. A process can have the following memory usage from the runtime’s POV:

-GC heap usage – this includes both the actual GC heap and the native memory used by the GC itself to do its bookkeeping;
-native memory used by other things in the runtime such as the jitted code heap;
-native memory used by something that’s not the runtime, eg, you are allocating native memory in your pinvoke calls;

We cannot control 3) and it could be significant. 2) is in general small compared to 1).

Link: https://blogs.msdn.microsoft.com/maoni/2019/02/04/running-with-server-gc-in-a-small-container-scenario-part-1-hard-limit-for-the-gc-heap/

simple-exec

SimpleExec is a .NET library that runs external commands. It wraps System.Diagnostics.Process to make things easier.

SimpleExec intentionally does not invoke the system shell.

The command is echoed to standard error (stderr) for visibility.

Platform support: .NET Standard 1.3 and upwards.

Link: https://github.com/adamralph/simple-exec

Why your ASP.NET Core application won’t scale – Damien Edwards, David Fowler

Hey my app doesn’t scale! ____ Framework sucks! Well, you can write a slow app in any language. David Fowler and Damian Edwards will show you why your app isn’t scaling and gives you the DOs and the DON’Ts of making big apps do big things in ASP.NET Core.

We’ll talk about async, parallelism, and appropriate use of multiple threads. Are you misusing some APIs and inadvertently crashing your apps?

David Fowler and Damian Edwards, will show you the errors of your ways and make sense out of these techniques and when they’re useful – or when they should be avoided.

This will be a demo-heavy and highly technical session.

Link: https://www.youtube.com/watch?v=-cJjnVTJ5og

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #35: Startup Hooks, HttpMaster, 7+M req/sec, Pre-Building Services, DockerComposeFixture

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

[C#] Have some fun with .net core startup hooks

One feature of .net core 2.2 that didn’t catch my mind immediately is the startup hooks. Put simply, this is a way to register globally a method in an assembly that will be executed whenever a .net core application is started. This unlocks a whole range of scenarios, from injecting a profiler to tweaking a static context in a given environment.

Link: https://medium.com/@kevingosse/c-have-some-fun-with-net-core-startup-hooks-498b9ad001e1

HttpMaster 4.3

Link: https://www.httpmaster.net/download

ASP.NET Core: Saturating 10GbE at 7+ million request/s

Looking at the latest run from the TechEmpower Benchmarks continuous results ASP.NET 2.2 is the 3rd fastest webserver (0.046% off the top spot); able to respond to 7 Million HTTP request per second

Link: https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/

Reducing initial request latency by pre-building services in a startup task in ASP.NET Core

This post follows on somewhat from my recent posts on running async startup tasks in ASP.NET Core. Rather than discuss a general approach to running startup tasks, this post discusses an example of a startup task that was suggested by Ruben Bartelink. It describes an interesting way to try to reduce the latencies seen by apps when they’ve just started, by pre-building all the singletons registered with the DI container.

Link: https://andrewlock.net/reducing-latency-by-pre-building-singletons-in-asp-net-core/

DockerComposeFixture

I happen to catch this twitter thread and noticed Khalid posted a link to this GitHub repo.

A XUnit fixture that allows you to spin up docker compose files and then run tests against them.

Link: https://github.com/devjoes/DockerComposeFixture

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.