Fast-forward to today and think about artificial intelligence. Chatbots draft contracts, cars drive themselves, and image tools create pictures that look real, all in a matter of seconds. The technology feels just as magical as steam engines must have felt in 1830, and it’s spreading just as quickly. But, like those early trains, AI can harm us in ways most of us don’t yet see. A language model can invent fake legal cases that fool a lawyer, a driverless car can misread a street and cause a crash, and a cloned voice can trick a parent into sending money to a scammer. The systems keep learning and scaling, yet we still don’t fully understand how or why they sometimes fail. That puts us in a Parkside moment of our own: we’re standing on the tracks, taking selfies, while an invisible locomotive comes around the bend. If we want the benefits of AI without the horror story, we need the modern versions of fences and signals. Independent testers should stress-check new models before they go public; clear rules must spell out who is responsible when things go wrong; and high-risk uses—health care, finance, critical infrastructure—should require certified operators who actually know what they’re turning loose. Good regulation isn’t a buzz-kill; it’s the safety net that lets everyone ride with confidence. The railway age only took off after people saw the danger and fixed it; AI will be no different, unless we ignore the warning and find ourselves repeating Huskisson’s tragic lesson.

1. Retrieval: Finding the most relevant context from a large dataset or knowledge base.

2. Generation: Using the retrived information as input to a generative AI model to produce a coherent and meaningful response.

RAG's strength lies in its ability to combine external knowledge with a pre-trained model's language capabilities, ensuring outputs that are contextually relevant.

How Retrieval Works: Vector Space and Semantic Search

The retrieval process in RAG relies heavily on vector representations and similarity search within a vector space. Here's how this works:

1. Embedding the Query:

   • When a user submits a query, it is transformed into a high-dimensional vector(see the diagmra below) representation using a pre-trained embedding model (e.g., OpenAI's embeddings).

   • These embeddings encode the semantic meaning of the query into a numerical format.

2. Knowledge Base Embedding:

   • The documents or data within the knowledge base are also preprocessed and stored as vectors in a vector database (e.g., Pinecone or Supabase).

   • Each document or chunk (There are several chunking strategies. our framework uses the best combination for the given knowledge data) of text is represented by its semantic vector, ensuring that documents with similar meanings are clustered together in the vector space.

3. Similarity Search:

   • The system calculates the similarity between the query vector and the document vectors using cosine similarity or other distance metrics.

   • Documents with the highest similarity scores are retrieved as the most relevant context.

4. Fine-Tuning Retrieval:

   • Advanced implementations include dense passage retrieval (DPR) or hybrid retrieval (combining semantic and keyword-based search) to enhance accuracy, which me can consider for scenarios where accuracy is critical.Benefits of Using Vector Space Retrieval

Using vector space retrieval offers several advantages:

1. Semantic Understanding: Unlike keyword-based systems, vector representations capture the meaning of text, ensuring retrieval is based on context rather than exact matches.

2. Scalability: Vector databases handle large-scale document collections efficiently, enabling rapid retrieval even in massive datasets.

3. Domain Adaptability: By fine-tuning embeddings, vector space retrieval can be tailored for specific industries or use cases

Infonex RAG framework

At Infonex, we have created a RAG framework that simplifies data chunking through vectorization and enables seamless retrieval using semantic search. This framework offers efficient and flexible chunking strategies. By pre-training it with your company's knowledge base, you can leverage its easy-to-integrate library for streamlined data management. If you'd like more information or need assistance implementing a similar strategy for your company’s data, feel free to email us at team@infonex.com.au or reach out on X (formerly Twitter) at @ludmal.

See our RAG Product here:
https://index.lightspire.ai

Conclusion

RAG is a sophisticated AI framework that bridges the gap between static pre-trained models and real-time, dynamic information retrieval. By leveraging vector spaces for retrieval and generative models for response crafting. Infonex RAG framework capable of delivering accurate, context-aware, and up-to-date answers, making them indispensable for applications like customer support, knowledge management, and specialized domains.

Table of Contents

1. What is Event-Driven Architecture?

2. Key Components of Event-Driven Microservices

3. Benefits of Event-Driven Architecture

4. Implementation of Event-Driven Microservices in .NET

• Step 1: Setting up a Publisher Microservice

• Step 2: Creating a Consumer Microservice

• Step 3: Event Handling and Event Bus (RabbitMQ Example)

5. Error Handling and Message Reliability

6. Conclusion

1. What is Event-Driven Architecture?

In an event-driven architecture, services communicate by producing and consuming events. This architecture decouples microservices, allowing them to interact asynchronously. When a microservice performs a significant action, like creating a new order or completing a payment, it can publish an event. Other microservices that are interested in this event can then react accordingly without knowing the details of the event producer.

Example:

In an e-commerce application, the OrderService may publish an event like OrderCreated. Other services like InventoryService and BillingService can subscribe to the event and update stock levels or process payments, respectively.

2. Key Components of Event-Driven Microservices

Event-driven microservices architecture is based on three key components:

1. Event Producers: These are the microservices that create and publish events. For example, when a new order is created, the OrderService publishes an OrderCreated event.

2. Event Consumers: These microservices listen for events and react to them. For example, InventoryService listens to OrderCreated events and reduces the inventory of the ordered product.

3. Event Bus: This is the communication channel through which events are transferred. Event buses like RabbitMQ, Azure Service Bus, or Kafka act as the middleware between the producer and consumer.

3. Benefits of Event-Driven Architecture

1. Loose Coupling: Producers and consumers are decoupled. They do not need to know about each other, making the system more modular and easier to maintain.

2. Scalability: Asynchronous messaging allows microservices to scale independently.

3. Resilience: Failures in one service do not block others. Consumers can handle events at their own pace.

4. Extensibility: New services can be added without modifying the existing ones.

4. Implementation of Event-Driven Microservices in .NET

Let's now implement an event-driven architecture in .NET using RabbitMQ as the event bus. We will have two services: OrderService (Publisher) and InventoryService (Consumer).

Step 1: Setting up a Publisher Microservice (OrderService)

In this step, we’ll create the OrderService, which will publish events when an order is created.

Code Example: OrderService (Event Publisher)

1. Install necessary RabbitMQ NuGet packages:

   dotnet add package RabbitMQ.Client

2. Define the event model:

   public class OrderCreatedEvent
   {
       public int OrderId { get; set; }
       public string ProductName { get; set; }
       public int Quantity { get; set; }
   }

3. Publish an event to RabbitMQ

using RabbitMQ.Client;
using System.Text;
using Newtonsoft.Json;

public class EventPublisher
{
    public void PublishOrderCreatedEvent(OrderCreatedEvent orderEvent)
    {
        var factory = new ConnectionFactory() { HostName = "localhost" };
        using (var connection = factory.CreateConnection())
        using (var channel = connection.CreateModel())
        {
            channel.ExchangeDeclare(exchange: "order_exchange", type: "fanout");

            var message = JsonConvert.SerializeObject(orderEvent);
            var body = Encoding.UTF8.GetBytes(message);

            channel.BasicPublish(
                exchange: "order_exchange",
                routingKey: "",
                basicProperties: null,
                body: body);

            Console.WriteLine($"[x] Published OrderCreatedEvent for OrderId: {orderEvent.OrderId}");
        }
    }
}

4. Trigger event when an order is created:

public class OrderService
{
    private readonly EventPublisher _eventPublisher = new EventPublisher();

    public void CreateOrder(int orderId, string productName, int quantity)
    {
        // Business logic for order creation
        var orderCreatedEvent = new OrderCreatedEvent
        {
            OrderId = orderId,
            ProductName = productName,
            Quantity = quantity
        };

        _eventPublisher.PublishOrderCreatedEvent(orderCreatedEvent);
    }
}

Step 2: Creating a Consumer Microservice (InventoryService)

Next, we’ll create the InventoryService that listens to OrderCreated events and updates inventory.

Code Example: InventoryService (Event Consumer)

1. Install the RabbitMQ package (same as the publisher).

2. Set up the consumer to subscribe to the RabbitMQ queue:

using RabbitMQ.Client;
using RabbitMQ.Client.Events;
using System.Text;
using Newtonsoft.Json;

public class EventConsumer
{
    public void ConsumeOrderCreatedEvent()
    {
        var factory = new ConnectionFactory() { HostName = "localhost" };
        using (var connection = factory.CreateConnection())
        using (var channel = connection.CreateModel())
        {
            channel.ExchangeDeclare(exchange: "order_exchange", type: "fanout");
            var queueName = channel.QueueDeclare().QueueName;
            channel.QueueBind(queue: queueName, 
                              exchange: "order_exchange", 
                              routingKey: "");

            var consumer = new EventingBasicConsumer(channel);
            consumer.Received += (model, ea) =>
            {
                var body = ea.Body.ToArray();
                var message = Encoding.UTF8.GetString(body);
                var orderEvent = JsonConvert.DeserializeObject<OrderCreatedEvent>(message);
                
                // Handle the event (e.g., update inventory)
                Console.WriteLine($"[x] Received OrderCreatedEvent for OrderId: {orderEvent.OrderId}");
            };

            channel.BasicConsume(queue: queueName, 
                                 autoAck: true, 
                                 consumer: consumer);

            Console.WriteLine(" [x] Waiting for events...");
            Console.ReadLine();
        }
    }
}

3. Handling the event:

public class InventoryService
{
    private readonly EventConsumer _eventConsumer = new EventConsumer();

    public void StartListening()
    {
        _eventConsumer.ConsumeOrderCreatedEvent();
    }
}

Step 3: Running the Microservices

To run the services:

- Start the OrderService which creates an order and publishes an event.

- Start the InventoryService which listens to the event and processes it.

class Program
{
    static void Main(string[] args)
    {
        var orderService = new OrderService();
        orderService.CreateOrder(1, "Laptop", 5);

        var inventoryService = new InventoryService();
        inventoryService.StartListening();
    }
}

5. Error Handling and Message Reliability

In a real-world scenario, robust error handling and ensuring message delivery are essential. Here are some common strategies:

• Retries: Use retries in case of failures when processing events.

• Dead Letter Queues (DLQ): Messages that fail repeatedly can be moved to a DLQ for later inspection.

• Idempotency: Ensure that processing an event multiple times doesn't cause issues (e.g., reduce stock only once per order).

You can implement retry logic and error handling using libraries like Polly in your microservices to ensure resilience.

Policy

   .Handle<Exception>()
   .Retry(3)
   .Execute(() => { /* Process event */ });

6. Conclusion

Event-driven microservices architecture in .NET allows for building highly decoupled, scalable, and resilient systems. By leveraging message brokers like RabbitMQ, services can communicate asynchronously without tightly coupling themselves. This architecture also simplifies the addition of new features without requiring changes to existing services.

In this post, we demonstrated how to implement a basic event-driven microservice architecture in .NET using RabbitMQ. With concepts like retries, dead-letter queues, and idempotency, you can build a system that is not only scalable but also fault-tolerant. In the next blog post, we'll explore how to use the MassTransit library to simplify integration with various messaging services, while leveraging its built-in support for resilience, retries, and the outbox pattern.

Understanding Polly Retry Handler

The retry pattern is a simple yet effective way to handle transient failures. When a request fails, instead of immediately throwing an exception, the application waits for a short period and then retries the request. This can often resolve issues caused by temporary network glitches or brief service unavailability.

Polly's retry handler allows you to specify:

1. The number of retry attempts

2. The delay between retries (which can be fixed or can increase with each attempt)

3. The types of exceptions or return results that should trigger a retry

In our example, we're using an exponential backoff strategy, where the delay increases exponentially with each retry attempt.

Understanding Circuit Breaker Policy

The circuit breaker pattern prevents an application from repeatedly trying to execute an operation that's likely to fail. It's like an electrical circuit breaker: when a problem is detected, it "trips" and stops the flow to protect the system.

The circuit breaker has three states:

1. Closed: When everything is normal, the circuit is closed, and requests are allowed through.

2. Open: If the number of failures exceeds a threshold, the circuit opens, and requests are not allowed through for a certain period.

3. Half-Open: After the timeout period, the circuit switches to half-open, allowing a limited number of requests through to test if the problem still exists.

This pattern is particularly useful for preventing cascading failures in distributed systems.

Implementing Resilient HTTP Clients

Let's break down the code and see how we're implementing these patterns:

We need to install following nuget packages:

dotnet add package Polly
dotnet add package Microsoft.Extensions.Http.Polly

public static void AddResilientApiClient(this IServiceCollection services, ApiClientConfiguration apiClientConfiguration)
{
    services.AddHttpClient("ResilientHttpClient")
        .AddPolicyHandler(GetRetryPolicy(apiClientConfiguration))
        .AddPolicyHandler(GetCircuitBreakerPolicy(apiClientConfiguration));
}

This method extends IServiceCollection to add a named HttpClient with both retry and circuit breaker policies.

Retry Policy

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy(ApiClientConfiguration config)
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .WaitAndRetryAsync(
            config.RetryCount,
            retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt) * config.RetryAttemptInSeconds)
        );
}

This method creates a retry policy that:

• Handles transient HTTP errors (NetworkError, 5xx, and 408 status codes)

• Retries for a specified number of times

• Uses exponential backoff for the delay between retries

Circuit Breaker Policy

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy(ApiClientConfiguration config)
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .CircuitBreakerAsync(
            config.HandledEventsAllowedBeforeBreaking,
            TimeSpan.FromSeconds(config.DurationOfBreakInSeconds)
        );
}

This method creates a circuit breaker policy that:

• Handles the same transient HTTP errors as the retry policy

• Opens the circuit after a specified number of consecutive failures

• Keeps the circuit open for a specified duration before allowing a trial request

Usage

To use this resilient HTTP client in your application, you would typically:

1. Define your `ApiClientConfiguration` with appropriate values.

2. Call `AddResilientApiClient` in your service configuration.

3. Inject and use the named `HttpClient` in your services.

For example:

public class ApiClientConfiguration
{
    public int RetryCount { get; set; }
    public int RetryAttemptInSeconds { get; set; }
    public int HandledEventsAllowedBeforeBreaking { get; set; }
    public int DurationOfBreakInSeconds { get; set; }
}

services.AddResilientApiClient(new ApiClientConfiguration
{
    RetryCount = 3,
    RetryAttemptInSeconds = 2,
    HandledEventsAllowedBeforeBreaking = 5,
    DurationOfBreakInSeconds = 30
});

Then, in your service:

public class MyApiService

{
    private readonly HttpClient _httpClient;
    public MyApiService(IHttpClientFactory httpClientFactory)
    {
        _httpClient = httpClientFactory.CreateClient("ResilientHttpClient");
    }
    Use _httpClient for your API calls
}

Conclusion

By implementing retry and circuit breaker patterns with Polly, we can create more resilient applications that can better handle transient failures and prevent cascading failures in distributed systems. This approach not only improves the reliability of our applications but also enhances the user experience by reducing the impact of temporary issues.

Remember, while these patterns can significantly improve your application's resilience, they're not a silver bullet. It's important to combine them with other best practices such as logging, monitoring, and alerting to create truly robust systems.

This feature allows you to write more concise and readable code when working with collections. It eliminates the need for repetitive initialization code, making your code more efficient and easier to maintain. Here are some of the samples. Also note that ‘var’ cannot be used when declaring collections with the expressions.

//Before
var names = new List<string> { "bill", "steve", "mark", "elon" }

//After
string[] names = ["bill", "steve", "mark", "elon"];

//Before
var numbers = new List<int> { 1, 2, 3, 4, 5 };

//After
int[] numbers = [1, 2, 3, 4, 5];

The new syntax is much cooler and allows you to use the spread element, as shown below.

string[] names1 = ["bill", "steve", "mark", "elon"];
string[] names2 = ["bill", "steve", "mark", "elon"];
List<string> allNames = [..names1, ..names2];

Start utilizing these features to enhance the readability and elegance of your code.

Configuration management is a critical aspect of modern software development. It allows developers to externalize application settings and parameters, making it easier to change application behavior without modifying code. In the .NET ecosystem, managing configuration has been greatly simplified with the introduction of `IOptions`, `IOptionsMonitor`, and `IOptionsSnapshot`. In this blog post, we'll explore these powerful tools and provide practical examples of how to use them in C#.

IOptions

IOptions is part of the Microsoft.Extensions.Options library, which provides a framework for managing application configuration settings. It's a simple way to access configuration values in your application. To get started, you need to define a class representing your configuration:

public class AppSettings

{

    public string ApiKey { get; set; }

    public int MaxItemsPerPage { get; set; }

}

Next, you need to register this class and its associated configuration section in your program.cs:

services.Configure<AppSettings>(Configuration.GetSection("AppSettings"));

Now, you can use `Options to access these configuration values in your application:

public class SomeService

{

    private readonly IOptions<AppSettings> _appSettings;

    public SomeService(IOptions<AppSettings> appSettings)

    {

        _appSettings = appSettings;

    }

    public string GetApiKey()

    {

        return _appSettings.Value.ApiKey;

    }

    public int GetMaxItemsPerPage()

    {

        return _appSettings.Value.MaxItemsPerPage;

    }

}

IOptions provides access to configuration values during application startup, and the values are cached for the application's lifetime.

IOptionsMonitor

While IOptions is suitable for most scenarios, sometimes you need the ability to dynamically update configuration values without restarting your application. This is where IOptionsMonitor comes into play. It allows you to create a configuration that can be monitored for changes.

First, define your configuration class as before:

public class AppSettings

{

    public string ApiKey { get; set; }

    public int MaxItemsPerPage { get; set; }

}

Then, register the class and its configuration section in your program.cs, but this time, use IOptionsMonitor:

services.Configure<AppSettings>(Configuration.GetSection("AppSettings"));

services.AddSingleton<IOptionsMonitor<AppSettings>, OptionsMonitor<AppSettings>>();

Now, you can use IOptionsMonitor to access your configuration values:

public class SomeService

{

    private readonly IOptionsMonitor<AppSettings> _appSettings;

    public SomeService(IOptionsMonitor<AppSettings> appSettings)

    {

        _appSettings = appSettings;

    }

    public string GetApiKey()

    {

        return _appSettings.CurrentValue.ApiKey;

    }

    public int GetMaxItemsPerPage()

    {

        return _appSettings.CurrentValue.MaxItemsPerPage;

    }

}

With IOptionsMonitor, you can react to configuration changes in real-time without needing to restart your application.

IOptionsSnapshot

IOptionsSnapshot is yet another tool in your configuration toolbox. It provides a scoped view of configuration settings, ideal for short-lived operations or background tasks. To use it, follow the same setup as with IOptions:

public class AppSettings

{

    public string ApiKey { get; set; }

    public int MaxItemsPerPage { get; set; }

}

// program.cs

services.Configure<AppSettings>(Configuration.GetSection("AppSettings"));

Then, inject IOptionsSnapshot into your scoped components:

public class ScopedService

{

    private readonly IOptionsSnapshot<AppSettings> _appSettings;

    public ScopedService(IOptionsSnapshot<AppSettings> appSettings)

    {

        _appSettings = appSettings;

    }

    public string GetApiKey()

    {

        return _appSettings.Value.ApiKey;

    }

    public int GetMaxItemsPerPage()

    {

        return _appSettings.Value.MaxItemsPerPage;

    }

}

IOptionsSnapshot provides a snapshot of configuration values, which is scoped to the current request or operation. This is particularly useful in scenarios where you need a unique set of configuration values for each user or operation.

Conclusion

In this blog post, we've explored three powerful tools for managing configuration in .NET applications: IOptions, IOptionsMonitor, and IOptionsSnapshot. By understanding the differences and use cases for each of these, you can efficiently manage configuration settings in your C# applications. Whether you need cached values, real-time updates, or scoped configurations, these options have got you covered, helping you build more flexible and maintainable applications.

The pattern described here is widely recognized as one of the most commonly employed and elegant approaches for configuring settings. It has been extensively utilized in both internal .NET libraries and third-party libraries. This pattern can serve as a valuable guide when registering configurations in program or startup classes for your internal libraries. For instance, if you are developing a library and wish to allow client developers to configure options during startup, this pattern can be of great assistance.

To illustrate this concept, let's consider the hypothetical scenario of designing a ApiRetryOptions class with two retry options — MaxRetries & DelayInSeconds. Within this class, default values are assigned to the MaxRetries and DelayInSeconds properties.

public class ApiRetryOptions
{
    public int MaxRetries { get; set; } = 3;
    public int DelayInSeconds { get; set; } = 1000;
}

Next, we create an extension method for this class, enabling us to register it during startup:

public static class ApiRetryOptionsExtensions
{
    public static void AddApiRetryOptions(this IServiceCollection services, Action<ApiRetryOptions>? options = null)
    {
        if (options != null) services.Configure(options);
    }
}

When registering the class with the Service Collection, it is important to note the use of the Action delegate. In C#, an Action represents a method with no parameters and no return value. In this case, we require an Action delegate to be registered with the built-in service configuration. The .NET framework provides a convenient method called services.Configure(Action<>) that allows us to accomplish this, as demonstrated in the example above.

Now, let's proceed to register this configuration in the program class. The beauty of this pattern lies in its ability to facilitate easy configuration during startup for any library registration. In this example, we override the default values:

builder.Services.AddApiRetryOptions(options =>
{
    options.MaxRetries = 1;
    options.MaxRetries = 4000;
});

Finally, we can integrate this configuration into our client code using the IOptions class:

app.MapGet("/retry", (IOptions<ApiRetryOptions> retry) => retry.Value.MaxRetries);

By adopting this pattern, you can align your library configuration with the established conventions used in .NET libraries, thereby ensuring consistency and coherence.

Subscribe now

Ahead of Time Compilation (AOT) is a technology that has been gaining momentum in the world of software development, and .NET 8 brings exciting advancements in this area. AOT offers significant advantages in terms of performance and security, making it an essential feature for modern .NET applications. Let's explore AOT in .NET 8 and its benefits.

What is Ahead of Time Compilation (AOT)?

AOT is a compilation technique that converts high-level code, such as C# or F#, into native machine code before the application is run. Unlike Just-In-Time (JIT) compilation, which compiles code at runtime, AOT compiles code ahead of time, resulting in several advantages: 

Performance Boost: AOT-compiled code runs faster since it doesn't require runtime compilation. This leads to reduced startup times and improved overall application performance.

Predictable Behavior: AOT eliminates the JIT warm-up time, ensuring consistent and predictable application behavior across different executions.

Improved Security: AOT reduces the attack surface by removing the need for a JIT compiler at runtime, making it harder for attackers to exploit vulnerabilities.

.NET 8 introduces enhanced AOT support, making it easier than ever to leverage this technology in your applications. Here are some key improvements:

Single-File AOT: .NET 8 allows you to create single-file AOT-compiled applications, simplifying deployment and distribution.

Cross-Platform AOT: AOT is no longer limited to Windows. .NET 8 brings cross-platform AOT support, enabling AOT-compiled apps to run on various operating systems.

Improved Interoperability: .NET 8 enhances the interoperability between AOT-compiled code and JIT-compiled code, ensuring smooth integration of AOT into existing projects.

In .NET 8, AOT makes your software faster, safer, and works on different devices. I Love it since it makes the Minimal Apis even faster. 

Just a quick post on how to add api key validation in swagger docs. Pretty easy and here is the code to add in AddSwaggerGen in the program.cs file. You can define your own Api key validation middleware.

    builder.Services.AddSwaggerGen(c =>
    {
        c.AddSecurityDefinition("api_key", new OpenApiSecurityScheme
        {
            Type = SecuritySchemeType.ApiKey,
            Name = "Authorization",
            In = ParameterLocation.Header,
            Description = "API key needed to access the endpoints."
        });

        // Define your security requirement (optional)
        c.AddSecurityRequirement(new OpenApiSecurityRequirement
        {
            {
                new OpenApiSecurityScheme
                {
                    Reference = new OpenApiReference
                    {
                        Type = ReferenceType.SecurityScheme,
                        Id = "api_key"
                    }
                },
                new string[] { }
            }
        });
    });

I am thrilled to share with all of you a journey I've passionately embarked on – writing a book dedicated to the world of Minimal APIs with a functional approach. This book is not just a guide; it's a deep dive into the efficient and innovative world of Minimal APIs, explored through the lens of functional programming. I've poured my experience and insights into this work, aiming to offer a fresh perspective on building lean, effective APIs. Whether you're a seasoned developer or just starting out, this book promises to enrich your understanding and skills in creating powerful, minimalistic APIs with a functional twist. Stay tuned for more updates and snippets from my book!

Coming Soon!

It's crucial to effectively handle transient errors during message processing. Many developers often attempt to create their own solutions for this issue, but there is already an elegant, built-in solution in the Azure Service Bus client. The key is to create a RetryOption and pass it to the Service Bus client during its creation. This straightforward approach leverages the native capabilities of Azure Service Bus to manage transient errors efficiently.

builder.AddServiceBusClient(settings.ConnectionStrings.AzureWebJobsServiceBus).ConfigureOptions(options =>
    {
        options.RetryOptions = new ServiceBusRetryOptions()
        {
            Delay = TimeSpan.FromSeconds(30), MaxDelay = TimeSpan.FromSeconds(30),
            Mode = ServiceBusRetryMode.Exponential, MaxRetries = 3
        };
    });

Structured logging is an approach to logging that captures data in a way that's easy to parse and analyze, unlike traditional logging, which often involves plain text messages. In structured logging, log entries are composed of discrete fields, such as time stamps, log levels, messages, and other contextual information.

Here is an example:

_logger.LogInformation("Request received {@Request}", request);

Why it is important? Well there are few main reasons. 

Searchability and Filtering: Structured logs allow for easier searching and filtering since each part of the log message is a distinct field. This makes it straightforward to find all logs related to a specific event, error code, or user action. As you can see in the following example, logs are written in a json format where you can easily search. 

Performance: When you use structured logging with deferred execution, such as with Serilog or NLog, the actual string interpolation doesn't happen unless the log level is enabled. This means you avoid unnecessary string manipulation if, for example, your debug logs are turned off in a production environment.

Why you shouldn't use logging with string interpolation?

Utilizing string interpolation in logging compromises the capability to efficiently search or filter through log entries. Additionally, it necessitates memory allocation for each log entry created, due to the fact that, unlike structured logging, the template is not established at compile-time, resulting in potentially higher overhead and less optimal performance.

_logger.LogInformation($"Request received {JsonSerializer.Serialize(request)}");

In conclusion, it is imperative to exercise discretion when implementing structured logging, particularly to mitigate the risks of inadvertently logging sensitive information or excessively large objects. Developers have the capacity to introduce entire objects into the log data, which could lead to breaches of privacy, security concerns, and potential performance issues due to the increased size and complexity of the log data. Therefore, it is essential to establish and adhere to best practices regarding what data should be logged, ensuring that the logs remain informative and valuable without compromising security or performance.

With keyed services, developers can associate specific keys with particular service implementations, granting more fine-grained control over service retrieval from the IOC container. This means that when a consumer requests a service, it can specify a key to receive a particular implementation of the service interface. 

This flexibility is crucial for scenarios where multiple implementations of an interface exist, and the decision to use one over another is determined at runtime. Keyed services in .NET 8’s IOC container therefore facilitate a more dynamic, adaptable, and modular application architecture. 

Here is a simple example of the Keyed services

Multiple implementation for the same interface

 
        public interface IGreetingService
        {
            string GetGreeting();
        }

        public class EnglishGreetingService : IGreetingService
        {
            public string GetGreeting() => "Hello!";
        }

        public class SpanishGreetingService : IGreetingService
        {
            public string GetGreeting() => "¡Hola!";
        }

        //Register the implementation with a key

        builder.Services.AddKeyedSingleton<IGreetingService, EnglishGreetingService>("English");
        builder.Services.AddKeyedSingleton<IGreetingService, SpanishGreetingService>("Spanish");

        //Use the key to inject to the required functions
            app.MapGet("/greet", ([FromKeyedServices("English")] IGreetingService english,[FromKeyedServices("Spanish")]
        IGreetingService spanish) =>
        $"English:{english.GetGreeting()} Spanish: {spanish.GetGreeting()}").WithName("GreetingEndpoint");

Hope this helps!

Typically these requests are handled via Api Gateway policies. However, .Net provides build in middleware to handle this effectively.

    builder.Services.AddRateLimiter(r => r
        .AddFixedWindowLimiter(policyName: "fixed", options =>
        {
            options.PermitLimit = 4;
            options.Window = TimeSpan.FromSeconds(12);
        }));

    var app = builder.Build();
    app.UseRateLimiter();

    app.MapGet("/", () => Results.Ok($"Hello World"))
        .RequireRateLimiting("fixed");

With MediatR, you define requests as plain C# classes representing a unit of work or a command, and you create handlers to process these requests. The library then handles the routing and execution of the requests to their corresponding handlers.

One of the key features of MediatR is its support for pipelines. A pipeline in MediatR is a sequence of behavior or middleware that can be applied before and after the execution of request handlers. Each behavior in the pipeline can intercept and modify the request, perform additional processing, or handle cross-cutting concerns such as validation, logging, caching, or authorization.

Following code example shows a simple Logging and Exception handling pipeline for Medatr requests. 

public class AddUserCommand : IRequest<Unit>
{
public string Username { get; set; }
public string Email { get; set; }
}

public class AddUserCommandHandler : IRequestHandler<AddUserCommand, Unit>
{
private readonly IUserService _userService;

public AddUserCommandHandler(IUserService userService)
{
_userService = userService;
}

public Task<Unit> Handle(AddUserCommand request, CancellationToken cancellationToken)
{
_userService.AddUser(request.Username, request.Email);
return Task.FromResult(Unit.Value);
}
}

//Simple logging behavior
public class LoggingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
private readonly ILogger<LoggingBehavior<TRequest, TResponse>> _logger;

public LoggingBehavior(ILogger<LoggingBehavior<TRequest, TResponse>> logger)
{
_logger = logger;
}

public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next)
{
_logger.LogInformation($"Handling {typeof(TRequest).Name}");

var response = await next();

_logger.LogInformation($"Finished handling {typeof(TRequest).Name}");

return response;
}
}

//Simple Exception handling behavior
public class ExceptionHandlingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
private readonly ILogger<ExceptionHandlingBehavior<TRequest, TResponse>> _logger;

public ExceptionHandlingBehavior(ILogger<ExceptionHandlingBehavior<TRequest, TResponse>> logger)
{
_logger = logger;
}

public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next)
{
try
{
return await next();
}
catch (Exception ex)
{
_logger.LogError(ex, $"Exception occurred while handling {typeof(TRequest).Name}");
throw;
}
}
}

Next step is to configure the pipeline in startup class.

//Configure the MediatR pipeline in StartUp Class
var services = new ServiceCollection();
services.AddMediatR(typeof(Startup));

// Register any other dependencies your handlers might require
services.AddTransient<IUserService, UserService>();

// Configure pipeline behaviors
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ExceptionHandlingBehavior<,>));

By utilizing MediatR's pipeline capabilities, you can easily insert and compose multiple behaviors in a flexible manner, providing a powerful way to modify and extend the behavior of your application's requests without tightly coupling them to specific implementations.

The pipeline in MediatR is typically implemented using a combination of decorators and the Decorator Pattern. Decorators wrap and modify the behavior of the underlying handler, allowing you to add or modify functionality at various points in the pipeline.

In summary, MediatR is a versatile library that simplifies the implementation of the Mediator pattern and facilitates the creation of pipelines in C# applications. It promotes decoupling, modularity, and extensibility, making it easier to handle requests, apply behaviors, and build scalable and maintainable applications.

https://github.com/jbogard/MediatR 

In simple terms, MassTransit allows different parts of a system to send and receive messages, regardless of where they are located or how they are implemented. It provides a way to abstract away the details of communication protocols and message serialization, allowing developers to focus on the business logic of their applications. 

I've used MassTransit many years ago and wanted to highlight the usage of it and the simplicty it provide to integrate with different message brokers. 

I have written a .Net 7 mininal api sample in MassTransit. Have a look at it and see how simple it is to integrate. This will eliminate tons of plumbing code to get the messaging working. 

    HTTPS://GITHUB.COM/LUDMAL/MASSTRANSITSAMPLE

With Minimal API, developers can create HTTP endpoints with fewer lines of code and without having to set up complex routing or middleware configurations. This is achieved by providing a simplified syntax for defining endpoints, which reduces the amount of code required to create an API.

A simple example:

    using Microsoft.AspNetCore.Mvc;
    using Microsoft.Extensions.Logging;

    var builder = WebApplication.CreateBuilder(args);

    var app = builder.Build();

    app.MapGet("/", () => "Hello World!");

    app.Run();

The goal of Minimal API is to enable developers to focus on writing business logic rather than dealing with infrastructure concerns. It provides a streamlined development experience, making it easier and faster to build APIs. Additionally, Minimal API integrates seamlessly with other .NET Core technologies, such as Dependency Injection and Entity Framework Core.

Another example for coherent code structure:

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapPost("/change-password", UserEndpoints.ChangePassword);

app.Run();

public static class UserEndpoints
{
public static async Task<IResult> ChangePassword(

                                    HttpContext context,

                                    ChangePasswordRequest request,
                            IUserService userService)
{
//Logic here
return await Task.FromResult(Results.Ok());
}
}

Overall, Minimal API in .NET Core provides a lightweight, modern approach to building web APIs, enabling developers to quickly create high-performance, scalable APIs with minimal effort. 

I will be writing quite a bit of minimal api usages and best practices in future. So stay tuned.  

One of the key benefits of switch expressions pattern matching is that it reduces the amount of code you need to write to handle different cases. This can make your code more readable, maintainable, and efficient.

Here's an example of how you can use switch expressions pattern matching in C#:

public string Execute(ICommand command) => command switch
{
    OpenCommand o     => "Open Command",
    CloseCommand o    => "Close Command",
    ExecuteCommand o  => "Execute Command",
    _                 => throw new ArgumentOutOfRangeException(nameof(command), command, null)
};

In the above example, we define a method called Execute that takes an ICommand object as a parameter. We then use a switch expression to match the type of the command and return the corresponding action. Also it is far easier to use pattern matching on the properties of the paratmers. 

public string Execute(ICommand command) => command switch
{
    { Valid: true, Value: > 10 }        => "Open Command",
    { Valid: false, Value: <= 10 }      => "Close Command",
    ExecuteCommand o                   => "Execute Command",
    _                                  => throw new ArgumentOutOfRangeException(nameof(command), command, null)
};

The switch expression uses the arrow notation (=>) to match the pattern and return the result. The _ symbol acts as a catch-all case, which throws an exception if an invalid command is passed in.

Tuples significantly improves the pattern matching as shown in the below example.

private static string FormatMobileNumber(string number) => 
    (number.StartsWith("+6"), number.StartsWith("6"), number.StartsWith("04")) switch
    {
        (true,  _,     _)    => number,
        (false, true,  _)    => $"+61{number[1..]}",
        (false, false, true) => $"+61{number[1..]}",
        _                    => number
    };

Overall, switch expressions pattern matching is a powerful feature in C# that can help you write more expressive and maintainable code. Whether you're working on a small project or a large enterprise application, it's definitely worth considering using switch expressions pattern matching in your code.

Big data is the key for the ML & AI. It helps ML learns and improve the accuracy. This is the main reason, companies such as Google benefits vastly from ML & AI. Moreover, AI & ML can improve the product significantly. When the product quality improves more users tend to use it and this generates more data. More data can be used for ML & AI to improve the product hence an infinite loop of improving the product. This is what I called -- “AI Product improvement cycle”

AI & ML has become an essential part of any product development. Therefore, analysing and implementing ML algorithms will improve the quality of the product which can leads to more users.

Visit my Github project for more details on how to use it.  - https://github.com/ludmal/AWS.Net

For example, sending a message to the SQS is easy as this. 

var service = new SqsService<EmailMessage>(new AwsCredentials
{
  RegionEndpoint = RegionEndpoint.USWest2
});

service.QueueUrl = ConfigurationManager.AppSettings["EmailQueue"];

var response = service.Push(new HelloEmail());

And retrieving the message with Generic object is very simple.

var service = new SqsService<EmailMessage>(new AwsCredentials
{
 //SQS Service Region
 RegionEndpoint = RegionEndpoint.USWest2
});

//SQS Queue Url
service.QueueUrl = ConfigurationManager.AppSettings["EmailQueue"];

var items = service.Process();