Implementing a bespoke authentication/authorisation service in .NET with using OpenIdDict library illustrating with samples on GitHub.

Practical approach to integration testing of the .NET + NoSQL bundle. Key features, examples and comparisons of RavenDB with other NoSQL engines.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

There is a .NET project. Running hundreds of SQL commands and queries. Mostly via an ORM. But occasionally doing the heavy lifting in carefully tuned high-performed SQL queries.
How to orchestrate automated tests against SQL Server for this project?

Multi-tenancy is never simple and can be addressed at different levels. Arguably, the most interesting solution would be where the app and the database both support multiple tenants. Here I bring this solution to the YABT project.

When a team produces an enterprise solution with a Single-Page Application (SPA) front-end and .NET Web API back-end, what are the options to host the two beasts?
Ultimately, we want to preserve the front-end bundle unchanged between environments, inject environment variables and have custom caching policies.

Marrying the flexibility of NoSQL entities for storing various sets of fields with strongly-typed .NET languages and powerful RavenDB indexing tools. Store custom fields, manage their C# structures and filter/search on them in the queries.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

Strategies for document identifiers in RavenDB (and NoSQL in general). Pros and cons of GUIDs, auto-incremented numbers, use of prefixes, ID masking and more.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

Practical modelling of a NoSQL database using the DDD (Domain Driven Design) practices to define the problem area (Bounded context) of the project, its domain entities and aggregates. Comparison to designing a relational model for a traditional SQL.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

NoSQL is not hard, it’s different. And to show that, RavenDB and I kick off a new series of articles dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

Five simple but often overlooked steps to provide a better experience to the devs using your NuGet package. Consider PDBs for the Symbol Server, Source Link integration, XML documentation, strong-named assemblies, CLS compliance and version managing.

A popular bundle of .NET + SPA framework (e.g. Angular, React, Vue) has a notorious problem of enforcing contracts between the back-end and the front-end. Among all solutions, code generation tools are particular tempting. And here is analysis of all the major players to get the job done: NSwag, Swagger Codegen, OpenAPI Generator, AutoRest, WebApiClientGen and TypeWriter (plus 2 extra tools with partial functionality).

Arguably, the Mediator pattern has become cool among the .NET devs when Jimmy Bogard released MediatR library 4 years ago. That library made words "Mediator" and "MediatR" interchangeable in the devs' lexicon. And as usual, trendy tools get often misused and applied without a second thought. Here I'm playing devil's advocate and look closely at its pros and cons. Is it still useful for modern .NET projects? May it become an anti-pattern one day as Service Locator did?

Having actively used RavenDB for a couple of years, I constantly get asked by other devs about feedback on the database. They usually expect to hear something simple and straightforward, like "love it" or maybe even "hate it", but my experience doesn't fall into any of these extremes. After 2 years I'm torn apart by polarised feelings about the database, and my expected-to-be-simple response turns into a long story about all the pros and cons, love and hatred. So here is my story.

Perhaps, Autofac is the most popular DI/IoC container for ASP.NET projects. But, since .NET Core has a pretty decent DI/IoC container, why would one still need Autofac? This is a story of gains and losses from switching a mid-sized project from Autofac to the standard .NET Core container.