Forem: Lobito

Understanding the Difference Between Proxy and Reverse Proxy

Lobito — Fri, 22 Mar 2024 10:52:19 +0000

Hey guys!

If you are working in the web architecture, proxies and reverse proxies play vital roles in facilitating communication between clients and servers. Despite sharing similar concepts, they serve distinct purposes and have different functionalities.
There is some confusion around this two concepts.
Let's put in the table the definitions.

Proxy:

A proxy server acts as an intermediary between a client and a server. When a client sends a request to access a resource, it doesn't directly communicate with the target server; instead, it communicates with the proxy server. The proxy server then forwards the request to the target server on behalf of the client. Upon receiving the response from the server, the proxy server sends it back to the client.

Key Characteristics of a Proxy:

Client-Side Proxy: Proxies primarily operate on the client side, intercepting requests before they reach the destination server.
Anonymity and Security: Proxies can enhance security and privacy by masking the client's IP address and providing anonymity.
Caching: Proxies can cache frequently accessed resources, improving performance by serving cached content to clients without needing to fetch it from the server every time.
Content Filtering: Proxies can filter content based on predefined rules, allowing organizations to control access to specific websites or content categories.

Reverse Proxy:

A reverse proxy, on the other hand, sits between the internet and web servers, forwarding client requests to the appropriate backend servers. Unlike a regular proxy, which forwards requests from clients to servers, a reverse proxy receives requests from clients and directs them to the appropriate backend server based on factors like load balancing, content caching, or other criteria.

Key Characteristics of a Reverse Proxy:

Server-Side Proxy: Reverse proxies operate on the server side, intercepting requests before they reach the destination servers.
Load Balancing: Reverse proxies distribute client requests across multiple servers, balancing the load and ensuring efficient resource utilization.
SSL Termination: Reverse proxies can handle SSL/TLS encryption and decryption, relieving backend servers of this resource-intensive task.
Content Caching: Similar to regular proxies, reverse proxies can cache content to improve performance and reduce the load on backend servers.

Key Differences:

Direction of Traffic: Proxies intercept client requests, while reverse proxies intercept requests before they reach backend servers.
Location: Proxies are typically deployed on the client side, while reverse proxies are deployed on the server side.
Functionality: Proxies focus on client-side tasks like anonymity, caching, and content filtering, whereas reverse proxies handle server-side tasks like load balancing, SSL termination, and content caching.

In conclusion, while both proxies and reverse proxies act as intermediaries in network communication, they serve different purposes and operate at different points in the client-server interaction. Understanding these distinctions is crucial for designing robust and efficient network architectures.

In a scenario of the web development you will work a lot with reverse proxy or API Gateway. A common package in .net is Ocelot library that make it possible create in a easy way API Gateways for your projects.
Stay tune! In the next article I will write about API Gateways and Ocelot.

Create a ASP.NET Web API with MongoDB

Lobito — Thu, 14 Mar 2024 15:19:56 +0000

Hello everybody,

Continuing my learning path to become a better and more complete developer I challenge myself to learn a little bit about MongoDB that will be consumed by my ASP.NET Core Web Api.

First things first, for those who don´t know what a hell is a MongoDB I will give a short explanation for what I learn in this challenge.

MongoDB is a NOSQL database and NOSQL means "Not Only SQL". This is because MongoDB is not only a relational database. NOSQL can store unstructured data.

Acording to the definition given by ChatGPT: _"A NoSQL database is a type of database that provides a mechanism for storage and retrieval of data that is modeled in ways other than the tabular relations used in relational databases. It's often used for large-scale distributed data storage and real-time web applications, offering flexibility, scalability, and performance advantages over traditional relational databases." _

So, in practice, MongoDB as NOSQL database is organized like this:
Database -> Collection -> Documents.

The data is stored in a BSON format (Binary Json). Each pieace of this json is a Document. So in this example we have three documents.

And this documents are stored in collections (you can compare a collection like as a table in SQL Relational databases)

And all this collections are stored in a database!

To start using MongoDB the first thing that you need is the MongoDB "engine". For that I recommend using a image container and run that image in the docker container.
You can find all the images available and also MongoDB here:
MongoDB container image

After pull the image and run it, you need a way to interact with the database. You can choose using for example MongoDB Shell or some GUI tool like MongoDB Compass.

Here you can find a good MongoDB Cheat Sheet where you can explore how manipulate the data in MongoDB.

Ok, this was just a brief about MongoDB, now let´s talk about how use MongoDB in a ASP.NET Core Web API.

The first this that you must do is create obviously a new asp.net core web api from your visual studio or vscode.

I will not demonstrate step-by-step everything because it will be boring and also you can download the source code from my GitHub.

After the project is created you need install the nuget package for the MongoDB Driver.

I organize my project in that way and I only show here the fundamentals. You can organize in other architecture.

I have in the Model folder a SuperHero class that represent the document in MongoDB.

Important things here is the data attributes to identify the field Id and map the c# names with MongoDB names.

Another thing that you need is to establish connection to the MongoDb. In this example I create a factory class to do that.

The configurations of MongoDB connection string is in the appsettings.json.

Now, all the magic is in the Repository class. I create a SuperHeroRepository that abstract the data manipulation. In this example the repository do the CRUD operations for MongoDB.

public class SuperHeroRepository : ISuperHeroRepository
    {
        private readonly IMongoDbConnectionFactory _connectionFactory;
        private readonly IMongoCollection<SuperHero> _collection;

        public SuperHeroRepository(IMongoDbConnectionFactory connectionFactory)
        {
            _connectionFactory = connectionFactory;

            var database = _connectionFactory.GetDatabase();
            _collection = database.GetCollection<SuperHero>("superhero");

        }

        public async Task<bool> Create(SuperHero hero)
        {
            try
            {
                await _collection.InsertOneAsync(hero);
                return true;
            }
            catch (Exception)
            {
                throw;
            }
        }

        public async Task<bool> Delete(string id)
        {
            var filterDefinition = Builders<SuperHero>.Filter.Eq(a => a.Id, id);
            var result = await _collection.DeleteOneAsync(filterDefinition);
            return result.DeletedCount > 0;
        }

        public async Task<List<SuperHero>> GetAll()
        {
            return await _collection.Find(Builders<SuperHero>.Filter.Empty).ToListAsync();
        }

        public async Task<SuperHero> GetById(string id)
        {
            var filterDefinition = Builders<SuperHero>.Filter.Eq(a => a.Id, id);
            return await _collection.Find(filterDefinition).FirstAsync();
        }

        public async Task<bool> Update(SuperHero hero)
        {
            var filterDefinition = Builders<SuperHero>.Filter.Eq(a=>a.Id, hero.Id);
            var result = await _collection.ReplaceOneAsync(filterDefinition, hero);
            return result.ModifiedCount > 0;
        }
    }

Now you need to create your controller that will receive by dependency injection the ISuperHeroRepository. In the Http methods you will call the respective CRUD action.

Lets see the GetAll example:

Another interesting thing is the way how we filter some query with MongoDB Drive.

In this example, I'm filtering the collection only by the super hero id.

And that's it guys, just sharing my learning with someone.

The source code in the my GitHub.

Feel free to clone and happy coding!

Repository Pattern in c#

Lobito — Fri, 08 Mar 2024 10:35:56 +0000

Any good software must be guided by design patterns. Design patterns are nothing more, nothing less than a set of best practices and mechanisms to make the code more robust, organized, and easy to maintain.

There are different design patterns for different situations and today, we will focus on one of the most commonly used patterns: the Repository Pattern.

The Repository Pattern is a design pattern commonly used in software development, particularly in applications that interact with databases or other data sources. It provides an abstraction layer between the application's business logic and the data access logic.

In essence, the Repository Pattern involves creating an interface or class (the repository) that defines methods for accessing data, such as querying, adding, updating, and deleting records. This repository acts as a mediator between the application's code and the data storage mechanism, abstracting away the details of how data is retrieved and manipulated.

With a repository pattern and the abstraction it provides, it's very simple, for example, to switch databases in an application. Let's imagine that we want to switch from a SQL Server database to MongoDB. All that will be needed is to implement a new repository implementation to apply the logic to MongoDB.

I'll present here a simple example of implementing a repository for a customer API. This API will have the following methods: GetAll, GetById, and Add.

The first thing to do is to create an interface that will define the repository contract. In this case, the interface will require the implementation of the GetAll, GetById, and Add methods.

public interface ICustomerRepository
    {
        Task<Customer> GetById(int id);
        Task<List<Customer>> GetAll();
        Task<Customer> Add(Customer customer);
    }

And our Customer model is a simple class with the following fields:

 [Table("customer")]
    public class Customer
    {
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        [Column("customer_id")]
        public int CustomerId { get; set; }
        [Column("customer_name")]
        public string CustomerName { get; set; }
        [Column("mobile_no")]
        public string MobileNumber { get; set; }
        [Column("email")]
        public string Email { get; set; }
    }

With the interface created, the next step is to implement these methods in a class called CustomerRepository, which will implement the previously created interface ICustomerRepository.

public class CustomerRepository : ICustomerRepository
    {
        private readonly CustomerDbContext _customerDbContext;

        public CustomerRepository(CustomerDbContext customerDbContext)
        {
            _customerDbContext = customerDbContext;
        }

        public async Task<Customer> Add(Customer customer)
        {

            var result = _customerDbContext.Customers.Add(customer);
            await _customerDbContext.SaveChangesAsync();
            return result.Entity;    
        }

        public async Task<Customer> GetById(int id)
        {
            return await _customerDbContext.Customers.FirstOrDefaultAsync(a => a.CustomerId == id);
        }

        public async Task<List<Customer>> GetAll()
        {
            return await _customerDbContext.Customers.ToListAsync();
        }
    }

In this application, I'm using a local SQL Server database to store information, but let's keep the example simple and leave the database for another example.

Now, what we need to do is create the controller for our API, which will call our repository. This controller will receive the repository via dependency injection, allowing it to access all the methods implemented earlier.

[Route("api/[controller]")]
    [ApiController]
    public class CustomerController : ControllerBase
    {
        private readonly ICustomerRepository _customerRepository;
        public CustomerController(ICustomerRepository customerRepository)
        {
            _customerRepository = customerRepository;
        }

        [HttpGet]
        [Route("getAll")]
        public ActionResult<IEnumerable<Customer>> GetCustomers()
        {
            return _customerRepository.GetAll().Result;
        }

        [HttpGet]
        [Route("{id}")]
        public ActionResult<Customer> GetCustomers(int id)
        {
            return _customerRepository.GetById(id).Result;
        }

        [HttpPost]
        [Route("add")]
        public ActionResult<Customer> Create([FromBody]Customer customer)
        {
            var newCustomer =   _customerRepository.Add(customer).Result;
            return Ok(newCustomer);
        }
    }

As you can see in the controller, we receive the repository via dependency injection and assign it in the constructor. Then, in each of the REST methods, we access the repository through the "_customerRepository".

The last thing to do is register our repository implementation in the C# dependency container. To do this, in the Program.cs, we'll register our implementation.

builder.Services.AddScoped<ICustomerRepository, CustomerRepository>();

You can find this example in my github repository:
Github

SOLID Principles

Lobito — Tue, 05 Mar 2024 21:54:21 +0000

As a software developer for a decade, I've come to realize that myself and a significant percentage of programmers are not prioritizing good practices, or at least, these concerns are not among our top priorities.
However, I decide revert this and learn to become a better professional.

I’m writing these articles as my personal notes and hope motivate you to be a better programmer as well.

So let’s start for the beginning: SOLID principles!

The SOLID principles are a set of five design principles intended to make software designs more understandable, flexible, and maintainable. They are:

1 - Single Responsibility Principle (SRP): A class should have only one reason to change, meaning it should have only one responsibility or job.
We all did the mistake to have a huge class that do more than one thing and different things with different contexts.


public class UserManagementSystem
{
    public void AddUser(User user)
    {
        // Add user to the database
    }

    public void DeleteUser(User user)
    {
        // Delete user from the database
    }

    public void SendEmailToUser(User user, string message)
    {
        // Send email to the user
    }

    public void GenerateReportForUser(User user)
    {
        // Generate report for the user
    }
}

In this example, the UserManagementSystem class is responsible for multiple tasks: adding/deleting users, sending emails, and generating reports. This violates the SRP because the class has multiple reasons to change: if the database structure changes, if the email service changes, or if the report generation logic changes. It would be better to separate these responsibilities into distinct classes.

2 - Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that you should be able to add new functionality without altering existing code.


public class Shape
{
    public string Type { get; set; }

    public double Area()
    {
        if (Type == "Rectangle")
        {
            Rectangle rectangle = new Rectangle();
            return rectangle.Length * rectangle.Width;
        }
        else if (Type == "Circle")
        {
            Circle circle = new Circle();
            return Math.PI * Math.Pow(circle.Radius, 2);
        }
        // More shapes and calculations can be added here, but violates OCP
        else
        {
            throw new InvalidOperationException("Unsupported shape type");
        }
    }
}

public class Rectangle
{
    public double Length { get; set; }
    public double Width { get; set; }
}

public class Circle
{
    public double Radius { get; set; }
}

In this example, the Shape class contains a method to calculate the area based on different shapes such as rectangles and circles. However, if a new shape is introduced, such as a triangle, the Area() method in the Shape class would need to be modified to accommodate the new shape. This violates the OCP because the class is not closed for modification; instead, it requires modification whenever a new shape is added.

3 - Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. In other words, derived classes should be substitutable for their base classes without altering the desirable properties of the program.

4 - Interface Segregation Principle (ISP): A client should not be forced to depend on interfaces it does not use. Instead of one large interface, it is better to have smaller, specific interfaces.

5 - Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This principle promotes loose coupling between software modules.