Dot Net World

Building a Web Scraping RAG Pipeline in .NET Using GitHub Models

2026-03-03T21:05:00.001+05:30

Retrieval‑Augmented Generation (RAG) has quickly become one of the most practical ways to build AI systems that work with real‑world data instead of relying only on a model’s training knowledge.

Most RAG examples today are written in Python and often depend on frameworks like LangChain. While powerful, this leaves a gap for developers working primarily in .NET and C#.

In this post, I’ll walk through a .NET Console application I built that implements a complete RAG pipeline using GitHub Models for embeddings and chat completion.

What This Project Does?

At a high level, this application allows you to:

Provide a website URL
Automatically scrape and clean the page content
Convert the content into embeddings
Store embeddings in an in‑memory vector store
Ask questions about the website
Get accurate, context‑aware answers generated by an AI model

All of this runs inside a .NET Console App, making it easy to debug, extend, and later expose as an API.

Architecture Overview

The application follows a simple but effective RAG architecture:

Each step is implemented as a separate service, making the system easy to test and reuse.

How the RAG Pipeline Works?

Web Scraping

The application fetches the website HTML and extracts visible content from tags like: p, h1–h6,li, span, div.

Script and style tags are removed to reduce noise.
Text Chunking

The cleaned text is split into overlapping chunks.This improves retrieval accuracy and mirrors how modern RAG systems operate. Example: Chunk size: 300 characters and Overlap: 50 characters
Embeddings with GitHub Models

Each chunk is converted into a vector embedding using GitHub Models, allowing the system to perform semantic similarity searches.

The same embedding model is used for:
- Website content
- User questions
This ensures meaningful vector comparisons.
Vector Similarity Search

When a question is asked:
- The query is embedded
- Cosine similarity is calculated against all stored vectors
- The top K most relevant chunks are selected
This acts as the knowledge retrieval step.
Prompt Construction

The final prompt sent to the chat model contains:
- Retrieved context chunks
- Conversation history
- The user’s question
This keeps responses accurate, grounded, and conversational.
Chat Completion

The prompt is sent to a GitHub Models chat model, which generates the final answer. If the context does not contain relevant information, the model is instructed to clearly say so.

Running the Application

dotnet restore
dotnet run

Console Commands

Enter a website URL to initialize the RAG pipeline
Ask questions about the website content
Type new to load another website
Type quit to exit

Check out the full source code on GitHub:

Happy coding!! 😊

Content Projection in Angular

2024-12-16T09:17:00.004+05:30

In Angular, content projection is a powerful technique that allows developers to pass content from a parent component into a child component, and display it in a specific location within the child component's template. This mechanism enables component reusability and flexibility, making it an essential concept for building modular applications.

This blog post delves into the concept of content projection, its types, and provides an example to help you understand how to implement it effectively.

What is Content Projection?

Content projection allows you to project or "transclude" external content into a component’s template. It uses the <ng-content> directive, which acts as a placeholder in the child component’s template where the content provided by the parent component will be inserted.

Types of Content Projection

Single-Slot Content Projection:
- The simplest form, where one <ng-content> tag is used in the child component.
Multi-Slot Content Projection:
- Uses the select attribute to project different types of content into different slots.
Conditional Content Projection:
- Employs structural directives like *ngIf to conditionally display projected content.

Example: Single-Slot Content Projection

Let’s start with a basic example to demonstrate single-slot content projection.

Step 1: Create a Child Component

Create a child component that includes an <ng-content> tag in its template.

// child.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-child',
  template: `
    
      Child Component
      
    
  `,
  styles: [
    `.child-container { border: 2px solid #007BFF; padding: 10px; margin: 10px; }`
  ]
})
export class ChildComponent {}

Step 2: Use the Child Component in a Parent Component

Pass custom content from the parent component to the child component.

// parent.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-parent',
  template: `
    
      Parent Component
      
        This is the projected content!
      
    
  `,
  styles: [
    `.parent-container { border: 2px solid #28A745; padding: 10px; margin: 10px; }`
  ]
})
export class ParentComponent {}

Result

Output will look like this.

Example: Multi-Slot Content Projection

To project multiple slots, use the select attribute in <ng-content> tags.

Step 1: Update the Child Component Template

// child.component.ts
@Component({
  selector: 'app-child',
  template: `
    
      Child Component
      
      
    
  `,
  styles: [
    `.child-container { border: 2px solid #007BFF; padding: 10px; margin: 10px; }`
  ]
})
export class ChildComponent {}

Step 2: Update the Parent Component Template

// parent.component.ts
@Component({
  selector: 'app-parent',
  template: `
    
      Parent Component
      
        This is the header content!
        This is the body content!
      
    
  `,
  styles: [
    `.parent-container { border: 2px solid #28A745; padding: 10px; margin: 10px; }`
  ]
})
export class ParentComponent {}

Result

The output will display the header and body content in their respective slots within the child component.

Benefits of Content Projection

Enhances reusability by allowing dynamic content insertion.
Separates the concerns of structure and content.
Reduces redundancy by avoiding repeated component code.

Conclusion

Content projection is a fundamental concept in Angular that empowers developers to create reusable and flexible components. By mastering single-slot, multi-slot, and conditional projection, you can build robust and scalable Angular applications. Start experimenting with <ng-content> in your projects to harness its full potential!

Find out more about content projection here.

Happy learning!! 😊

Angular(DI) Resolution Modifiers

2024-12-09T07:30:00.001+05:30

In Angular, one of its core strengths lies in its Dependency Injection (DI) system, which ensures that components and services can seamlessly interact. A key feature of this DI system is the use of Resolution Modifiers. In this blog post, we'll explore what Resolution Modifiers are, how they work, and their practical applications in Angular.

What Are Resolution Modifiers?

Resolution Modifiers in Angular provide specific instructions to the dependency injection system on how to resolve a dependency. They are used to modify the default behavior of Angular's DI system, allowing developers to handle more complex scenarios effectively.

Angular provides four main resolution modifiers:

@Optional
@Self
@SkipSelf
@Host

These decorators are applied to constructor parameters in a component or service to control how dependencies are injected.

@Optional

The @Optional decorator tells Angular that a dependency is optional. If the DI system cannot resolve the dependency, it will inject null instead of throwing an error.

import { Component, Optional } from '@angular/core';
import { SomeService } from './some.service';

@Component({
  selector: 'app-optional-example',
  template: 'Check the console for details.'
})
export class OptionalExampleComponent {
  constructor(@Optional() private someService: SomeService) {
    console.log('Service:', someService);
  }
}

When to Use:

Use @Optional when a dependency is not critical for the component’s functionality.
Ideal for scenarios where a service might or might not be available.

@Self

The @Self decorator restricts Angular's DI system to only look for the dependency in the current injector. If the dependency is not found, Angular will throw an error instead of searching up the injector hierarchy.

import { Component, Self } from '@angular/core';
import { SomeService } from './some.service';

@Component({
  selector: 'app-self-example',
  template: 'Check the console for details.'
})
export class SelfExampleComponent {
  constructor(@Self() private someService: SomeService) {
    console.log('Service:', someService);
  }
}

When to Use:

Use @Self when you want to ensure the dependency comes from the current injector only.
Prevents accidental resolution of dependencies from ancestor injectors.

@SkipSelf

The @SkipSelf decorator tells Angular to skip the current injector and look for the dependency in ancestor injectors.

import { Component, SkipSelf } from '@angular/core';
import { SomeService } from './some.service';

@Component({
  selector: 'app-skip-self-example',
  template: 'Check the console for details.'
})
export class SkipSelfExampleComponent {
  constructor(@SkipSelf() private someService: SomeService) {
    console.log('Service:', someService);
  }
}

When to Use:

Use @SkipSelf when you explicitly want to avoid resolving a dependency from the current injector.
Useful in hierarchical injector configurations where certain dependencies are defined only at specific levels.

@Host

@Host instructs Angular to look for the required dependency in the closest component with the requested service in its injector hierarchy. It starts the search from the component where the directive with this decorator is applied.

import { Component, SkipSelf } from '@angular/core';
import { SomeService } from './some.service';

@Component({
  selector: 'app-skip-self-example',
  template: 'Check the console for details.'
})
export class SkipSelfExampleComponent {
  constructor(@Host() private someService: SomeService) {
    console.log('Service:', someService);
  }
}

Practical Scenarios

Handling Fallbacks with @Optional: If a feature is only available conditionally, you can use @Optional to gracefully handle the absence of its service.
Scoped Services with @Self: When implementing a service that should only exist within a specific component or module, use @Self to enforce this boundary.
Avoiding Circular Dependencies with @SkipSelf: In hierarchical dependency setups, @SkipSelf can help prevent circular dependency issues by bypassing the current injector.

Conclusion

Resolution Modifiers are a powerful tool in Angular's Dependency Injection system. They give developers fine-grained control over how dependencies are resolved, ensuring greater flexibility and robustness in application design. By understanding and leveraging these modifiers, you can handle complex dependency scenarios with ease.

Happy learning!! 😊

Angular Preloading Strategy : Enhancing User Experience and Performance

2024-12-02T07:30:00.004+05:30

Angular offers several features to enhance performance and improve the user experience. One of these features is preloading, a mechanism to load modules in the background after the application has been bootstrapped.At the heart of this feature is the PreloadStrategy, a powerful tool for optimizing Angular applications.

In this blog post, we’ll explore what PreloadStrategy is, its significance, how it works, and how to customize it to suit your needs.

What is PreloadStrategy?

In Angular applications, lazy loading is commonly used to load modules only when needed, reducing the initial bundle size and improving load time. However, lazy loading might cause a delay when users navigate to a route whose module hasn’t been loaded yet. Preloading bridges this gap by loading lazy-loaded modules in the background after the application is initialized.

PreloadStrategy is an Angular interface that defines the strategy for preloading these modules. By default, Angular provides two built-in strategies:

NoPreloading: Disables preloading entirely.
PreloadAllModules: Preloads all lazy-loaded modules as soon as possible.

Why Use Preloading?

Preloading enhances user experience by:

Reducing Navigation Latency: Modules are preloaded before users navigate to them, making transitions smoother.
Balancing Performance: By preloading selectively, you can optimize network usage and avoid unnecessary loads.

How Does Preloading Work?

Angular’s preloading mechanism relies on the router. When defining routes, you specify lazy-loaded modules with the loadChildren property. Preloading strategies dictate whether these modules should be loaded immediately after the application starts or deferred until navigation.

Here’s an example of enabling preloading with the PreloadAllModules strategy:

Step 1: Configuring the Router

import { NgModule } from '@angular/core';
import { RouterModule, Routes, PreloadAllModules } from '@angular/router';

const routes: Routes = [
  { path: '', redirectTo: 'home', pathMatch: 'full' },
  { path: 'home', loadChildren: () => import('./home/home.module').then(m => m.HomeModule) },
  { path: 'about', loadChildren: () => import('./about/about.module').then(m => m.AboutModule) },
];

@NgModule({
  imports: [RouterModule.forRoot(routes, { preloadingStrategy: PreloadAllModules })],
  exports: [RouterModule]
})
export class AppRoutingModule {}

Step 2: Including the Router in Your Application

Ensure your application’s AppModule imports the AppRoutingModule:

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, AppRoutingModule],
  bootstrap: [AppComponent]
})
export class AppModule {}

Customizing PreloadStrategy

Sometimes, preloading all modules might not be ideal. You may want to preload specific modules based on conditions like user roles or network bandwidth. For such cases, you can create a custom PreloadStrategy.

Creating a Custom PreloadStrategy

A custom strategy involves implementing the PreloadStrategy interface and overriding the preload method:

import { Injectable } from '@angular/core';
import { Route, PreloadingStrategy } from '@angular/router';
import { Observable, of } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class CustomPreloadStrategy implements PreloadingStrategy {
  preload(route: Route, load: () => Observable<any>): Observable<any> {
    // Check for a custom data property to decide whether to preload
    if (route.data && route.data['preload']) {
      return load();
    }
    return of(null);
  }
}

Using the Custom Strategy

To use your custom strategy, configure the router as follows:

@NgModule({
  imports: [RouterModule.forRoot(routes, { preloadingStrategy: CustomPreloadStrategy })],
  exports: [RouterModule]
})
export class AppRoutingModule {}

And add data properties to your routes:

const routes: Routes = [
  { path: 'home', loadChildren: () => import('./home/home.module').then(m => m.HomeModule), data: { preload: true } },
  { path: 'about', loadChildren: () => import('./about/about.module').then(m => m.AboutModule), data: { preload: false } },
];

Conclusion

Preloading strategies in Angular are essential for balancing application performance and user experience. The default strategies—NoPreloading and PreloadAllModules—cover basic needs, but you can tailor preloading behavior by implementing custom strategies. By leveraging preloading effectively, you can create applications that are fast and responsive, delighting your users.

Find out more about Preloading here.

Happy learning!! 😊

Understanding Resolvers in Angular

2024-11-29T07:30:00.001+05:30

When building Angular applications, one of the common requirements is to fetch data before navigating to a route. For instance, consider a scenario where you want to display a user's details on a profile page. Instead of loading the route and showing a spinner while fetching data, wouldn't it be better to resolve the data before entering the route? This is where Angular Resolvers shine.

In this post, we'll explore what resolvers are, why they're essential, and how to use them effectively in your Angular applications

What is a Resolver in Angular?

A Resolver in Angular is a service that retrieves data before a route is activated. It ensures that your component is rendered with the required data already available, improving user experience by reducing the time spent waiting for asynchronous calls after the view is loaded.

Resolvers are part of Angular's Route Guards, which include CanActivate, CanDeactivate, CanLoad, and others. While these guards determine route activation, Resolvers focus specifically on fetching data.

Why Use Resolvers?

Optimized User Experience: By fetching data before rendering, you avoid rendering incomplete views with loading indicators.

Centralized Data Logic: Resolvers encapsulate data-fetching logic, keeping your components clean and focused on UI concerns.
Error Handling: Resolvers allow you to handle errors gracefully and redirect users if data retrieval fails.

Implementing a Resolver

Here’s a step-by-step guide to creating and using a Resolver in Angular

Step 1: Define the Resolver Function

Here’s how you can create a resolver using ResolveFn:

import { ResolveFn } from '@angular/router';
import { inject } from '@angular/core';
import { UserService } from './user.service';

export const userResolver: ResolveFn<User> = (route, state) => {
  const userService = inject(UserService);
  const userId = route.paramMap.get('id');
  return userService.getUserById(userId!);
};

In the above code we have:

Dependency Injection: The inject() function provides access to the UserService.
Route Parameters: Use route.paramMap.get('id') to fetch dynamic route parameters.
Return Value: Return an observable, promise, or synchronous value. Angular will wait for the observable to resolve before activating the route.

Step 2: Configure the Route

Add the resolver to the desired route in the RouterModule configuration.

import { Routes } from '@angular/router';
import { UserComponent } from './user.component';
import { userResolver } from './user.resolver';

const routes: Routes = [
  {
    path: 'user/:id',
    component: UserComponent,
    resolve: { userData: userResolver },
  },
];

Here, the resolve property maps the resolver (userResolver) to a key (userData) that can be accessed in the component.

Step 3: Access Resolved Data in the Component

We can access the resolved data in component by using ActivatedRoute’s data property.

import { Component, OnInit } from '@angular/core';
import { ActivatedRoute } from '@angular/router';

@Component({
  selector: 'app-user',
  template: `User Details
             {{ user | json }}`,
})
export class UserComponent implements OnInit {
  user: User | undefined;

  constructor(private route: ActivatedRoute) {}

  ngOnInit() {
    this.user = this.route.snapshot.data['userData'];
  }
}

Conclusion

Resolvers in Angular are a powerful tool for managing data preloading and improving user experience. By combining resolvers with Angular's routing and lazy-loading capabilities, you can build robust, user-friendly applications.

Happy learning!! 😊

Understanding ClaimsPrincipal, ClaimsIdentity, and Claim in C#

2024-11-20T17:30:00.009+05:30

When developing applications that require user authentication and authorization, managing user identities and their associated information securely is essential. In C#, the classes ClaimsPrincipal, ClaimsIdentity, and Claim in the System.Security.Claims namespace provide a flexible and extensible way to manage user identity data in a claims-based manner.

In this post, we'll explore the concepts of ClaimsPrincipal, ClaimsIdentity, and Claim in C#, and see how they work together to represent and manage user identity information.

Understanding Claims-Based Identity

Before diving into the classes, it’s helpful to understand the concept of claims-based identity. A claim is a statement about a user that provides information about who they are, what they can do, or other relevant attributes. Examples of claims include:

The user's email address
A role or permission level (like "Admin" or "User")
The user's age or country of residence

A claims-based approach to identity allows you to store these attributes about users and use them to authorize access to various resources or features within an application.

Claim, ClaimsIdentity, and ClaimsPrincipal

Claim

A Claim is the smallest unit in claims-based identity management. Each claim represents a single piece of information about a user. In .NET, a Claim object consists of:

Type: A string identifier for the claim, such as ClaimTypes.Email, ClaimTypes.Role, or custom identifiers.
Value: The data associated with the claim type, such as an email address or role.
ValueType: Optional, indicating the data type of the claim (e.g., string, boolean).
Issuer: Optional, indicating which system provided the claim.

Here’s how you might create a Claim object in C#:

using System.Security.Claims;

// Create a claim representing the user's email address
var emailClaim = new Claim(ClaimTypes.Email, "user@example.com");

ClaimsIdentity

A ClaimsIdentity represents a user identity and acts as a container for a set of claims. Each identity can have multiple claims, making it a way to associate a collection of claims with a single user. Additionally, an identity can be labeled with an authentication type, which indicates how the user was authenticated (e.g., "Forms", "OAuth").

Creating a ClaimsIdentity and adding claims to it is straightforward:

// Create a ClaimsIdentity for the user, with a set of claims
var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, "John Doe"),
    new Claim(ClaimTypes.Email, "johndoe@example.com"),
    new Claim(ClaimTypes.Role, "Admin")
};

var identity = new ClaimsIdentity(claims, "CustomAuthType");

ClaimsPrincipal

A ClaimsPrincipal is the top-level class that represents the user’s identity as a whole. It can contain one or more ClaimsIdentity instances, which means a user could have multiple identities in different contexts (e.g., a business identity and a personal identity).

ClaimsPrincipal is particularly useful for authorization as it provides methods for querying claims, checking roles, and retrieving the user’s identity data across different authentication mechanisms.

Creating a ClaimsPrincipal from a ClaimsIdentity looks like this:

var principal = new ClaimsPrincipal(identity);

You can access claims in the ClaimsPrincipal like so:

var email = principal.FindFirst(ClaimTypes.Email)?.Value;
var isAdmin = principal.IsInRole("Admin");

How Claims-Based Identity Works in ASP.NET Core

In ASP.NET Core, claims-based identity is tightly integrated into the authentication and authorization framework. When a user logs in, ASP.NET Core creates a ClaimsPrincipal for that user, populated with claims provided by the authentication mechanism (e.g., from a database, external login provider, or token). You can configure custom claims by adding them to the ClaimsPrincipal as part of your authentication process.

Example: Adding Claims to the User in ASP.NET Core

Here’s an example of adding custom claims after the user authenticates in ASP.NET Core:

public async Task<IActionResult>> Login(string username, string password)
{
    if (ValidateUser(username, password))
    {
        var claims = new List<Claim>
        {
            new Claim(ClaimTypes.Name, username),
            new Claim("Department", "IT"),
            new Claim(ClaimTypes.Role, "Admin")
        };

        var claimsIdentity = new ClaimsIdentity(claims, "CustomAuthType");
        var claimsPrincipal = new ClaimsPrincipal(claimsIdentity);

        await HttpContext.SignInAsync(claimsPrincipal);

        return RedirectToAction("Index", "Home");
    }

    return View("LoginFailed");
}

In this example, if ValidateUser confirms the user credentials, we create a new ClaimsPrincipal with relevant claims, and call SignInAsync to persist the user’s authentication status.

Advantages of Using Claims-Based Identity

Flexibility: Claims allow you to attach arbitrary data to users, enabling complex authorization logic.
Simplified Role Management: Roles are just one type of claim, so authorization logic can be extended beyond simple roles.
Federation-Friendly: Claims are essential when integrating with external identity providers (e.g., Google, Microsoft) because they facilitate exchanging user identity information securely.

Conclusion

The ClaimsPrincipal, ClaimsIdentity, and Claim classes in C# provide a powerful and flexible way to manage user identities and authorization. By adopting a claims-based approach to identity, you can create applications that are secure, adaptable, and easy to integrate with external identity providers.

Find out more -

Happy learning!! 😊

Exploring HybridCache in .Net 9

2024-11-13T09:30:00.002+05:30

As ASP.NET Core continues to evolve, with the release of .NET 9, a new caching mechanism called HybridCache has been introduced, offering a blend of in-memory and distributed caching to address the limitations of traditional caching methods.

What is HybridCache?

HybridCache is a caching library designed to combine the best features of in-memory caching (L1) and distributed caching (L2). This dual-layer approach helps mitigate common issues like cache stampedes and race conditions, ensuring a more robust and efficient caching strategy.

Key Features of HybridCache

Stampede Protection: Prevents multiple concurrent requests from overwhelming the cache by ensuring only one request fetches the data while others wait for the result.

Multi-Tier Caching: Utilizes both in-memory (L1) and distributed (L2) caches, balancing speed and storage capacity.
Configurable Serialization: Offers flexibility in how data is serialized and deserialized, catering to various application needs.
Tag-Based Eviction: Allows for more granular control over cache invalidation, improving cache management.

Setting Up HybridCache

To get started with HybridCache in your ASP.NET Core application, follow these steps:

Install the Package

dotnet add package Microsoft.Extensions.Caching.Hybrid

Register the Service

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHybridCache();

Using HybridCache

public class SomeService
{
    private readonly HybridCache _cache;

    public SomeService(HybridCache cache)
    {
        _cache = cache;
    }

    public async Task<string> GetSomeInfoAsync(string name, int id, CancellationToken token = default)
    {
        return await _cache.GetOrCreateAsync(
            $"CacheKey",
            async cancel => await GetDataFromTheSourceAsync(name, id, cancel),
            cancellationToken: token
        );
    }

    private async Task<string> GetDataFromTheSourceAsync(string name, int id, CancellationToken token)
    {
        // Simulate data retrieval
        return $"{name}-{id}";
    }
}

Benefits of HybridCache

Improved Performance: By leveraging both in-memory and distributed caches, HybridCache reduces latency and enhances data retrieval speed.
Enhanced Scalability: The dual-layer caching system allows applications to scale more efficiently, handling larger volumes of data without compromising performance.
Simplified API: HybridCache provides a unified API for both in-process and out-of-process caching, reducing complexity for developers.

Conclusion

HybridCache in .NET Core represents a significant advancement in caching technology, offering a powerful and flexible solution for modern web applications. By combining the strengths of in-memory and distributed caching, it ensures optimal performance, scalability, and reliability.

For more detailed information and advanced configuration options, refer to the official documentation.

Happy coding!! 😊

Polly in .NET Core: A Guide to Resilience and Fault Handling

2024-11-12T07:30:00.003+05:30

Polly is a .NET library that provides a framework for handling transient faults in an application. It allows developers to implement retry policies, circuit breakers, timeouts, and other fault-handling patterns in a clean, composable, and declarative way. In this post, we'll explore what Polly is, why it’s valuable, and how to use it in .NET Core applications to build resilient, fault-tolerant solutions.

What is Polly?

Polly is an open-source library that enables you to build fault-handling and resilience logic into your applications. It helps you manage faults and unexpected scenarios by providing a range of resilience policies. Polly works seamlessly with .NET Core and can be used across HTTP clients, database calls, message queues, and more. Here are the key policies Polly supports:

Retry: Retry a failed operation multiple times before giving up.
Circuit Breaker: Stop calling a failing service temporarily to give it time to recover.
Timeout: Fail if an operation takes longer than a specified time.
Fallback: Provide an alternative response or behavior when an operation fails.
Bulkhead Isolation: Limit concurrent executions to avoid resource exhaustion.
Cache: Cache responses to avoid repeated calls for the same result.

By combining these policies, Polly enables you to create robust and customizable resilience strategies tailored to your application’s needs.

Why Use Polly?

In any distributed application, you’ll inevitably encounter issues like network instability, service unavailability, or rate limiting. Polly allows you to handle these scenarios without excessive code and helps:

Improve User Experience: Users will experience fewer errors and smoother interactions if transient faults are handled gracefully.
Enhance Reliability: Redundant attempts (like retries) increase the likelihood of success when services experience intermittent failures.
Manage System Load: Circuit breakers and bulkhead isolation help to prevent overwhelming dependent services and your application.

By using Polly in .NET Core applications, you get a consistent and reliable way to manage resilience, even as your system scales and complexity grows.

Getting Started with Polly in .NET Core

To get started, install Polly through NuGet:

dotnet add package Polly

Polly integrates well with the HttpClientFactory in .NET Core, which simplifies managing HTTP requests and supports resilient communication between services. Here’s a look at how to apply Polly with HttpClientFactory.

Example: Using Polly with HttpClientFactory in .NET Core

The IHttpClientFactory offers a way to register and configure HttpClient instances, and it easily integrates Polly policies for fault tolerance.

Define Resilience Policies: Set up retry and circuit breaker policies.
Configure HttpClient: Apply these policies to HttpClient.

Step 1: Define Resilience Policies

In your Startup.cs or Program.cs (for minimal APIs), configure Polly policies:

using Polly;
using Polly.Extensions.Http;
using System.Net.Http;

// Retry policy for transient errors
var retryPolicy = HttpPolicyExtensions
    .HandleTransientHttpError() // Handles 5xx errors and network failures
    .OrResult(msg => msg.StatusCode == HttpStatusCode.TooManyRequests) // Additional handling for 429
    .WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));

// Circuit breaker policy to prevent hammering a failing service
var circuitBreakerPolicy = HttpPolicyExtensions
    .HandleTransientHttpError()
    .CircuitBreakerAsync(2, TimeSpan.FromSeconds(30));

These policies set up a retry mechanism with exponential backoff and a circuit breaker to stop calls when repeated failures are detected.

Step 2: Configure HttpClient with Polly Policies

services.AddHttpClient("MyResilientClient", client =>
{
    client.BaseAddress = new Uri("https://example.api.com/");
})
.AddPolicyHandler(retryPolicy)
.AddPolicyHandler(circuitBreakerPolicy);

Now, when MyResilientClient is injected into services or controllers, it will automatically use the defined retry and circuit breaker policies.

Step 3: Use the Configured HttpClient

Inject and use the configured HttpClient with the resilience policies:

public class MyService
{
    private readonly HttpClient _httpClient;

    public MyService(IHttpClientFactory httpClientFactory)
    {
        _httpClient = httpClientFactory.CreateClient("MyResilientClient");
    }

    public async Task<string> GetDataAsync()
    {
        var response = await _httpClient.GetAsync("/data");
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

With this setup, GetDataAsync will retry failed requests automatically up to three times and break the circuit if there are multiple failures within a short timeframe.

Conclusion

Polly in .NET Core is a powerful tool for building resilient and fault-tolerant applications. By using Polly’s declarative syntax, you can easily create custom resilience policies like retries, circuit breakers, and timeouts.

Find out more about Polly- Meet Polly: The .NET resilience library

Happy coding!! 😊

Implementing JWT Authentication in .NET Core

2024-11-11T07:30:00.013+05:30

JWT (JSON Web Token) is a popular way to implement secure authentication in modern web applications. It provides a lightweight and stateless mechanism to authenticate users, ensuring secure data transfer. In this blog post, we’ll explore how to implement JWT authentication in a C# ASP.NET Core application with a step-by-step example.

What is JWT?

A JWT is a token that is used to securely transmit information between two parties (client and server). It is digitally signed, ensuring that the data it contains can be trusted. JWT consists of three parts:

Header: Specifies the algorithm used to generate the signature, typically HMAC SHA256 or RSA.
Payload: Contains the claims or the data being transmitted (such as user ID, roles, etc.).
Signature: Ensures that the token hasn’t been tampered with.

The general structure looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1bmlxdWVfbmFtZSI6InVzZXIwMSIsIm5iZiI6MTczMTIxMDQ4OCwiZXhwIjoxNzMxMjExNjg4LCJpYXQiOjE3MzEyMTA0ODh9.2adOgvFCgF4FfzwWS3VbT-AOUvXvwwMmI76HrdTXFW4

Why JWT?

Stateless: No need to store sessions on the server.
Scalable: The server doesn’t need to store or retrieve session information.
Cross-domain: JWT can be easily used across different domains, making it ideal for distributed applications like microservices.

Implementing JWT in C# ASP.NET Core

Lets' build a simple ASP.NET Core Web Api and implement JWT Authentication. In this demo project we will have three projects-

JWTAuthentication.WebApi: This will be Api in which we will have two endpoints, one to Authenticate the user and return JWT Token. Another endpoint will be secure which will return data only for valid tokens.
JwtAuthentication.Services:This will be our servcie layer.
JWTAuthentication.TokenManager:This will be class library where we will implement JWT token generation.

Lets start the implementation-

Setting Up the Project

Open Visual Studio and create a new ASP.NET Core project JWTAuthentication.WebApi.
Add a class library in this project name JwtAuthentication.Services
Add another class library in this project name JwtAuthentication.TokenManager

JWTAuthentication.TokenManager Project

Install the required NuGet packages in JWTAuthentication.TokenManager Project

    dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer

Add a class file JwtExtension.cs and Create a extension method for Registering and configure the JWT Authentication.

    public static IServiceCollection AddCustomJwtAuthentication(this IServiceCollection services)
    {
    services.AddAuthentication(option =>
    {
        option.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        option.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
        option.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
    }).AddJwtBearer(x =>
    {
        x.RequireHttpsMetadata = false;
        x.SaveToken = false;
        x.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8
                .GetBytes(JWTTokenManager.JWT_Secret)
            ),
            ValidateIssuer = false,
            ValidateAudience = false,
            ClockSkew = TimeSpan.Zero
        };
    });
    return services;
}

Add a class file JWTTokenManager.cs and add the below code.

  public class JWTTokenManager
  {
      public static string JWT_Secret = "Your Secret Key";
      private static int JWT_TOKEN_VALIADITY_MIN = 20;
      public string GenerateJwtToken(string userName)
      {
          var claims = new List<Claim>
          {
              new Claim(ClaimTypes.Name, userName),
          };
          var key = Encoding.ASCII.GetBytes(JWT_Secret);
          var tokenHandler = new JwtSecurityTokenHandler();
          var tokenDescriptor = new SecurityTokenDescriptor
          {
              Subject = new ClaimsIdentity(claims),
              Expires = DateTime.UtcNow.AddMinutes(JWT_TOKEN_VALIADITY_MIN),
              SigningCredentials = new SigningCredentials(new SymmetricSecurityKey(key), SecurityAlgorithms.HmacSha256Signature)
          };
          var token = tokenHandler.CreateToken(tokenDescriptor);
          return tokenHandler.WriteToken(token);
      }
  }

In the above code , you have created a method to generate the JWT Token when a user successfully logs in.

JwtAuthentication.Services Project

Add JWTAuthentication.TokenManager as reference in JwtAuthentication.Services Project. In this project we will verify the user based on user name and password and on successfull verofication, we will call JWT token creation method which we have implemented in JWTAuthentication.TokenManager project

Models-Add below class files in this project-AuthenticateRequest.cs, AuthenticateResponse.cs,UserAccount.cs

  //AuthenticateRequest.cs
  public class AuthenticateRequest
  {
      [Required]
      public string Username { get; set; }

      [Required]
      public string Password { get; set; }
  }
  //AuthenticateResponse.cs
  public class AuthenticateResponse
  {       
      public string Username { get; set; }
      public string Token { get; set; }
  }
  //UserAccount
  public class UserAccount
  {
      [JsonIgnore]
      public string UserName { get; set; }
      public string FirstName { get; set; }
      public string LastName { get; set; }

      [JsonIgnore]
      public string Password { get; set; }
  }

Add file UserServiceExtensions.cs. In this file we will create a extension method of IServiceCollection and add the dependencies-

  public static IServiceCollection AddUserServiceDepedencies(this IServiceCollection services) 
  {
      services.AddSingleton^lt;JWTTokenManager>();
      services.AddSingleton<IUserService, UserService>();
      return services;
  }

Add file UserService.cs and copy pase the below code-

 public interface IUserService
 {
     AuthenticateResponse? Authenticate(AuthenticateRequest model);
     IEnumerable<UserAccount> GetAll();
 }
 public class UserService : IUserService
 {
     // users hardcoded for simplicity, store in a db with hashed passwords in production applications
     private List<UserAccount> _users = new List<UserAccount>
     {
         new UserAccount { FirstName = "Test", LastName = "User", UserName = "user01", Password = "user01" },
         new UserAccount { FirstName = "Test1", LastName = "User", UserName = "user02", Password = "user02" }
     };
     private readonly JWTTokenManager _jwtTokenManager;
     public UserService(JWTTokenManager jwtTokenManager)
     {
         _jwtTokenManager = jwtTokenManager;
     }
     public AuthenticateResponse? Authenticate(AuthenticateRequest model)
     {
         var user = _users.SingleOrDefault(x => x.UserName == model.Username && x.Password == model.Password);

         // return null if user not found
         if (user == null) return null;

         // authentication successful so generate jwt token
         var token = _jwtTokenManager.GenerateJwtToken(user.UserName);

         return new AuthenticateResponse { Token = token, Username = user.UserName };
     }
     public IEnumerable<UserAccount> GetAll()
     {
         return _users;
     }

 }

Here, we have Authenticate method to validate the user by username and password.On successfull validation, we are calling GenerateJwtToken method to generate the new JWT Token

JWTAuthentication.WebApi

Add JWTAuthentication.TokenManager and JwtAuthentication.Services as reference.

Modify the Program.cs file to configure the JWT authentication. Add the following to enable JWT authentication

    builder.Services.AddCustomJwtAuthentication();
	builder.Services.AddAuthorization();
	builder.Services.AddUserServiceDepedencies();
	builder.Services.AddControllers();

Add authentication middleware-

    // Enable Authentication and Authorization
    app.UseAuthentication();
	app.UseAuthorization();

Program.cs file will look like this-

    using JWTAuthentication.TokenManager.Extensions;
    using JwtAuthentication.Services.Extensions;

    var builder = WebApplication.CreateBuilder(args);

    builder.Services.AddCustomJwtAuthentication();
    builder.Services.AddAuthorization();
    builder.Services.AddUserServiceDepedencies();
    builder.Services.AddEndpointsApiExplorer();
    builder.Services.AddSwaggerGen();
    builder.Services.AddControllers();


    var app = builder.Build();

    // Configure the HTTP request pipeline.
    if (app.Environment.IsDevelopment())
    {
        app.UseSwagger();
        app.UseSwaggerUI();
    }

    app.UseHttpsRedirection();
    app.UseAuthentication();
    app.UseAuthorization();
    app.MapControllers();
    app.Run();

Creating a Authenticate Endpoint :In your controller, create an action that logs in the user and returns a token.

    [HttpPost("authenticate")]
    public IActionResult Authenticate(AuthenticateRequest model)
    {
        var response = _userService.Authenticate(model);

        if (response == null)
            return BadRequest(new { message = "Username or password is incorrect" });

        return Ok(response);
    }

Securing API Endpoints :Now that we have JWT authentication set up, let’s secure an API endpoint. Add the [Authorize] attribute to a controller action that you want to protect
```
    [Authorize]
    [HttpGet]
    public IActionResult GetAll()
    {
        var users = _userService.GetAll();
        return Ok(users);
    }
    
```
This ensures that the GetSecureData method can only be accessed by users who have a valid JWT token.

Testing the API

You can test your API using a tool like Postman or cURL.

First, make a POST request to your authenticate endpoint in this case /api/User/authenticate with the following JSON in the body:
```
    {
    	"username": "user01",
        "password": "user01"
    }
    
```
You should receive a JWT token in the response.
Use this token in the Authorization header for subsequent requests to the secure endpoint.
```
    Authorization: Bearer <your-token-here>
    
```
Making a GET request to /api/User with the token should return the protected data.

The full source code is available here:

Conclusion

JWT authentication is a robust and stateless method for securing your ASP.NET Core applications. By following this guide, you now have a basic implementation of JWT authentication in a C# Web API. This approach not only improves security but also simplifies scalability by reducing the need for server-side session management.

Happy coding!! 😊

Forms in Angular - A Comprehensive Guide to Building Reactive and Template-Driven Forms

2024-11-04T17:30:00.001+05:30

Forms are a fundamental part of any web application, enabling users to interact with the app, provide information, and submit data. In Angular, forms can be implemented using two main approaches: Template-driven and Reactive forms. Each approach has unique benefits, so understanding how to use them effectively can elevate your Angular app development.

In this post, we'll dive into the following:

Template-driven forms
Reactive forms
Form validation
Comparing the two approaches

1. Template-Driven Forms

Template-driven forms in Angular rely heavily on Angular's two-way data binding. They’re built directly in the HTML template using directives like ngModel. Template-driven forms are ideal for simpler forms and are particularly helpful when you don’t need to programmatically control form behavior.

Setting Up a Template-Driven Form

To start with a template-driven form, you’ll first need to import the FormsModule in your AppModule.

import { FormsModule } from '@angular/forms';

@NgModule({
  imports: [FormsModule],
})
export class AppModule {}

Building a Simple Registration Form

<form #registerForm="ngForm" (ngSubmit)="onSubmit(registerForm)">
  <label for="username">Username:</label>
  <input type="text" id="username" name="username" ngModel required>

  <label for="email">Email:</label>
  <input type="email" id="email" name="email" ngModel required email>

  <label for="password">Password:</label>
  <input type="password" id="password" name="password" ngModel required minlength="6">

  <button type="submit" [disabled]="registerForm.invalid">Register</button>
</form>

Here’s a breakdown:

ngModel: Binds the input elements to the model.
#registerForm="ngForm": Creates a local reference for the form.
ngSubmit: Binds the form submission to a method in your component.

Handling Form Data in the Component

import { Component } from '@angular/core';

@Component({
  selector: 'app-register',
  templateUrl: './register.component.html'
})
export class RegisterComponent {
  onSubmit(form: any) {
    console.log('Form Data:', form.value);
  }
}

With template-driven forms, Angular automatically handles the form instance for you, which is beneficial for simple use cases.

2. Reactive Forms

Reactive forms provide a more programmatic approach to building forms and give you more control over validation, value changes, and error management. Unlike template-driven forms, reactive forms rely on explicit form control objects within the component class.

Setting Up a Reactive Form

To use reactive forms, you’ll need to import ReactiveFormsModule in your AppModule.

import { ReactiveFormsModule } from '@angular/forms';

@NgModule({
  imports: [ReactiveFormsModule],
})
export class AppModule {}

Building a Reactive Login Form

import { Component, OnInit } from '@angular/core';
import { FormBuilder, FormGroup, Validators } from '@angular/forms';

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html'
})
export class LoginComponent implements OnInit {
  loginForm!: FormGroup;

  constructor(private fb: FormBuilder) {}

  ngOnInit(): void {
    this.loginForm = this.fb.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required, Validators.minLength(6)]],
    });
  }

  onSubmit(): void {
    if (this.loginForm.valid) {
      console.log('Form Data:', this.loginForm.value);
    }
  }
}

HTML Template for Reactive Form

<form [formGroup]="loginForm" (ngSubmit)="onSubmit()">
  <label for="email">Email:</label>
  <input type="email" id="email" formControlName="email">

  <label for="password">Password:</label>
  <input type="password" id="password" formControlName="password">

  <button type="submit" [disabled]="loginForm.invalid">Login</button>
</form>

In this example:

FormGroup defines the structure of the form.
formControlName links form controls to the component class.

3. Form Validation

Angular provides built-in validators such as Validators.required, Validators.email, and Validators.minLength etc. that can be used in both form types. For custom validation, you can create validator functions to enforce specific business rules.

Adding Custom Validation

In a reactive form, custom validators are easily applied within the FormBuilder.

function strongPassword(control: FormControl) {
  const hasNumber = /\d/.test(control.value);
  const hasUppercase = /[A-Z]/.test(control.value);
  const isValid = hasNumber && hasUppercase;
  return isValid ? null : { strongPassword: true };
}

To apply it, add the validator to a control:

this.loginForm = this.fb.group({
  password: ['', [Validators.required, strongPassword]],
});

4. Comparing Template-Driven and Reactive Forms

Conclusion

Angular forms, whether template-driven or reactive, offer powerful ways to collect and validate user input. While template-driven forms work well for simple forms, reactive forms provide robust tools for more complex scenarios. Understanding both approaches and choosing the right one for your app’s needs will greatly improve the development process.

Start with the basics and practice building forms using both methods to gain confidence in handling Angular forms in real-world applications.

Find out more: Angular Forms

Happy larning!! 😊

Angular Signals : A Practical Guide with Examples

2024-11-01T16:30:00.004+05:30

Angular 17 recently introduced the concept of Signals to improve reactivity and simplify state management. Signals allow Angular applications to handle state changes in a more predictable, efficient, and declarative way. This blog will cover what Signals are, why they matter, and how to use them with practical examples.

What are Signals?

In Angular, a Signal is a reactive primitive that provides a new approach to managing and responding to state changes. With Signals, you can track changes to specific data points (variables or objects), allowing the app to automatically react when the data changes without needing complex change detection.

Why Use Signals?

Signals offer several benefits:

Predictable reactivity: Signals enable precise control over when a component updates, leading to more predictable behavior.
Improved performance: With Signals, Angular avoids unnecessary re-renders by updating only the affected parts.

Simplified state management: Signals are easy to understand and integrate with Angular’s Dependency Injection, making state management simpler and more scalable.

Creating and Using Signals in Angular

Angular Signals can be defined using the signal function in Angular 16 and above. Let’s walk through an example where we’ll create a simple counter component using Signals.

1. Setting Up the Counter Component

First, create a new Angular component:

ng generate component Counter

2. Import Signals into the Component

Import signal, computed, and effect from @angular/core. These functions allow us to create reactive data and computed states in Angular.

import { Component, signal, computed, effect } from '@angular/core';

3. Define the Counter Component with Signals

In your component file (counter.component.ts), create a signal for the counter state and add methods to increment and decrement its value.

@Component({
  selector: 'app-counter',
  templateUrl: './counter.component.html',
  styleUrls: ['./counter.component.css']
})
export class CounterComponent {
  // Define a signal for the counter
  counter = signal(0);

  // Create a computed signal to double the counter value
  doubledCounter = computed(() => this.counter() * 2);

  // Define methods to increment and decrement the counter
  increment() {
    this.counter.update(value => value + 1);
  }

  decrement() {
    this.counter.update(value => value - 1);
  }

  // Set up an effect to log counter changes
  constructor() {
    effect(() => {
      console.log("Counter value changed:", this.counter());
    });
  }
}

signal(0): Initializes the counter with a value of 0.
computed(() => this.counter() * 2): Creates a computed signal that automatically updates when the counter changes.
effect: Logs counter updates to the console whenever the counter’s value changes.

4. Updating the Component Template

Open the counter.component.html file and add buttons to control the counter. Display both the counter value and the computed doubled counter value.

<div>
  <h1>Angular Signals Counter</h1>
  <p>Counter: {{ counter() }}</p>
  <p>Doubled Counter: {{ doubledCounter() }}</p>

  <button (click)="increment()">Increment</button>
  <button (click)="decrement()">Decrement</button>
</div>

{{ counter() }}: This syntax retrieves the current value of the counter signal.
{{ doubledCounter() }}: Shows the computed value of counter * 2.

5. Testing the Component

Run your Angular application using:

ng serve

Open your browser, and navigate to http://localhost:4200. You should see the counter with its initial value, along with buttons to increment and decrement. Every time you click the buttons, the component updates in real time, and the effect logs the change in the console.

Advanced Example: Using Signals for Form Validation

Let’s extend this concept to form validation. In this example, we’ll create a form with a text field and use a computed signal to enable or disable the submit button based on validation.

1. Create the Form Component

ng generate component Form

2. Define Signals for Form State

Inside the form.component.ts, create signals to hold the input value and a computed signal for validation.

import { Component, signal, computed } from '@angular/core';

@Component({
  selector: 'app-form',
  templateUrl: './form.component.html',
  styleUrls: ['./form.component.css']
})
export class FormComponent {
  // Signal to hold form input
  inputText = signal('');

  // Computed signal to check if input is valid
  isInputValid = computed(() => this.inputText().length >= 3);

  // Update the input text
  updateInputText(value: string) {
    this.inputText.set(value);
  }
}

3. Update the Template with Form Controls

In form.component.html, add a text input and a submit button that is enabled only when the input is valid.

<div>
  <h1>Form with Angular Signals</h1>
  <input
    type="text"
    placeholder="Enter at least 3 characters"
    [value]="inputText()"
    (input)="updateInputText($event.target.value)"
  />

  <button [disabled]="!isInputValid()">Submit</button>
  <p *ngIf="!isInputValid()">Input must be at least 3 characters.</p>
</div>

[disabled]="!isInputValid()": Disables the submit button unless isInputValid is true.

4. Testing the Form Component

With this setup, the submit button will enable only when the input text has at least three characters. This demonstrates how Signals can help manage form validation logic simply and effectively.

Conclusion

Using Signals in Angular can make your code more reactive, efficient, and easier to manage. They work well for basic state management and can be scaled up for more complex applications. By using Signals, computed values, and effects, Angular apps become more predictable and performant.

Find out more: Angular Signals

Happy learning!! 😊

Service Discovery in Microservices with C# and .NET

2024-10-28T06:03:00.014+05:30

Service Discovery is a key pattern in microservice architectures, where services need to find each other dynamically. Unlike monolithic applications, where all components are contained within a single executable, microservices are distributed across multiple instances, often across different servers, virtual machines, or containers. Service discovery simplifies the way these services locate one another, allowing for load balancing, failover, and flexibility.

What is Service Discovery?

Service Discovery refers to the process by which services in a distributed system dynamically find each other. Instead of hard-coding the addresses of service instances (which can change in a dynamic environment like Kubernetes), services register themselves with a centralized service registry. Other services query this registry to find the addresses of the services they need to communicate with.

Benefits:

Scalability: New instances of services can be added dynamically.
Load Balancing: Requests can be routed to different instances of the same service.
Fault Tolerance: Dead services can be automatically removed from the registry.

Types of Service Discovery:

Client-Side Discovery

In client-side service discovery, the client directly queries the service registry to discover service instances and choose one to send a request to. This method requires the client to implement the logic for discovery and load balancing.

Server-Side Discovery

In server-side discovery, the client makes a request to a load balancer, and the load balancer queries the service registry to find available instances. The load balancer then forwards the request to an appropriate service instance.

Service Discovery in .NET/C#

In the .NET ecosystem, there are several tools and libraries that help with service discovery. These include:

Consul
etcd
ZooKeeper
Eureka (Spring Cloud for .NET)

We'll focus on Consul, which is one of the most popular choices for service discovery and distributed configuration.

Example Using Consul

Step 1: Install Consul

Before diving into C#, we need to install and run a Consul agent. You can download Consul from Consul Download and follow the installation instructions for your operating system.

Once Consul is installed, you can start the agent by running:

consul agent -dev

This command starts a local Consul agent in development mode.Open url http://localhost:8500/ in browser , you will see below ui-

Step 2: Setting Up the API:

Now, let’s create a .NET Core API project Service.Discovery.Demo.Api.This API will act as a service that needs to be discovered by other applications.

Next, configure the API to register with the Consul upon startup. Add the Consul client package to the project

dotnet add package Consul

Step 3: Register a Service in Consul

In the Program.cs, we'll register a service with Consul. When a service starts, it registers itself with Consul using a unique service ID and some metadata.

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
// Consul Configuration
builder.Services.AddSingleton<IConsulClient>(p => new ConsulClient(consulConfig =>
{
    var consulHost = builder.Configuration["Consul:Host"];
    var consulPort = Convert.ToInt32(builder.Configuration["Consul:Port"]);
    consulConfig.Address = new Uri($"http://{consulHost}:{consulPort}");
}));
builder.Services.AddSingleton<IServiceDiscovery, ServiceDiscovery>();

Create a class named ServiceDiscovery that implements the IServiceDiscovery interface to handle service registration:

//IServiceDiscovery interface
public interface IServiceDiscovery
{
    Task RegisterServiceAsync(string serviceName, string serviceId, string serviceAddress, int servicePort);
    Task RegisterServiceAsync(AgentServiceRegistration serviceRegistration);

    Task DeRegisterServiceAsync(string serviceId);
}
//IServiceDiscovery Implementation
 public class ServiceDiscovery : IServiceDiscovery
 {
     private readonly IConsulClient _consulClient;

     public ServiceDiscovery(IConsulClient consulClient)
     {
         _consulClient = consulClient;
     }        

     public async Task RegisterServiceAsync(string serviceName, string serviceId, string serviceAddress, int servicePort)
     {
         var registration = new AgentServiceRegistration
         {
             ID = serviceId,
             Name = serviceName,
             Address = serviceAddress,
             Port = servicePort
         };
         await _consulClient.Agent.ServiceDeregister(serviceId);
         await _consulClient.Agent.ServiceRegister(registration);
     }

     public async Task RegisterServiceAsync(AgentServiceRegistration serviceRegistration)
     {
         await _consulClient.Agent.ServiceDeregister(serviceRegistration.ID);
         await _consulClient.Agent.ServiceRegister(serviceRegistration);
     }
     public async Task DeRegisterServiceAsync(string serviceId)
     {
         await _consulClient.Agent.ServiceDeregister(serviceId);
     }
 }

Now add the service registration logic in Program.cs file

app.MapControllers();
#region Service Registration
var discovery = app.Services.GetRequiredService<IServiceDiscovery>();
var lifetime = app.Services.GetRequiredService<IHostApplicationLifetime>();
var serviceName = builder.Configuration["ServiceRegistration:serviceName"];
var serviceId = builder.Configuration["ServiceRegistration:serviceId"];
var serviceAddress = builder.Configuration["ServiceRegistration:servcieHost"];
var servicePort = Convert.ToInt32(builder.Configuration["ServiceRegistration:servciePort"]);

lifetime.ApplicationStarted.Register(async () =>
{
    var registration = new AgentServiceRegistration
    {
        ID = serviceId,
        Name = serviceName,
        Address = serviceAddress,
        Port = servicePort
    };
    await discovery.RegisterServiceAsync(registration);
});

lifetime.ApplicationStopping.Register(async () =>
{
    await discovery.DeRegisterServiceAsync(serviceId);
});
#endregion

In the above code we are getting host, post and other configuration values from appsettings.json file. Add the below configuration in appsettings.json file.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  /* Consul Config*/
  "Consul": {
    "Host": "localhost",
    "Port": 8500
  },
  /* Service Registration Config*/
  "ServiceRegistration": {
    "serviceName": "DemoApi",
    "serviceId": "6a5f4761-ac01-4407-a81b-831a28894f0f",
    "servcieHost": "locahost",
    "servciePort": "7087"
  }
}

With these configurations, the API will register itself with the Consul upon startup and deregister upon shutdown.

Step 4: Creating the Client Application

Next, create a console application named Service.Discovery.Demo.Client and add the Consul client package to the project.

dotnet add package Consul

In the Program.cs file, configure the Consul client to discover services:

using Consul;

using (var client = new ConsulClient(consulConfig =>
{
    consulConfig.Address = new Uri("http://localhost:8500");
}))
{
    var services = await client.Catalog.Service("DemoAPi");
    foreach (var service in services.Response)
    {
        Console.WriteLine($"Service ID: {service.ServiceID}, Address: {service.ServiceAddress}, Port: {service.ServicePort}");
    }
}
Console.ReadLine();

This code snippet retrieves all instances of the Api service registered with the Consul.

Step 5: Testing the API and Client Application:

Below is the project structure

Now run both applications using the command dotnet run. When this application starts, the Consul portal will display the registered service.

Below is the output of the console application

Conclusion

Service discovery is a crucial component in building microservices at scale. In this post, we covered the basics of service discovery, types of service discovery (client-side and server-side), and demonstrated how to use Consul in a .NET application for registering and discovering services.

Happy coding!! 😊

Implementing an API gateway in a .NET Core application

2024-10-12T17:30:00.111+05:30

The API Gateway Pattern is a design pattern used in microservices architecture. It acts as a single entry point for clients, managing all interactions between them and the backend services. This pattern simplifies client interactions by encapsulating the complexities of multiple microservices, providing features like request routing, load balancing, caching, and security.

Why Use an API Gateway?

Centralized Entry Point: Clients interact with one endpoint rather than multiple services.
Decoupling of Client and Services: The gateway handles communication with services, hiding service details from clients.
Cross-cutting Concerns: It manages functionalities like authentication, logging, rate-limiting, etc., across services.
Load Balancing: Distributes incoming traffic efficiently to backend services.
Security: Acts as a gatekeeper, providing security features like SSL termination and token validation.

Introduction to Ocelot

Ocelot is an open-source API Gateway, designed for microservice architecture. This is based on .NET Core. Ocelot is a set of middleware designed for features such as routing, caching, security, rate limiting, etc. please refer to the link for more details.

Create Simple Services

Let's build a simple API Gateway using ASP.NET Core.We will be creating two simple services for demo purposes.Let us start two services – one is Product Service and another one is Customer Service

Setting up APIs

Product Service will looks like below-

using Microsoft.AspNetCore.Mvc;
using models = Product.MicroService.Models;

namespace Product.MicroService.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class ProductController : ControllerBase
    {
        [HttpGet]
        public IActionResult GetAll()
        {
            var products = new List<models.Product>
            {
                new models.Product { Id = 1, ProductName = "Iphone", Rate = 2000 },
                new models.Product { Id = 2, ProductName = "Samsung Galaxy", Rate = 1800 }
            };
            return Ok(products);
        }
    }
}

Customer Service will looks like below-

using Microsoft.AspNetCore.Mvc;
using models = Customer.MicroService.Models;

namespace Customer.MicroService.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class CustomerController : ControllerBase
    {
        [HttpGet]
        public IActionResult GetAll()
        {
            var customers = new List<models.Customer>
            {
                new models.Customer {Id = 1, Name = "Manish", Email = "test@gmail.com"},
                new models.Customer{Id = 2, Name = "Ashis", Email = "xyz@gmail.com" }
            };
            return Ok(customers);
        }
    }
}

Implement Gateway using Ocelot

Let us go ahead and create an empty ASP.NET Core project. And then install the Ocelot package.

Install-Package Ocelot

Configure Ocelot

We need to create a JSON file – ocelot.json at the root project level in Gateway project.Let us modify the file and configure the Ocelot.json file

{
  "GlobalConfiguration": {
    "BaseUrl": "http://localhost:5003"
  },
  "Routes": [
    {
      "UpstreamPathTemplate": "/gateway/product",
      "UpstreamHttpMethod": [ "Get" ],
      "DownstreamPathTemplate": "/api/product",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5160
        }
      ]
    },
    {
      "UpstreamPathTemplate": "/gateway/customer",
      "UpstreamHttpMethod": [ "Get" ],
      "DownstreamPathTemplate": "/api/customer",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 5173
        }
      ]
    }
  ]
}

This configuration maps incoming requests to specific downstream services:

/gateway/product will forward requests to the Product service running on localhost:5160.
/gateway/customer will forward requests to the Customer service running on localhost:5173.

Configure the Ocelot Middleware

Now we need to configure our project to use the ocelot.json fine. These configuration needs to be done in Program.cs file as below,

builder.Configuration.AddJsonFile("ocelot.json", optional: false, reloadOnChange: true);
builder.Services.AddOcelot(builder.Configuration);

The namespaces which need to be imported are,

using Ocelot.DependencyInjection;
using Ocelot.Middleware;

Now add the Ocelot Middleware in Program.cs

await app.UseOcelot();

As a final step, to run all the services simultaneously, right click on Solution and select Properties, update the below highlighted settings.

Now instead of executing the downstream service, let us go ahead and execute the gateway and see the result.Execute the below Gateway end points and see whether we are getting the expected result

/gateway/product

/gateway/customer

Conclusion

The API Gateway Pattern helps manage complex microservice architectures by providing a unified interface for clients, simplifying the communication between clients and services. Using tools like Ocelot in .NET makes it straightforward to implement an API Gateway that handles routing, security, and load balancing efficiently.

This example is a basic introduction. In a production environment, you would also implement additional features like authentication, rate-limiting, logging, and more.

The full source code is available here:

Happy coding!! 😊

Microservice Design Patterns

2024-09-17T17:30:00.011+05:30

Microservices architecture is a powerful approach to building complex, scalable applications by breaking them down into smaller, independent services. However, designing and managing microservices effectively can be challenging. This is where microservice design patterns come into play. These patterns provide proven solutions to common challenges in microservice architecture, helping developers create systems that are scalable, resilient, and maintainable.

1. API Gateway Pattern

Problem: In a microservice architecture, clients need to interact with multiple services, leading to increased complexity and potential performance bottlenecks.
Solution: Implement an API Gateway that acts as a single entry point for all client requests. The gateway routes requests to the appropriate microservices and can handle tasks like authentication, rate limiting, and load balancing.

Example: Netflix uses Zuul as an API Gateway to handle all incoming traffic and route it to the appropriate services.

2. Circuit Breaker Pattern

Problem: Microservices often depend on other services. If one service fails, it can cause a cascading failure across the entire system.
Solution: The Circuit Breaker pattern prevents this by wrapping calls to external services. If a service is down or slow, the circuit breaker trips, returning a fallback response instead of repeatedly trying to contact the failing service.

Example: Hystrix, a popular library from Netflix, implements the Circuit Breaker pattern to improve system resilience.

3. Service Discovery Pattern

Problem: In dynamic environments where services are constantly being deployed or scaled, finding the location of a service can be challenging.
Solution: Use Service Discovery to maintain a registry of available services and their instances. Services can register themselves and query the registry to locate other services.

Example: Consul and Eureka are commonly used service discovery tools that allow microservices to discover and communicate with each other efficiently.

4. Saga Pattern

Problem: Managing transactions across multiple microservices can be complex since traditional ACID transactions are difficult to implement.
Solution: The Saga pattern breaks down a transaction into smaller steps, each handled by a different service. If one step fails, the saga pattern ensures that compensating actions are taken to rollback the previous steps, ensuring consistency.

Example: An order processing system where creating an order, charging a customer, and updating inventory are handled by separate services. If inventory update fails, the Saga pattern triggers a rollback on the payment service.

5. Event Sourcing Pattern

Problem: Keeping track of the state of a system, especially when multiple services modify the same data, can be difficult.
Solution: Event Sourcing captures changes to the application state as a sequence of events. Each event represents a state change, and the current state of an entity can be derived by replaying these events.

Example: Systems like CQRS (Command Query Responsibility Segregation) often use Event Sourcing to ensure that the read and write sides of an application are eventually consistent.

6. Strangler Fig Pattern

Problem: Migrating a monolithic application to a microservices architecture can be risky and complex if done all at once.
Solution: The Strangler Fig pattern allows for incremental migration by slowly replacing parts of the monolith with microservices. Over time, the monolith "strangles" as more of its functionality is replaced.

Example: Start by extracting a single feature into a microservice and route relevant requests to it. Gradually, move other features to microservices until the monolith is fully deprecated.

7. Bulkhead Pattern

Problem: A failure in one part of a system should not bring down the entire application.
Solution: The Bulkhead pattern isolates different parts of the system, so that a failure in one part doesn’t affect others. This can be achieved by partitioning services or resources, such as thread pools or connection pools.

Example: If one microservice is facing high traffic, the Bulkhead pattern ensures that it doesn’t exhaust all system resources, allowing other services to continue functioning normally.

8. Database per Service Pattern

Problem: Sharing a single database across multiple microservices can lead to tight coupling and difficulties in scaling.
Solution: Each microservice should have its own database, allowing services to be more autonomous, scalable, and resilient. This pattern aligns with the principle of decentralized data management in microservices.

Example: An e-commerce application where the order service, inventory service, and payment service each have their own databases, enabling independent scaling and deployment.

9. Sidecar Pattern

Problem: Some functionalities, such as logging, monitoring, or communication, need to be shared across multiple microservices, leading to code duplication.
Solution: The Sidecar pattern involves deploying helper components alongside microservices in the same container or pod. These sidecars handle cross-cutting concerns without bloating the main service code.

Example: Service mesh solutions like Istio use the Sidecar pattern to handle network-related concerns, such as traffic management and security, without modifying the microservices themselves.

Conclusion

Microservice design patterns are essential tools for building resilient, scalable, and maintainable systems. By applying these patterns thoughtfully, you can overcome many of the challenges inherent in microservice architectures, ensuring that your system is robust and adaptable to change.

Whether you are starting with microservices or optimizing an existing architecture, understanding these design patterns will significantly enhance your ability to design effective solutions.

Happy Learning!! 😊

What are Microservices?

2024-09-16T17:30:00.031+05:30

In today’s fast-paced tech world, businesses need to be agile and responsive to change. One way to achieve this is through the use of microservices. But what exactly are microservices, and why are they so popular?

What Are Microservices?

Microservices is an architectural style in software development where an application is composed of small, independent services, each responsible for a specific function. These services communicate with each other, often via APIs, and work together to fulfill the overall requirements of the application.

Unlike the traditional monolithic architecture, where all components of an application are interconnected and run as a single unit, microservices allow each service to be developed, deployed, and scaled independently. This modular approach gives greater flexibility in managing complex applications.

Key Features of Microservices

Independence: Microservices function as independent units, meaning developers can work on different parts of an application simultaneously without causing interference.
Decentralization: Unlike monolithic architectures where a central database manages the entire application, microservices often use decentralized data management. Each service may manage its own database, leading to better autonomy.
Scalability: Since microservices are independently deployable, individual services can be scaled based on demand without scaling the entire system, making resource management more efficient.
Technology Diversity: Teams can use different programming languages, frameworks, or technologies for each service, allowing them to choose the best tools for the job.
Fault Isolation: In a monolithic application, a failure in one part can potentially bring down the entire system. With microservices, a failure in one service doesn't necessarily impact others, leading to increased system resilience.

Example of Microservices in Action

Imagine an e-commerce website. In a microservices architecture, there might be separate services for:

User authentication: Handles login and user management.
Product catalog: Manages the listing and description of products.
Shopping cart: Tracks items a user has selected for purchase.
Order processing: Manages orders and payments.

Each of these services can be developed and deployed independently, making the overall system more flexible and easier to maintain.

Advantages of Microservices

Faster Time to Market: Teams can develop, test, and deploy services independently, leading to shorter development cycles and quicker releases.
Continuous Delivery: Microservices enable continuous integration and delivery practices, allowing frequent updates without impacting the entire system.
Flexibility in Development: Teams can adopt different technologies for different services, enhancing flexibility in the development process.
Improved Fault Tolerance: A failure in one service won't necessarily disrupt the entire application, leading to better fault tolerance.

Challenges of Microservices

Complexity in Management: Managing multiple services introduces complexity, requiring sophisticated monitoring, logging, and security practices.
Data Consistency: Since each service may have its own database, ensuring data consistency across services can be challenging.
Inter-service Communication: Efficient communication between microservices is essential and can become complex when scaling.

Conclusion

Microservices architecture provides a flexible, scalable approach to building complex applications by breaking them into smaller, independent services. While it introduces new challenges, the benefits in terms of agility, resilience, and scalability make it an attractive choice for modern software development.

Happy Learning!! 😊

Memento Design Pattern in C#

2024-09-13T17:30:00.004+05:30

The Memento Design Pattern is a Behavioral Design Pattern that can restore an object to its previous state. This pattern is useful for scenarios where you need to perform an undo or rollback operation in your application. The Memento pattern captures an object’s internal state so that the object can be restored to this state later. It is especially useful when implementing undo functionality in an application.

Component of Memento Design Pattern

Originator: The object whose state you want to save or restore.
Memento: Stores the internal state of the Originator. It has two interfaces:
- Caretaker Interface: This interface provides no access to the internal state of the Memento. It is used by the Caretaker to manage the Memento without modifying it.
- Originator Interface: This interface allows the Originator to access the Memento to restore its state.
Caretaker: The object that requests the saving and restoring of the Originator’s state.

Implementing Memento Pattern in C#

Define the Memento

namespace MementoPattern
{
    /// <summary>
    /// Memento class to hold the state
    /// </summary>
    public class Memento
    {
        public string State { get; private set; }

        public Memento(string state)
        {
            State = state;
        }
    }
}

Implement the Originator

namespace MementoPattern
{
    /// <summary>
    /// Originator class that uses Memento to save and restore state
    /// </summary>
    public class Originator
    {
        public string State { get; set; }

        public void SetState(string state)
        {
            Console.WriteLine($"Setting state to: {state}");
            State = state;
        }

        public Memento SaveStateToMemento()
        {
            Console.WriteLine("Saving state to Memento.");
            return new Memento(State);
        }

        public void RestoreStateFromMemento(Memento memento)
        {
            State = memento.State;
            Console.WriteLine($"Restored state from Memento: {State}");
        }
    }
}

Create the Caretaker

namespace MementoPattern
{
    /// <summary>
    /// Caretaker class that manages Mementos
    /// </summary>
    public class Caretaker
    {
        private List<Memento> _mementoList = new List<Memento>();

        public void AddMemento(Memento memento)
        {
            _mementoList.Add(memento);
            Console.WriteLine("State saved to Caretaker.");
        }

        public Memento GetMemento(int index)
        {
            return _mementoList[index];
        }
    }
}

Test the Memento Pattern(Program.cs)

// Create Originator and Caretaker objects
using MementoPattern;

Originator originator = new Originator();
Caretaker caretaker = new Caretaker();

// Set and save some states
originator.SetState("State 1");
caretaker.AddMemento(originator.SaveStateToMemento());

originator.SetState("State 2");
caretaker.AddMemento(originator.SaveStateToMemento());

originator.SetState("State 3");
caretaker.AddMemento(originator.SaveStateToMemento());

// Restore previous states
Console.WriteLine("\nRestoring states:");
originator.RestoreStateFromMemento(caretaker.GetMemento(0));
originator.RestoreStateFromMemento(caretaker.GetMemento(1));
Console.ReadLine();

Explanation

The Originator class represents the object whose state needs to be saved and restored. It has a SetState method for changing the state and a SaveStateToMemento method for saving the current state to a Memento.
The Memento class stores the state of the Originator.
The Caretaker class is responsible for keeping a collection of Memento objects. It doesn’t modify or access the internal state of the Memento, but it can store and retrieve them.

Output

Key Takeaway

The Memento pattern is useful for implementing undo/redo functionality by saving different states of an object at different points in time.
The Caretaker stores Memento objects without needing to understand their contents.
The Originator can use a Memento to restore its state at any given point.

This pattern helps to manage the internal state of complex objects in a clean and effective manner without exposing internal details to other classes.

Happy coding!! 😊

Iterator Design Pattern in C#

2024-09-10T17:30:00.005+05:30

The Iterator Design Pattern is a behavioral design pattern that allows sequential access to the elements of an aggregate object (i.e., collection) without exposing its underlying representation. That means using the Iterator Design Pattern, we can access the elements of a collection sequentially without knowing its internal representations. This pattern provides a uniform interface for traversing different data structures.

The collections in C#, like List, ArrayList, Array, etc., are containers containing many objects. In object-oriented programming, the iterator pattern is a design pattern in which an iterator is used to traverse a container and access the elements of the container.

Components of Iterator Pattern

Iterator: The interface that defines the methods for traversing the collection.
Concrete Iterator: The class that implements the iterator interface and performs the actual traversal.

Aggregate: The interface for the collection that provides a method to create an iterator.
Concrete Aggregate: The class that implements the aggregate interface and returns an instance of the concrete iterator.

Example Implementation in C#

Let's create a simple example using the Iterator Pattern. We’ll define a custom collection called BookCollection that holds a list of Book objects. We will implement an iterator to traverse the collection.

Define Book Class

namespace IteratorDesignPattern.Model
{
    public class Book
    {
        public string Title { get; }
        public string Author { get; }

        public Book(string title, string author)
        {
            Title = title;
            Author = author;
        }
    }
}

Define the IIterator interface

namespace IteratorDesignPattern.Iterator
{
    public interface IIterator<T>
    {
        bool HasNext();
        T Next();
    }
}

Implement the BookIterator class

using IteratorDesignPattern.Model;

namespace IteratorDesignPattern.Iterator
{
    public class BookIterator : IIterator<Book>
    {
        private readonly List<Book> _books;
        private int _position = 0;

        public BookIterator(List<Book> books)
        {
            _books = books;
        }

        public bool HasNext()
        {
            return _position < _books.Count;
        }

        public Book Next()
        {
            if (!HasNext())
            {
                return null;
            }

            return _books[_position++];
        }
    }
}

Define the IAggregate interface

using IteratorDesignPattern.Iterator;

namespace IteratorDesignPattern.Aggregator
{
    public interface IAggregate<T>
    {
        IIterator<T> CreateIterator();
    }
}

Implement the BookCollection class

using IteratorDesignPattern.Iterator;
using IteratorDesignPattern.Model;

namespace IteratorDesignPattern.Aggregator
{
    public class BookCollection : IAggregate<Book>
    {
        private readonly List<Book> _books = new List<Book>();

        public void AddBook(Book book)
        {
            _books.Add(book);
        }

        public IIterator<Book> CreateIterator()
        {
            return new BookIterator(_books);
        }
    }
}

Using the Iterator(Program.cs)

using IteratorDesignPattern.Aggregator;
using IteratorDesignPattern.Iterator;
using IteratorDesignPattern.Model;

BookCollection bookCollection = new BookCollection();
bookCollection.AddBook(new Book("Do Epic Shit", "Ankur Wariko"));
bookCollection.AddBook(new Book("To Kill a Mockingbird", "Harper Lee"));
bookCollection.AddBook(new Book("1984", "George Orwell"));

IIterator<Book> iterator = bookCollection.CreateIterator();

while (iterator.HasNext())
{
    Book book = iterator.Next();
    Console.WriteLine($"{book.Title} by {book.Author}");
}
Console.ReadLine();

Output

Explanation

Book Class: Represents a book with a title and an author.
IIterator Interface: Defines the methods HasNext (to check if there are more elements) and Next (to get the next element).
BookIterator Class: Implements the IIterator interface. It maintains the current position in the collection and provides methods to traverse the list of books.
IAggregate Interface: Declares a method CreateIterator to return an iterator for the collection.
BookCollection Class: Implements the IAggregate interface and provides a way to add books to the collection. It also returns an iterator to traverse the books.
Using the Iterator: In Program.cs we use the iterator to traverse the BookCollection. It prints each book's title and author.

Benefits of the Iterator Pattern

Encapsulation: The Iterator pattern hides the internal structure of the collection, allowing you to traverse it without exposing its implementation details.
Flexibility: You can traverse different types of collections using the same interface, making your code more reusable.
Separation of Concerns: By separating the collection and the traversal logic, the pattern promotes cleaner code and better maintainability.

Conclusion

The Iterator pattern is a powerful tool for managing collections in a flexible and reusable manner. By implementing this pattern in C#, you can simplify the traversal of complex collections and keep your codebase clean and maintainable.

The full source code is available here:

Happy coding!! 😊

Interpreter Design Pattern in C#

2024-09-09T17:30:00.011+05:30

The Interpreter Design Pattern is a behavioral design pattern that defines a grammatical representation for a language and provides an interpreter to deal with this grammar. This pattern is particularly useful for designing simple languages or interpreting expressions.

When to Use the Interpreter Pattern

When you have a simple language to interpret.
When you need to interpret expressions in a language.
When the grammar of the language is relatively simple and stable.

Components of Interpreter Design Pattern

The Interpreter pattern involves the following components:

Abstract Expression: Declares an abstract Interpret method.
Terminal Expression: Implements the Interpret method for terminal symbols in the grammar.
Non-Terminal Expression: Implements the Interpret method for non-terminal symbols in the grammar.
Context: Contains information that’s global to the interpreter.

Example in C#: Simple Arithmetic Interpreter

Let’s create a simple arithmetic interpreter that can evaluate expressions like “3 + 5 - 2”.

Define the Abstract Expression

namespace InterpreterPattern
{
    /// <summary>
    /// Abstract Expression
    /// </summary>
    public abstract class Expression
    {
        public abstract int Interpret();
    }
}

Define Terminal Expressions

namespace InterpreterPattern
{
    /// <summary>
    /// Terminal Expression
    /// </summary>
    public class NumberExpression : Expression
    {
        private int _number;

        public NumberExpression(int number)
        {
            _number = number;
        }

        public override int Interpret()
        {
            return _number;
        }
    }
}

Define Non-Terminal Expressions

// Add Expression
namespace InterpreterPattern
{
    /// <summary>
    /// Non-Terminal Expression
    /// </summary>
    public class AddExpression : Expression
    {
        private Expression _leftExpression;
        private Expression _rightExpression;

        public AddExpression(Expression leftExpression, Expression rightExpression)
        {
            _leftExpression = leftExpression;
            _rightExpression = rightExpression;
        }

        public override int Interpret()
        {
            return _leftExpression.Interpret() + _rightExpression.Interpret();
        }
    }
}

//Subtract Expression
namespace InterpreterPattern
{
    /// <summary>
    /// Non-Terminal Expression
    /// </summary>
    public class SubtractExpression : Expression
    {
        private Expression _leftExpression;
        private Expression _rightExpression;

        public SubtractExpression(Expression leftExpression, Expression rightExpression)
        {
            _leftExpression = leftExpression;
            _rightExpression = rightExpression;
        }

        public override int Interpret()
        {
            return _leftExpression.Interpret() - _rightExpression.Interpret();
        }
    }
}

Define the Context

namespace InterpreterPattern
{
    /// <summary>
    /// Context
    /// <summary>
    public class Context
    {
        private Dictionary<string, int> _variables;

        public Context()
        {
            _variables = new Dictionary<string, int>();
        }

        public int GetVariable(string name)
        {
            return _variables[name];
        }

        public void SetVariable(string name, int value)
        {
            _variables[name] = value;
        }
    }
}

Client Code(Program.cs)

// Example: (3 + 5) - 2
using InterpreterPattern;

Expression expression = new SubtractExpression(
    new AddExpression(
        new NumberExpression(3),
        new NumberExpression(5)
    ),
    new NumberExpression(2)
);

Console.WriteLine($"Result: {expression.Interpret()}");
Console.WriteLine();

Explanation

NumberExpression: Represents numbers in the expression.
AddExpression: Represents addition operations.
SubtractExpression: Represents subtraction operations.
Context: Holds any global information needed by the interpreter (not used in this simple example).
InterpreterClient: Constructs the expression tree and interprets it.

Conclusion

The Interpreter Design Pattern is a powerful tool for evaluating expressions defined by a formal grammar. While this example demonstrates arithmetic operations, the pattern can be extended to handle more complex languages and operations.

By structuring your code using the Interpreter pattern, you can keep the logic for interpreting each type of expression encapsulated within its own class, leading to a clean and maintainable design.

The full source code is available here:

Happy coding!! 😊

Route Guards in Angular

2024-09-04T17:30:00.002+05:30

When building Angular applications, managing access to different routes is crucial for both security and user experience. Angular provides a robust mechanism called Route Guards to control navigation. Let’s dive into what Route Guards are, the different types available, and how to implement them with examples.

What are Route Guards?

Route Guards are interfaces that allow you to control the navigation to and from routes in your Angular application. They help you decide whether a user can access a particular route or not. There are several types of Route Guards:

CanActivate: Determines if a route can be activated.
CanActivateChild: Determines if child routes can be activated.
CanDeactivate: Determines if a route can be deactivated.
CanLoad: Determines if a module can be loaded.
CanMatch: Determines if a route can be matched.

Implementing CanActivate Guard

The CanActivate guard is used to check if a user can navigate to a route. Here’s an example where we use an authentication service to check if the user is logged in.

Step 1: Create the Auth Service

First, create an authentication service that will handle the login logic.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class AuthService {
  private isLoggedIn = false;

  login() {
    this.isLoggedIn = true;
  }

  logout() {
    this.isLoggedIn = false;
  }

  isAuthenticated(): boolean {
    return this.isLoggedIn;
  }
}

Step 2: Create the CanActivate Guard

Next, create the guard that implements the CanActivate interface.

import { Injectable } from '@angular/core';
import { CanActivate, ActivatedRouteSnapshot, RouterStateSnapshot, Router } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable({
  providedIn: 'root'
})
export class AuthGuard implements CanActivate {

  constructor(private authService: AuthService, private router: Router) {}

  canActivate(
    route: ActivatedRouteSnapshot,
    state: RouterStateSnapshot): boolean {
    if (this.authService.isAuthenticated()) {
      return true;
    } else {
      this.router.navigate(['/login']);
      return false;
    }
  }
}

Step 3: Apply the Guard to Routes

Finally, apply the guard to the routes in your routing module.

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { HomeComponent } from './home/home.component';
import { DashboardComponent } from './dashboard/dashboard.component';
import { AuthGuard } from './auth.guard';

const routes: Routes = [
  { path: '', component: HomeComponent },
  { path: 'dashboard', component: DashboardComponent, canActivate: [AuthGuard] }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Other Types of Guards

CanActivateChild

This guard works similarly to CanActivate but applies to child routes.

import { Injectable } from '@angular/core';
import { CanActivateChild } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable({
  providedIn: 'root'
})
export class AuthChildGuard implements CanActivateChild {

  constructor(private authService: AuthService) {}

  canActivateChild(): boolean {
    return this.authService.isAuthenticated();
  }
}

CanDeactivate

This guard is used to prevent users from leaving a route if certain conditions are not met, such as unsaved changes.

import { Injectable } from '@angular/core';
import { CanDeactivate } from '@angular/router';
import { Observable } from 'rxjs';

export interface CanComponentDeactivate {
  canDeactivate: () => Observable<boolean> | Promise<boolean> | boolean;
}

@Injectable({
  providedIn: 'root'
})
export class CanDeactivateGuard implements CanDeactivate<CanComponentDeactivate> {

  canDeactivate(component: CanComponentDeactivate): Observable<boolean> | Promise<boolean> | boolean {
    return component.canDeactivate ? component.canDeactivate() : true;
  }
}

Conclusion

Route Guards in Angular are powerful tools for managing access to different parts of your application. By using guards like CanActivate, CanActivateChild, and CanDeactivate, you can enhance the security and user experience of your app. Implementing these guards is straightforward and can be customized to fit your specific needs.

Happy coding!! 😊

Lifecycle of an Angular service

2024-09-03T17:30:00.000+05:30

Understanding the lifecycle of an Angular service is crucial for effectively managing dependencies and ensuring optimal performance in your application. Here’s a breakdown of the lifecycle of an Angular service:

1. Creation

When a service is first requested by a component, directive, or another service, Angular’s dependency injection system creates an instance of the service. This happens only once if the service is provided at the root level or a module level, ensuring a singleton instance.

@Injectable({
  providedIn: 'root',
})
export class MyService {
  constructor() {
    console.log('MyService instance created');
  }
}

2. Injection

The created instance is then injected into the requesting component, directive, or service. This is done through the constructor of the class where the service is needed.

@Component({
  selector: 'app-my-component',
  template: `{{ message }}`,
})
export class MyComponent {
  message: string;

  constructor(private myService: MyService) {
    this.message = this.myService.getMessage();
  }
}

3. Usage

The methods and properties of the service are used by the component, directive, or another service. This is where the main functionality of the service is utilized.

@Injectable({
  providedIn: 'root',
})
export class MyService {
  getMessage() {
    return 'Hello from MyService!';
  }
}

4. Destruction

Angular does not explicitly destroy services. Instead, services are subject to JavaScript’s garbage collection. When there are no more references to the service instance, it becomes eligible for garbage collection. This typically happens when the component or module that requested the service is destroyed.

Key Points to Remember

Singleton Services: When a service is provided at the root level (providedIn: 'root'), it is a singleton, meaning only one instance of the service exists throughout the application.
Scoped Services: When a service is provided at a module or component level, it can have multiple instances, each scoped to the module or component where it is provided.
Lazy Loading: Services provided in lazy-loaded modules are created only when the module is loaded, which can help optimize performance by loading services only when needed.

Example Scenario

App Initialization: The application starts, and no services are instantiated yet.
Component Request: A component requests a service.
Service Creation: Angular’s DI system creates an instance of the service.
Service Injection: The service instance is injected into the component.
Service Usage: The component uses the service’s methods and properties.
Component Destruction: When the component is destroyed, the service instance remains if it is a singleton. If the service is scoped to the component, it becomes eligible for garbage collection.

Understanding this lifecycle helps in designing services that are efficient, reusable, and maintainable.

Happy coding!! 😊

Hierarchical Dependency Injection in Angular

2024-09-02T17:30:00.015+05:30

Hierarchical Dependency Injection (DI) in Angular is a powerful feature that allows you to control the scope and lifetime of services. It enables you to create a hierarchy of injectors, where each injector can provide its own set of dependencies. This hierarchy mirrors the component tree, allowing for fine-grained control over which services are available to which parts of your application.

How Hierarchical Dependency Injection Works?

In Angular, every component has its own injector, and these injectors form a hierarchy. The root injector is created when the application starts, and child injectors are created for each component. When a component requests a dependency, Angular starts at the component’s injector and works its way up the hierarchy until it finds a provider for the requested dependency.

Example

Let’s look at an example to understand how hierarchical DIworks.

Step 1: Create a Service

First, we’ll create a simple service.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class LoggerService {
  log(message: string) {
    console.log(message);
  }
}

Step 2: Create Components

Next, we’ll create a parent component and a child component .

import { Component } from '@angular/core';
import { LoggerService } from './logger.service';

@Component({
  selector: 'app-parent',
  template: `
    <h1>Parent Component</h1>
    <app-child></app-child>
  `,
  providers: [LoggerService],
})
export class ParentComponent {
  constructor(private logger: LoggerService) {
    this.logger.log('Parent Component Initialized');
  }
}

@Component({
  selector: 'app-child',
  template: `<h2>Child Component</h2>`,
})
export class ChildComponent {
  constructor(private logger: LoggerService) {
    this.logger.log('Child Component Initialized');
  }
}

In this example, the ParentComponent provides the LoggerService. The ChildComponent does not provide the LoggerService, so it will use the instance provided by the ParentComponent.

Step 3: Register Components in a Module

Finally, we’ll register the components in a module.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent } from './app.component';
import { ParentComponent } from './parent.component';
import { ChildComponent } from './child.component';

@NgModule({
  declarations: [AppComponent, ParentComponent, ChildComponent],
  imports: [BrowserModule],
  bootstrap: [AppComponent],
})
export class AppModule {}

Key Points

Injector Hierarchy: Each component has its own injector, forming a hierarchy that mirrors the component tree.
Provider Scope: Providers can be registered at different levels (root, module, component), controlling the scope and lifetime of services.
Dependency Resolution: Angular starts at the component’s injector and works its way up the hierarchy to resolve dependencies.

Benefits of Hierarchical Dependency Injection

Scoped Services: You can create services that are scoped to specific parts of your application, improving modularity and encapsulation.
Optimized Performance: By limiting the scope of services, you can reduce memory usage and improve performance.
Flexible Configuration: Different parts of your application can use different configurations of the same service.

Hierarchical DI is a powerful feature that allows you to build scalable and maintainable Angular applications by providing fine-grained control over service instances and their lifetimes.

Happy coding!! 😊

Difference between providedIn and providers array

2024-08-28T17:30:00.003+05:30

providedIn

The providedIn property is used within the @Injectable decorator to specify where the service should be provided. This is a more modern and preferred way to provide services in Angular.

Global Scope: When you use providedIn: 'root', the service is registered with the root injector, making it a singleton and available throughout the entire application.

@Injectable({
  providedIn: 'root',
})
export class MyService {
  constructor() { }
}

Feature Module Scope: You can also specify a feature module to limit the scope of the service.

@Injectable({
  providedIn: SomeFeatureModule,
})
export class MyService {
  constructor() { }
}

providers Array

The providers array is used within the @NgModule or @Component decorators to register services. This method is more traditional and offers more granular control over the scope of the service.

Module Level: When you add a service to the providers array in an @NgModule, the service is available to all components declared in that module.

@NgModule({
  providers: [MyService]
})
export class AppModule { }

Component Level: When you add a service to the providers array in a component’s decorator, the service is available only to that component and its children.

@Component({
  selector: 'app-my-component',
  providers: [MyService],
  template: `<p>{{ message }}</p>`,
})
export class MyComponent {
  constructor(private myService: MyService) { }
}

Key Differences

Scope:
1. providedIn: 'root': Service is available application-wide.
2. providers array: Service scope can be limited to a specific module or component.
Singleton:
1. providedIn: 'root': Ensures a singleton instance across the entire application.
2. providers array: Can create multiple instances if provided at different levels (e.g., module and component).
Tree Shaking:
1. providedIn: Supports tree shaking, meaning unused services can be removed during the build process.
2. providers array: Does not support tree shaking as effectively.

Conclusion

Using providedIn is generally recommended for its simplicity and efficiency, especially for services that need to be available application-wide. The providers array is useful when you need more control over the scope and lifecycle of your services.

Happy coding!! 😊

Understanding Providers in Angular

2024-08-27T17:30:00.007+05:30

In Angular, providers are a fundamental concept that allows you to inject dependencies into your components, services, and other parts of your application. They play a crucial role in Angular's dependency injection (DI) system, making it easier to manage and share services across your application.

What is a Provider?

A provider is an instruction to the Angular dependency injection system on how to obtain a value for a dependency. When you configure a provider, you tell Angular how to create an instance of a service or value that can be injected into components, directives, pipes, or other services.

Types of Providers

Angular supports several types of providers:

1- Class Providers: The most common type, where you provide a class to be instantiated by the DI system.


@Injectable({
  providedIn: 'root',
})
export class MyService {
  constructor() { }
}

2- Value Providers: Use this to provide a simple value.

const MY_VALUE = { key: 'value' };

@NgModule({
  providers: [{ provide: 'myValue', useValue: MY_VALUE }]
})
export class AppModule { }

3- Factory Providers: Use a factory function to create the value.

export function myFactory() {
  return new MyService();
}

@NgModule({
  providers: [{ provide: MyService, useFactory: myFactory }]
})
export class AppModule { }

4- Existing Providers: Alias an existing provider.

@NgModule({
  providers: [{ provide: MyService, useExisting: AnotherService }]
})
export class AppModule { }

Where to Provide Services?

You can provide services at different levels in your Angular application:

Root Level: By using the providedIn: 'root' syntax in the @Injectable decorator, the service is available application-wide.
Module Level: By adding the service to the providers array in an @NgModule decorator, the service is available to all components declared in that module.
Component Level: By adding the service to the providers array in a components's decorator, the service is available only to that components and its children.

Example: Using a Service in a Component

Here’s a simple example of how to use a service in a components:

Create a Service:

@Injectable({
  providedIn: 'root',
})
export class DataService {
  getData() {
    return 'Hello from DataService!';
  }
}

Inject the Service into a Component:

@Component({
  selector: 'app-my-component',
  template: `{{ message }}`,
})
export class MyComponent implements OnInit {
  message: string;

  constructor(private dataService: DataService) { }

  ngOnInit() {
    this.message = this.dataService.getData();
  }
}

Conclusion

Providers are a powerful feature in Angular that facilitate dependency injection, making your code more modular, testable, and maintainable. By understanding and utilizing different types of providers, you can effectively manage dependencies in your Angular applications.

Happy coding!! 😊

Understanding Lazy-Loaded Modules in Angular

2024-08-26T17:30:00.004+05:30

Lazy loading is a design pattern in Angular that allows you to load modules only when they are needed, rather than loading all modules upfront. This can significantly improve the performance of your application by reducing the initial load time.

What is a Lazy-Loaded Module?

A lazy-loaded module is an Angular module that is loaded on demand. Instead of being included in the main bundle, it is loaded asynchronously when the user navigates to a route that requires the module.

Example:

Let’s create a simple example to demonstrate lazy loading.

Step 1: Create a Feature Module

First, we’ll create a feature module that we want to lazy load.

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { FeatureComponent } from './feature.component';
import { RouterModule } from '@angular/router';

@NgModule({
  declarations: [FeatureComponent],
  imports: [
    CommonModule,
    RouterModule.forChild([
      { path: '', component: FeatureComponent }
    ])
  ]
})
export class FeatureModule {}

Step 2: Configure Lazy Loading in the App Routing Module

Next, we’ll configure the app routing module to lazy load the feature module.

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';

const routes: Routes = [
  { path: 'feature', loadChildren: () => import('./feature/feature.module').then(m => m.FeatureModule) }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule {}

In this example, the FeatureModule is lazy-loaded when the user navigates to the /feature route.

Impact on Dependency Injection Hierarchy

Lazy-loaded modules have their own injector, which is a child of the root injector. This has several implications for dependency injection:

Scoped Services: Services provided in a lazy-loaded module are scoped to that module. This means that each lazy-loaded module can have its own instance of a service, separate from the root injector and other lazy-loaded modules.
Service Isolation: Services provided in a lazy-loaded module are not available to the rest of the application unless explicitly provided at a higher level (e.g., in the root module).
Memory Management: Lazy loading can help with memory management by loading services only when needed and potentially unloading them when the module is no longer in use.

Example:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class RootService {
  constructor() {}
}

@Injectable()
export class LazyService {
  constructor() {}
}

In this example, RootService is provided at the root level and is available throughout the application. LazyService, on the other hand, is provided in a lazy-loaded module and is only available within that module.

Feature Module:

@NgModule({
  providers: [LazyService],
  // other module metadata
})
export class FeatureModule {}

Key Points

Lazy Loading: Modules are loaded on demand, improving initial load time and performance.
Scoped Services: Services in lazy-loaded modules are scoped to those modules, allowing for isolated instances.
Injector Hierarchy: Lazy-loaded modules have their own injectors, which are children of the root injector.

Benefits of Lazy Loading

Improved Performance: Reduces the initial load time by loading only the necessary modules.
Modular Architecture: Encourages a modular architecture by isolating features and their dependencies.
Better Resource Management: Loads resources only when needed, potentially reducing memory usage.

Lazy loading is a powerful feature in Angular that, when combined with hierarchical dependency injection, allows for efficient and modular application design.

Happy coding!! 😊

Understanding Angular Dependency Injection

2024-08-22T17:30:00.002+05:30

Dependency Injection (DI) is a design pattern used to implement IoC (Inversion of Control), allowing a class to receive its dependencies from an external source rather than creating them itself. Angular’s DI system is a powerful feature that makes it easy to manage dependencies and promote code reusability and testability.

How Dependency Injection Works in Angular?

In Angular, DI is used to provide components, services, and other classes with the dependencies they need. The Angular injector is responsible for creating and managing these dependencies. Here’s a step-by-step explanation of how DI works in Angular:

Providers: A provider is an object that tells the injector how to create a dependency. Providers can be registered at different levels (module, component, or service).
Injector: The injector is responsible for creating instances of dependencies and injecting them into the classes that need them.
Tokens:Tokens are used to uniquely identify a dependency. They can be class types, strings, or injection tokens.

Example: Using Dependency Injection in Angular

Let’s create a simple example to demonstrate how DI works in Angular.

Step 1: Create a Service

First, we’ll create a service that provides some data.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class DataService {
  constructor() {}

  getData() {
    return ['Item1', 'Item2', 'Item3'];
  }
}

In this example, the DataService class is decorated with @Injectable, making it available for injection throughout the application.

Step 2: Inject the Service into a Component

Next, we’ll create a component and inject the DataService into it.

import { Component, OnInit } from '@angular/core';
import { DataService } from './data.service';

@Component({
  selector: 'app-data',
  template: `
    <h1>Data from Service</h1>
    <ul>
      <li *ngFor="let item of data">{{ item }}</li>
    </ul>
  `,
})
export class DataComponent implements OnInit {
  data: string[];

  constructor(private dataService: DataService) {}

  ngOnInit() {
    this.data = this.dataService.getData();
  }
}

In this example, the DataComponent class has a dependency on DataService. The DataService is injected into the component's constructor, and its getData method is called to retrieve data.

Step 3: Register the Service in a Module (if not using providedIn: 'root')

If you are not using the providedIn: 'root' syntax, you need to register the service in a module.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent } from './app.component';
import { DataComponent } from './data.component';
import { DataService } from './data.service';

@NgModule({
  declarations: [AppComponent, DataComponent],
  imports: [BrowserModule],
  providers: [DataService],
  bootstrap: [AppComponent],
})
export class AppModule {}

In this example, the DataService is registered in the providers array of the AppModule.

Benefits of Dependency Injection

Reusability: Services can be reused across different components.
Testability: Dependencies can be easily mocked or replaced in unit tests.
Maintainability: Dependencies are managed in a centralized way, making the codebase easier to maintain.

Happy coding!! 😊

Dot Net World

Building a Web Scraping RAG Pipeline in .NET Using GitHub Models

What This Project Does?

Architecture Overview

How the RAG Pipeline Works?

Web Scraping

Text Chunking

Embeddings with GitHub Models

Vector Similarity Search

Prompt Construction

Chat Completion

Running the Application

Console Commands

Content Projection in Angular

What is Content Projection?

Types of Content Projection

Example: Single-Slot Content Projection

Step 1: Create a Child Component

Child Component

Step 2: Use the Child Component in a Parent Component

Parent Component

Result

Example: Multi-Slot Content Projection

Step 1: Update the Child Component Template

Child Component

Step 2: Update the Parent Component Template

Parent Component

Result

Benefits of Content Projection

Conclusion

Angular(DI) Resolution Modifiers

What Are Resolution Modifiers?

@Optional

@Self

@SkipSelf

@Host

Practical Scenarios

Conclusion

Angular Preloading Strategy : Enhancing User Experience and Performance

What is PreloadStrategy?

Why Use Preloading?

How Does Preloading Work?

Step 1: Configuring the Router

Step 2: Including the Router in Your Application

Customizing PreloadStrategy

Creating a Custom PreloadStrategy

Using the Custom Strategy

Conclusion

Understanding Resolvers in Angular

What is a Resolver in Angular?

Why Use Resolvers?

Implementing a Resolver

Step 1: Define the Resolver Function

Step 2: Configure the Route

Step 3: Access Resolved Data in the Component

User Details

Conclusion

Understanding ClaimsPrincipal, ClaimsIdentity, and Claim in C#

Understanding Claims-Based Identity

Claim, ClaimsIdentity, and ClaimsPrincipal

Claim

ClaimsIdentity

ClaimsPrincipal

How Claims-Based Identity Works in ASP.NET Core

Example: Adding Claims to the User in ASP.NET Core

Advantages of Using Claims-Based Identity

Conclusion

Exploring HybridCache in .Net 9

What is HybridCache?

Key Features of HybridCache

Setting Up HybridCache

Install the Package

Register the Service

Using HybridCache

Benefits of HybridCache

Conclusion

Polly in .NET Core: A Guide to Resilience and Fault Handling

What is Polly?

Why Use Polly?

Getting Started with Polly in .NET Core