Output Caching gRPC is Bad Idea

In this post I investigate how to enable ASP.NET Core's Output Caching for an ASP.NET Core gRPC service. Primarily, this is done for the sake of curiosity. The concept, design and code below should be avoided in production grade applications.

Output Caching

Output caching is a new type of caching introduced with ASP.NET Core 7.0. It positioned between response caching and in-memory (or distributed) caching. With output caching the server responses are cached on the server. However, it gives less flexibility on choosing custom keys or caching strategy compared to in-memory caching provided by .NET runtime.

Output cache varying allows caching based on keys composed from query parameters, header parameters or by chosen value given the HTTP request. While output cache provides features like cache revalidation and cache invalidation, in this post I will not explore them in detail. Output caching is typically used for caching Razor pages, static HTML content, etc. in GET and HEAD HTTP requests. The default output caching policy behavior bypasses caching responses for authenticated requests or responses that sets cookies.

Find out more

Required Keyword

C# 11 introduces a new keyword: required. This keyword can be applied onto fields or properties to make them required to be set during initialization. In this post I will focus on using required properties.

In the past developers could create init properties that could be set only at initialization time by the type's constructor or object initializer. However, the compiler did not require the developer to explicitly set a value to a property.

Required properties make object initializers issue a compiler error when the developer does not set a required property.

In this post I will explore the following topics for required properties:

Find out more

ASP.NET Core and Http2, Http3, gRPC

This post is a quick lap around using http2 and http3 and gRPC endpoints with ASP.NET Core.

ASP.NET Core's Kestrel host on .NET 7 supports hosting endpoints with http1, http2 and http3 protocols. We can host gRPC endpoints with ASP.NET Core both using http2 and http3.

The two questions I would like to answer:

  • can we host http2 without SSL?

  • how to invoke an http2 endpoint without SSL?

  • how http3 REST performance compares with gRPC over h2?

Find out more

Meadow Getting Started

I have acquired a ProjectLab device with Meadow from Wilderness Labs. This post describes how to set up a development environment on Windows for such a device.


Install the latest .NET SDK. In my case at the time of writing, I am testing with .NET 8 Preview 3, hence that is installed my machine.

Next install the Meadow dotnet CLI. It is a dotnet tool, so we can install it as:

Find out more

Singletons with DI Container

A typical discussion topic about Dependency Injection (DI) Containers is creating singleton classes. Although many discussions come to the conclusion that the singleton pattern can be converted directly to singleton with a DI container, that is not entirely true.

First concern is that many DI containers support creating a child or scoped containers. Singleton registrations are instantiated with different rules based on the contract of the container. In that case it is possible that a child container creates its own singleton instance - but this is generally not the case. Today most containers differentiate scoped registrations from singletons to handle this case.

Second concern is that most DI containers require the user to implement the singleton type with a public constructor. This ensures that the DI container can invoke the constructor. However, it also implies that any user code may just as well instantiate further objects from the type. Even worse, the declaration of the type does not reflect its intended use.

The third concern is that a user can create multiple DI containers in an application. Each container can have its own singletons, as nothing restricts not to register the same (singleton) type with multiple containers.

Find out more