Forem: Danilo Silva

Como integrar ASP.NET + ChatGPT

Danilo Silva — Wed, 03 Jul 2024 17:51:18 +0000

Olá. Neste artigo, vamos ver como podemos conectar uma API em Asp.NET Core com a API do ChatGPT.

Introdução
Cenário da Aplicação
Obtendo uma chave de API
Funcionamento da API do ChatGPT
- Criando DTOs
- Criando o serviço
- Criando a controller
- Testando a aplicação
Conclusão

Introdução

Todos os modelos de IA generativas que estão operando de maneira madura, ou seja, possuem algum site ou interface para que as pessoas possam fazer uso de seus modelos, costumar ter algum tipo de driver, SDK ou framework para conexão com diversas linguagens. O C# não foge disso, mas, fazer uso da API desses modelos pode ser ainda mais simples.

Vamos ver como fazer isso, mas não apenas fazer uma conexão simples, e sim com um exemplo prático de interação com a base de dados.

Cenário da Aplicação

Para ilustrar um uso dessa API, vamos criar um cenário de um e-commerce de uma grande loja de variedades. Imagine um site onde você possa pedir sugestões de presentes para um determinado público. Uma conexão direta com o ChatGPT facilmente poderia fazer isso, mas, você não deseja que a resposta encaminhe seu usuário para outro site ou sugira um produto que você não venda. Não seria intuitivo.

Talvez, clonar e trabalhar no seu próprio modelo de IA iria resolver isso, mas vamos buscar uma abordagem mais simples.

Vamos trabalhar com uma API simples com arquitetura em camadas, trabalhando apenas com uma única tabela chamada Categories, para armazenar as categorias de produtos que temos no site. Iremos utilizar o mongodb, por ser mais leve para você clonar o projeto e rodar.

Projeto inicial

Você pode clonar essa versão inicial e subir um container com o comando:

docker compose up -d --build

E então rodar o projeto com o comando:

dotnet run

Você poderá então acessar o endereço na rota GET /categories e conferir as informações do banco. Este projeto possui um arquivo mongo-init.js para carregar o mongodb com algumas categorias de produtos.

Portanto, vamos utilizar essas categorias para personalizar a resposta que o ChatGPT pode nos entregar.

Obtendo uma chave de API

Quanto à conexão com ChatGPT, entenda que o mesmo é pago e solicita uma chave de API. Você pode carregar um saldo mínimo para fazer uso ou verificar se a sua conta possui um saldo de demonstração. Para isso:

1 - Acesse o endereço da Plataforma da OpenAI e clique em Log in ou Sign up

2 - Faça login com a sua forma desejada

3 - Clique no canto superior direito, então em Your Profile. Após isso, você verá uma página similar à imagem. Então clique na aba User API Keys.

4 - Atualmente, o ChatGPT está retirando as chaves de APIs associadas a usuários e solicitando a criação de chaves associadas a projetos. Portanto, clique em View project API keys.

5 - Nesta tela, clique no canto superior direito em Create new secret key. Uma janela modal irá aparecer, onde você pode dar um nome para sua chave e então clicar em Create secret key.

6 - A janela será atualizada agora mostrando a sua chave de API. Clique no botão Copy e cole a sua chave em algum editor.

⚠️ Essa é a única vez onde você terá acesso à chave pelo site da OpenAI. Portanto, é extremamente importante salvar em um local seguro.

Funcionamento da API do ChatGPT

Para fazer com que nosso projeto faça chamadas na API do ChatGPT, devemos verificar o seu funcionamento na documentação oficial, mas podemos simplificar a explicação.

Para o uso de modelos de texto, a chamada mais básica deverá ser:

/POST https://api.openai.com/v1/chat/completions

{
    "model": "gpt-4",
    "messages": []
}

Onde model indica o modelo de gpt a ser utilizado e messages é um array de mensagens a serem enviadas. As mensagens seguem o seguinte objeto:

{
   "role": "user",
   "content": "Olá ia. Como vai?"
}

Dentre essas mensagens, o atributo role indica o papel da pessoa autora daquela mensagem, tal como se fosse uma conversa. Dentre deste atributo, iremos preenchê-lo com 03 tipos:

user: essa role representa a pessoa que está perguntando ao chatgpt. Logo, quando utilizamos o mesmo, estamos assumindo o papel de user.
assistant: essa role representa as mensagens do ChatGPT, ou seja, as suas criações.
system: essa role representa a pessoa desenvolvedora que irá dar instruções para o modelo e alterar o tom da conversa.

Portanto, se fizermos, por exemplo, uma requisição com o seguinte corpo:

{
  "model": "gpt-4",
  "messages": [
         {
        "role": "system",
        "content": "Crie respostas curtas"
      },
            {
        "role": "user",
        "content": "Olá ia. Como vai?"
      }
  ]
}

Obteremos uma resposta no seguinte formato:

{
    "id": "chatcmpl-9g...",
    "object": "chat.completion",
    "created": 1719955224,
    "model": "gpt-4-0613",
    "choices": [
        {
            "index": 0,
            "message": {
                "role": "assistant",
                "content": "Olá! Estou funcionando perfeitamente. Como posso ajudar você hoje?"
            },
            "logprobs": null,
            "finish_reason": "stop"
        }
    ],
    "usage": {
        "prompt_tokens": 25,
        "completion_tokens": 19,
        "total_tokens": 44
    },
    "system_fingerprint": null
}

Se analisarmos o objeto de retorno, temos um json com uma chave chamada choices que receberá um array de mensagens. Esse array, para as chamadas simples que iremos fazer, irão retornar um objeto apenas. Esse objeto terá uma chave message com a role: assistant e um content com a nossa mensagem. Entender o formato desse json é essencial para o código.

Criando DTOs

Iremos criar DTOs para representar a request e a response na API do ChatGPT.

namespace dotnet_gpt.DTO;

public class RequestGPT
{
    public string? model { get; set; }
    public List<RequestGPTMessage>? messages { get; set; }
}

public class RequestGPTMessage
{
    public string? role { get; set; }
    public string? content { get; set; }
}

A classe RequestGPT terá os atributos de model e messages para o primeiro nível do json. Já o atributo messages será uma coleção de um segundo DTO chamado RequestGPTMessage que terá o formato do objeto de cada mensagem.

Além disso, iremos criar DTOs para representar o futuro funcionamento da nossa API. No corpo de requisição, teremos um json com um único atributo chamado message enquanto a resposta será a mesma message do ChatGPT mais a categoria de produto do nosso banco de dados recomendada.

public record AdviceRequest
{
    public string? message { get; set; }
}

public record AdviceReponse : AdviceRequest
{
    public Category? Category { get; set; }
}

Criando o serviço

Iremos agora criar um serviço capaz de realizar chamadas HTTP. Mas para podermos trabalhar com os objetos json com mais facilidade e realizar a requisição, iremos instalar algumas dependências com os comandos:

dotnet add package Newtonsoft.Json
dotnet add package System.Net.Http

Ou qualquer outra forma de instalar dependências pelo Nuget.

Nosso próximo passo será criar uma classe chamada IAService que irá receber a camada repository e o objeto HttpClient (responsável pela chamada na API do ChatGPT)

public class IAService
{
    protected readonly HttpClient _client;
    private readonly ICategoryRepository _categoryRepository;

    public IAService(ICategoryRepository categoryRepository, HttpClient client)
    {
        _categoryRepository = categoryRepository;
        _client = client;
    }
}

Além disso, iremos criar uma variável para armazenar o token.

 private string token = "seu-token-jwt";

Para facilitar, estamos colocando o token em uma string hard-coded mas em sua aplicação, você pode decidir entre variáveis de ambiente ou configurações do appsettings.json.

Iremos criar um método assíncrono para receber a request do corpo de requisição e retornar o corpo de response.

public async Task<AdviceReponse> GetAdvice(AdviceRequest request)
{
}

Neste método, iremos começar buscando os nomes das categorias da camada repository e concatenar em uma mesma string. Usaremos essa string para informar ao ChatGPT, quais são as categorias de produtos existentes em nossa loja.

public async Task<AdviceReponse> GetAdvice(AdviceRequest request)
{
    List<Category> categories = _categoryRepository.GetCategories();
    string categoriesNames = "";
    foreach(var category in categories)
    {
        categoriesNames += category.Name + ", ";
    }
}

Então podemos criar um objeto com o corpo de requisição para a API da OpenAI.

RequestGPT requestGPT = new RequestGPT {
    model =  "gpt-4",
    messages = new List<RequestGPTMessage>()
};

Neste objeto, adicionaremos 03 mensagens. A primeira mensagem será do tipo system e irá indicar o comportamento das respostas a serem geradas.

requestGPT.messages.Add(new RequestGPTMessage {
    role = "system",
    content = "Se comporte como um assistente para sugerir produtos de um e-commerce."
});

A segunda mensagem também será do tipo system e irá indicar quais são as categorias que o ChatGPT irá considerar ao recomendar um presente.

requestGPT.messages.Add(new RequestGPTMessage {
    role = "system",
    content = "Nesse e-commerce, as categorias de produtos são "+ categoriesNames+"sugira uma dessas categorias baseando-se na solicitação. Não sugira produtos, apenas a categoria com um texto breve de 20 palavras"
});

Note que nesta mensagem, estamos concatenando um texto informativo com as categorias existentes no mongodb.

Por último, iremos indicar a mensagem que a pessoa usuária irá digitar ao pedir uma recomendação de presente.

requestGPT.messages.Add(new RequestGPTMessage {
    role = "user",
    content = request.message
});

Podemos então converter esse objeto para json com a biblioteca Newtonsoft.Json e fazer uma request com o objeto HttpClient passando esse corpo de requisição e o token da API.

var requestBody = JsonConvert.SerializeObject(requestGPT);
var httpRequest = new HttpRequestMessage(HttpMethod.Post, $"https://api.openai.com/v1/chat/completions")
{
    Content = new StringContent(requestBody, Encoding.UTF8, "application/json")
};

httpRequest.Headers.Add("Accept", "application/json");
httpRequest.Headers.Add("User-Agent", "seu-agent");
_client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", token);

var response = await _client.SendAsync(httpRequest);
if(!response.IsSuccessStatusCode) return default!;

Com a response, podemos então converter a resposta da requisição para um DTO que consiga interpretar os dados e obter o texto da primeira resposta do ChatGPT

var result = await response.Content.ReadFromJsonAsync<ResponseGPT>();
var resultText = result!.choices!.First().message!.content!.ToString();

Neste ponto, teremos na variável resultText, a mensagem do GPT4. Como o mesmo indica o texto da categoria escolhida, podemos buscar o objeto do banco de dados referente a essa escolha e montar o objeto de retorno.

Category? choiceCategory = null;
foreach(var category in categories)
{
    if (resultText.IndexOf(category.Name) > -1)
    {
        choiceCategory = category;
    }
}


AdviceReponse adviceReponse = new AdviceReponse { message = resultText, Category = choiceCategory };

return adviceReponse;

Ao final dessa construção, teremos a seguinte camada service

public class IAService
{
    protected readonly HttpClient _client;
    private readonly ICategoryRepository _categoryRepository;
    private string token = "sk-proj-6TXNCUChRKjLdPupBYSET3BlbkFJIrrztu24plcHou3YduWv";
    public IAService(ICategoryRepository categoryRepository, HttpClient client)
    {
        _categoryRepository = categoryRepository;
        _client = client;
    }

    public async Task<AdviceReponse> GetAdvice(AdviceRequest request)
    {
        List<Category> categories = _categoryRepository.GetCategories();
        string categoriesNames = "";
        foreach(var category in categories)
        {
            categoriesNames += category.Name + ", ";
        }

        RequestGPT requestGPT = new RequestGPT {
            model =  "gpt-4",
            messages = new List<RequestGPTMessage>()
        };

        requestGPT.messages.Add(new RequestGPTMessage {
            role = "system",
            content = "Se comporte como um assistente para sugerir produtos de um e-commerce."
        });

        requestGPT.messages.Add(new RequestGPTMessage {
            role = "system",
            content = "Nesse e-commerce, as categorias de produtos são "+ categoriesNames+"sugira uma dessas categorias baseando-se na solicitação. Não sugira produtos, apenas a categoria com um texto breve de 20 palavras"
        });

        requestGPT.messages.Add(new RequestGPTMessage {
            role = "user",
            content = request.message
        });

        var requestBody = JsonConvert.SerializeObject(requestGPT);
        var httpRequest = new HttpRequestMessage(HttpMethod.Post, $"https://api.openai.com/v1/chat/completions")
        {
            Content = new StringContent(requestBody, Encoding.UTF8, "application/json")
        };
        httpRequest.Headers.Add("Accept", "application/json");
        httpRequest.Headers.Add("User-Agent", "seu-agent");
        _client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", token);

        var response = await _client.SendAsync(httpRequest);

        if(!response.IsSuccessStatusCode) return default!;

        var result = await response.Content.ReadFromJsonAsync<ResponseGPT>();
        var resultText = result!.choices!.First().message!.content!.ToString();

        Category? choiceCategory = null;
        foreach(var category in categories)
        {
            if (resultText.IndexOf(category.Name) > -1)
            {
                choiceCategory = category;
            }
        }


        AdviceReponse adviceReponse = new AdviceReponse { message = resultText, Category = choiceCategory };
        return adviceReponse;
    }
}

Criando a controller

Por fim, para criarmos a controller, precisamos receber em sua injeção de dependências, o IAService criado anteriormente, e criar um método que receba do corpo de requisição, o objeto AdviceRequest que iremos enviar em nosso serviço.

[ApiController]
[Route("[controller]")]
public class AdviceController : ControllerBase
{
    private readonly IAService _iaService;
    public AdviceController(IAService iaService)
    {
        _iaService = iaService;
    }

    [HttpPost]
    public async Task<IActionResult> Post([FromBody] AdviceRequest adviceRequest)
    {
        return Ok(await _iaService.GetAdvice(adviceRequest));
    }
}

Após essa etapa, devemos garantir as injeções de dependências com:

builder.Services.AddScoped<IContextConnection, ContextConnection>();
builder.Services.AddScoped<ICategoryRepository, CategoryRepository>();
builder.Services.AddHttpClient<IAService>();

Testando a aplicação

Para testar a aplicação, podemos chamar a rota POST /advice com um corpo de requisição com uma solicitação.

Podemos ver que, enviamos a solicitação ao ChatGPT e graças à mensagem do tipo system, recebemos um texto indicando qual a categoria de produto que o mesmo melhor se enquadra.

Analisando o texto da resposta do ChatGPT, podemos coletar o registro da categoria no banco de dados e retornar para o front-end.

Conclusão

Você aprendeu como podemos utilizar o HttpClient do C# para fazer uma requisição na API do ChatGPT.

Basicamente, se nossa aplicação tivesse nesse momento, uma lista de produtos, poderíamos responder com os produtos mais vendidos nessa categoria. Portanto, criamos uma forma de fazer bom uso da inteligência artificial sem precisar treinar um modelo do zero.

Para facilitar a construção, deixo aqui o repositório completo.

Danilo Silva

Desenvolvedor de software experiente em boas práticas, clean code e no desenvolvimento de software embarcado e de integração com hardwares de controle e telecomunicação.

Linkedin
Github
Twitter
E-mail

SQL Server + Docker Compose: como criar e popular bancos de dados ao inicializar os containers

Danilo Silva — Mon, 24 Jun 2024 13:47:55 +0000

Fazer uso de containers é uma excelente abordagem para automatizar o funcionamento e a distribuição de projetos. Entretanto, se você está criando uma aplicação ASP.NET Core com Entity Framework Core, você provavelmente utilizou migrations para construir o banco de dados.

Agora, como poderíamos automatizar a inicialização dessa aplicação? Através de do Startup do SQL Server.

O SQL Server possui uma série de aplicativos funcionais em seu core. Um deles se chama sqlcmd. Esse executável permite com que você possa realizar comandos instantâneos no SQL Server sem necessariamente conectar a sua aplicação ou um gerenciador de banco de dados e está disponível para uso na imagem Docker do SQL Server.

⚠️ Atenção: Se você está utilizando um computador com processador ARM, provavelmente você não utilizou a imagem do SQL Server mas sim a imagem do Azure SQL Edge. Lembre-se que a imagem do Azure SQL não possui o executável sqlcmd e por isso, não funcionará.

Para mostrar a automatização do processo, utilizei uma API simples utilizando .NET 6 e EF Core chamada ToDo.API.

1º Passo

Iremos criar um arquivo docker-compose.yml com a imagem do SQL Server e garantir que exista um volume nela. Este volume foi feito com o bind /data -> /initdb e servirá para colocarmos um script SQL capaz de construir o banco de dados.

version: '3'
services:
  db:
    image: mcr.microsoft.com/mssql/server:2019-latest
    volumes:
      - ./data:/initdb
    container_name: todo-database
    ports:
        - 1433:1433
    environment:
      - ACCEPT_EULA=Y
      - MSSQL_SA_PASSWORD=TodoApiSqlPass123!
      - MSSQL_PID=Developer

2º Passo

Agora, iremos criar as migrations para a nossa aplicação. Será muito importante garantir que exista apenas uma única migrations capaz de construir o banco de dados inteiro. Podemos fazer isso com o seguinte comando dentro do diretório da API:

dotnet ef migrations add initialcreate

3º Passo

O próximo passo será criar um script com o código dessa migration. Como ela é a única, não precisamos nos preocupar em indicar qual migration criar o script. Iremos salvar esse script dentro do diretório /data, para onde apontamos o volume:

 dotnet ef migrations script -o ../data/initial.sql

4º Passo

Agora iremos editar o arquivo /data/initial.sql para indicar o banco que estamos trabalhando. Nesta API, configurei a API para se conectar a um banco de dados chamado Todo. Portanto, no início do arquivo initial.sql, iremos colocar as seguintes instruções:

CREATE DATABASE Todo;
GO

USE Todo;
GO

No final desse arquivo, você pode criar instruções de INSERT para popular o seu banco de dados como um seeder.

5º Passo

Podemos então criar um Dockerfile para criar uma imagem da API. Dentro do diretório da API, criaremos o seguinte:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
WORKDIR /app

COPY . ./
RUN dotnet restore
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build-env /app/out .

ENTRYPOINT ["dotnet", "ToDo.Api.dll"]

Esse é o modelo de Dockerfile mais simples para aplicações ASP.NET e você pode construir o mesmo da maneira desejada.

6º Passo

Agora podemos finalmente adicionar o serviço da API dentro do docker-compose.yml como um serviço dependente do banco de dados:

api:
    container_name: todo-api
    build: ./ToDo.Api
    ports:
      - 5501:5501
    depends_on:
      - db

7º Passo

Nosso último passo e mais importante. Popular o banco de dados. Para isso, iremos criar um shell script. Mas vamos entender como funciona o processo.

Dentro do container do banco de dados, temos o executável sqlcmd como mencionado anteriormente, localizado em /opt/mssql-tools/bin/sqlcmd.

Este executável pode ser chamado com os seguintes parâmetros:

sqlcmd -S server -U usuario -P senha -d banco -i script.sql

Onde:
-S: corresponde ao servidor de conexão com o SQL Server;
-U: corresponde ao usuário;
-P: corresponde à senha;
-d: corresponde ao banco onde será feita a conexão;
-i: corresponde ao script SQL que será executado.

Para a nossa aplicação, podemos chamar então o sqlcmd com um docker exec da seguinte maneira:

 docker exec todo-database /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P TodoApiSqlPass123! -d master -i initdb/initial.sql

Nesse comando, executamos dentro do container todo-database, nomeado no arquivo docker-compose.yml passando o server, usuário e senha também configurados no mesmo. Para o banco de dados, selecionamos master, pois é o banco de maior acesso em um server novo, e ainda não possuímos o nosso banco.

Quanto ao script, passamos o diretório /initdb que criamos no volume do container junto do arquivo initial.sql criado pela migration.

8º Passo

Entretanto, para deixar algo mais automatizado, iremos criar um script shell para executar tal comando. Portanto, iremos criar um arquivo chamado init.sh na raiz do repositório com o seguinte conteúdo:

#!/bin/bash
while :
do 
  PORTS=`lsof -i:1433`
  echo $PORTS
  if ["$PORTS" = '']; then
    echo 'Database is down, trying to reconnect to run initial migrations!'
    sleep 5s
  else
    docker exec todo-database /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P TodoApiSqlPass123! -d master -i initdb/initial.sql; echo "All done!";
    break
  fi
done

echo "Successfuly executed!"

⚠️ Atenção: Este script está preparado para computadores Linux ou Mac mas você pode adaptar para Windows com o Powershell.

Como funciona esse script?

Primeiramente, como o container de um banco de dados SQL Server pode ser demorado a subir, temos que garantir algo para validar se o mesmo está operacional. Esse container está expondo a porta 1433 e com ela, iremos verificar se o banco está operacional.

O script roda o comando lsof -i:1433 para verificar os processo executando nessa porta. Se não encontrar nenhum processo usando a porta, o mesmo irá imprimir a mensagem Database is down, trying to reconnect to run initial migrations! e irá esperar por 05 segundos para tentar novamente.

Caso o mesmo encontre o container do banco de dados, irá executar o sqlcmd e ao fim do processo, imprimir as mensagens All done! e Successfuly executed!.

Para facilitar a visualização, você pode clonar o repositório completo.

Danilo Silva

Desenvolvedor de software experiente em boas práticas, clean code e no desenvolvimento de software embarcado e de integração com hardwares de controle e telecomunicação.

Linkedin
Github
Twitter
E-mail

ASP.NET Core - Load Balancing com Nginx e Docker

Danilo Silva — Tue, 30 Jan 2024 14:25:38 +0000

O load balancing, ou balanceamento de carga é a prática que permite que o tráfego de uma aplicação seja distribuído entre diferentes servidores ou recursos computacionais para evitar sobrecargas e garantir um desempenho eficiente.

Imagine um site popular que recebe muitas visitas em uma determinada funcionalidade. Tanto backend como frontend dessa funcionalidade poderiam se tornar muito demorados.

Em vez de deixar um único servidor lidar com todas as solicitações, o load balancing distribui essas solicitações entre vários servidores. Isso ajuda a evitar que um servidor fique sobrecarregado, garantindo que a aplicação continue funcionando de maneira rápida e eficiente, mesmo durante períodos de alto tráfego.

Aqui, veremos como utilizar o Nginx para balancear a carga de uma API com 03 instâncias iniciadas. Cada instância irá rodar em um servidor, no nosso caso, um container docker, e as solicitações para essa API serão divididas entre as diferentes instâncias.

API

Portanto, para verificar se as mesmas chamadas estão sendo realizadas em diversas máquinas, vamos criar uma controller de exemplo que mostre essa determinada funcionalidade.

using Microsoft.AspNetCore.Mvc;

namespace FirstAPI.Controllers;

[ApiController]
[Route("[controller]")]
public class StatusController : ControllerBase
{
    private readonly ILogger<StatusController> _logger;

    public StatusController(ILogger<StatusController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public IActionResult Get()
    {
        _logger.LogInformation("Request on Status Controller");
        var MachineName = System.Environment.MachineName;
        return Ok(new { Status = "online", MachineName });
    }
}

Criamos aqui uma API chamada FirstAPI no ASP.NET Core. A rota GET /status mostrará uma mensagem fixa de online junto do nome da máquina na qual a aplicação está rodando. Obtemos essa informação através da propriedade de ambiente System.Environment.MachineName.

Para que a nossa API também seja executada em uma porta parametrizada pela variável de ambiente, devemos forçar essa URL no arquivo Program.cs ou Startup.cs com a seguinte instrução:

var port = builder.Configuration["PORT"];
builder.WebHost.UseUrls($"http://*:{port}");

var app = builder.Build();

Isso garantirá que a aplicação suba pela variável de ambiente PORT.

Dockerfile

Para que essa API possa ser executada em um container, devemos construir um dockerfile para a mesma. Sabendo que o nome da aplicação é FirstAPI e que estamos utilizando o .NET Framework 7.0, o dockerfile se dará da seguinte forma:

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS publish-environment
WORKDIR /app

COPY . ./
RUN dotnet restore
RUN dotnet publish -c Release -o published

FROM mcr.microsoft.com/dotnet/aspnet:7.0
WORKDIR /app
COPY --from=publish-environment /app/published .
ENTRYPOINT ["dotnet", "FirstAPI.dll"]

Nginx

O Nginx é um servidor web de código aberto, utilizado para servir conteúdo na internet, sendo um dos servidores web mais leve dentre os existentes. Além de suas capacidades como servidor web, o Nginx também pode agir como proxy reverso, balanceador de carga e servidor de cache.

Utilizaremos o Nginx como balanceador de carga através do simples arquivo de configuração abaixo:

upstream api {
    server first-api:3000;    
}

server {
    listen 80;

    include /etc/nginx/mime.types;

    location / {
        proxy_pass http://api/;
    }
}

Nessa configuração, primeramente criamos um upstream chamado api. Aqui temos como server, o endereço chamado first-api:3000. Nosso intuito será criar o container da api utilizando um docker compose de forma que o nome do serviço, e consequentemente, o endereço criado no DNS da rede criada pelo docker compose seja first-api.

Caso aqui você tivesse outros servers com diferentes nomes e portas, mas que fizessem parte da mesma funcionalidade, você poderia apenas adicionar linhas nesse bloco. Por exemplo:

upstream api {
    server first-api:3000;    
    server second-api:3001; 
}

Nesse bloco, o endereço second-api:3001 também seria uma das opções no load balancing.

Depois, temos o bloco server que definirá o servidor. Esse servidor será criado na porta 80 e o redirecionamento será para um proxy apontado para o upstream api, portanto para o endereço http://api/.

Docker compose

Agora podemos criar um docker compose com dois serviços. O primeiro serviço será a nossa API com o nome first-api.

version: '3'
services:
  first-api:
    build: ./APIs/FirstAPI
    environment:
      - PORT=3000
    deploy:
      replicas: 3
    networks:
      - load-balancing

networks:
  load-balancing:

Nesse serviço, injetamos a variável de ambiente PORT com o valor 3000. Criamos uma rede interna chamada load-balancing para o nome do DNS funcionar dentro do docker. Também criamos a chamada de replicas igual a 3 para subir 03 containers com a mesma imagem de nossa API.

Para o serviço do Nginx, seguiremos com a seguinte configuração no mesmo docker compose:

  nginx:
    image: nginx:latest
    container_name: reverse_proxy
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    ports:
      - "3000:80"
    networks:
      - load-balancing
    depends_on:
      - first-api

Nesse serviço, temos 04 configurações importantes. Primeiramente, o volume que fará com que o arquivo nginx.conf que criamos a pouco seja o arquivo de configuração default dentro do container do nginx.

Fazemos um bind de portas para que a porta 80 do nginx seja refletida como a porta 3000, originalmente a porta do serviço que devemos replicar.

Devemos também manter a mesma rede load-balancing e dizer que esse serviço depende do serviço first-api.

Com esse docker-compose.yml, podemos subir o mesmo pelo comando:

docker compose up -d --build

E esperamos o seguinte resultado:

Uso da API

A partir desse container, o load balancing do Nginx irá distribuir as solicitações dentre as 03 instâncias da WebAPI.

Para facilitar os testes, você pode clonar o Repositório completo.

Danilo Silva

Desenvolvedor de software experiente em boas práticas, clean code e no desenvolvimento de software embarcado e de integração com hardwares de controle e telecomunicação.

Linkedin
Github
Twitter
E-mail

Design Patterns: Factory - Getting Started with Typescript

Danilo Silva — Wed, 15 Mar 2023 21:27:19 +0000

What is a Design Pattern?

Hi devs. We will start talking about design patterns for software development. In day life as a programmer, we face several refactoring issues, clean code reusability and performance problems to make sure our sofware is scalable.

All these problems were shared by dev community for a long time and the result of all discussions was the creation of several paradigms to build a code.

It was created, for example, the object-oriented programming, the four pillars of OOP, the SOLID principles and the design patterns.

Design patterns are patterns of software development with the aim to make code scalable and improve software quality. The standards guarantee ways to solve problems of clarity and code maintainability.

Remember, the patterns are not code blocks to add to your project. They are ways to coding and because of that, the patterns are usable to several languages. We're going to code with typescript, but you can choose the language you like the most.

Factory

The factory, or factory method, is one of the creational patterns (Factory, Abstract Factory, Builder, Prototype and Singleton), so, it's a pattern relative to object instances. It proposes the coding of a method to instance classes objects.

Using factory method, your code will no longer instance class objects with new. Your code is going to call the factory method and this one will return an instantiated object called product.

What's the advantage of using the Factory method?

First of all, you uncouple instances from your code. So the business rule needed by a product is not explained to the rest of your code.

Second, if you use the factory method, you can add features to all processes involving the instance of objects. Without factory, you need to add a change to all 'new' method called.

You can think about adding the feature in constructor but, in this way, you can code against three SOLID principles at once (S, O and D). Let's check examples:

You are coding a car shop management system and in your code you have the entity Car. This class is fully of business rules about car, including taxes calculation and car registration documents.

So we have to develop a new feature: 'When a new car is instantiated, we must log this event'. You must create a Log class responsible for logging these data in a file or database.

If we instantiate an Log object at Car class constructor, we are coding against the single-responsibility principle because the Car class must be responsible only by cars.

We don't use the Open-closed principle because a class should be open for extension and close for modification. In this case, we are changing the constructor.

And we don't use the dependency inversion principle because the Car class can't be used due to the high coupling to Log class. If you want to use the Car class in other system, you should to code the Log class.

The third advantage is that you can return a previously created object instead of instantiating a new one. In this case, we use another creational pattern called Singleton.

Let's Code

We are developing an Airline software and the first class is Airplane. For a while, we won't code complex methods and numerous attributes. We'll have only prefix, manufacturer and aircraft attributes.

We will have the getters methods and all attributes will be assigned in constructor. Our Airplane class implements the IAirplane interface.

interface IAirplane {
    prefix: string;
    manufacturer: string;
    aircraft: string;
}

class Airplane implements IAirplane {
    constructor(private _prefix: string,
        private _manufacturer: string,
        private _aircraft: string) {}

    get prefix(): string {
        return this._prefix
    }

    get manufacturer(): string {
        return this._manufacturer;
    }

    get aircraft(): string {
        return this._aircraft;
    }

}

For now on, every time we use an object Airplane we would call the new method:

const embraerE195 = new Airplane('PR-ABC','Embraer','E195');

However, we're going to use the factory pattern. The implementation is the creation of a new class called AirplaneFactory. This class must have the factory method called create which it will instantiate a new Airplane product. So, in our code, the factory class is going to be the only one that we can to instantiate with the new method.

Some samples suggest that factory method and factory class are statics. This is a wrong way to code the factory that prevents it to be extended. We will check about creating abstract and concrete products.

In factory class and factory method, we code:

class AirplaneFactory {
    public create (prefix: string, manufacturer: string, aircraft: string): Airplane {
        return new Airplane(prefix, manufacturer, aircraft);
    } 
};

and to create a new Airplane:

const airplaneFactory = new AirplaneFactory();

const embraerE195 = airplaneFactory.create('PR-ABC','Embraer','E195');

Note that the factory method must always have a product of the same type as the business rule class, even if it is an abstract product.

Abstracts and concrete factories

We will increase the complexity. In our business rule, from now on, the airplane is an abstract entity to create passenger airplanes and cargo airplanes.

In the diagram, we have the classes PassengerAirplane and CargoAirplane extending the abstract class Airplane and the interfaces IPassengerAirplane and ICargoAirplane.

Now we have the abstract class for Airplane

abstract class Airplane implements IAirplane {
    constructor(private _prefix: string,
        private _manufacturer: string,
        private _aircraft: string) {}

    get prefix(): string {
        return this._prefix
    }

    get manufacturer(): string {
        return this._manufacturer;
    }

    get aircraft(): string {
        return this._aircraft;
    }
}

and the concrete classes

interface IPassengerAirplane extends IAirplane {
    passengerCapacity: number;
    buyTicket(): void;
}


class PassengerAirplane extends Airplane implements IPassengerAirplane {

    constructor(prefix: string, manufacturer: string, aircraft: string, private _passengerCapacity: number) {
        super(prefix, manufacturer, aircraft);
    }

    get prefix(): string {
        return super.prefix
    }

    get manufacturer(): string {
        return super.manufacturer;
    }

    get aircraft(): string {
        return super.aircraft;
    }

    get passengerCapacity(): number {
        return this._passengerCapacity;
    }

    public buyTicket(): void {
        console.log(`New ticket emitted to ${this.manufacturer} ${this.aircraft} - Prefix: ${this.prefix}`);
    }
}

interface ICargoAirplane extends IAirplane {
    payload: number;
    loadCargo(weight: number)
}

class CargoAirplane extends Airplane implements ICargoAirplane {
    constructor(prefix: string, manufacturer: string, aircraft: string, private _payload: number) {
        super(prefix, manufacturer, aircraft);
    }

    get prefix(): string {
        return super.prefix
    }

    get manufacturer(): string {
        return super.manufacturer;
    }

    get aircraft(): string {
        return super.aircraft;
    }

    get payload(): number {
        return this._payload;
    }

    public loadCargo(weight: number){
        console.log(`${weight} loaded to ${this.manufacturer} ${this.aircraft} - Prefix: ${this.prefix}`);
    }
}

Now we should fix the factory method. At this moment, we have a factory method to create an Airplane product. We must keep the concrete products as a Airplane product but extending to a PassengerAirplane or CargoAirplane. Because of this, we must have two concrete factories extending from an abstract factory.

The factory method must be an abstract method in the abstract class. The concrete methods must be implemented according to yours definitions.

The concrete factories implement the create method. Even the two possible products are different, both of them implements the IAirplane interface. This is a sample to not create a static factory method.

Let's code

abstract class AirplaneFactory {
    public abstract create (prefix: string, 
       manufacturer: string, 
       aircraft: string, 
       payload: number, 
       passengerCapacity: number): Airplane
};

class PassengerAirplaneFactory extends AirplaneFactory {
    public create (prefix: string, 
       manufacturer: string, 
       aircraft: string, 
       passengerCapacity: number): PassengerAirplane {
        return new PassengerAirplane(prefix,
           manufacturer,
           aircraft,
           passengerCapacity);
    } 
};

class CargoAirplaneFactory extends AirplaneFactory {
    public create (prefix: string,
       manufacturer: string, 
       aircraft: string, 
       payload: number): CargoAirplane {
        return new CargoAirplane(prefix,
           manufacturer,
           aircraft,
           payload);
    }
};

const passengerAirplaneFactory = new 
    PassengerAirplaneFactory();

const cargoAirplaneFactory = new 
    CargoAirplaneFactory();

const E195 = passengerAirplaneFactory
    .create('PR-ABC', 
        'Embraer', 
        'E195', 
         118);

const KC390 = cargoAirplaneFactory
    .create('PR-DEF', 
        'Boeing', 
        'B747', 
         137);

E195.buyTicket();
KC390.loadCargo(100);

We create two objects, one called E195 created with the concrete factory PassengerAirplaneFactory and another one called KC390 created with the concrete factory CargoAirplaneFactory. We called the methods buyTicket and loadCargo in spite of both of them are an Airplane product.

If you think that we can code a concrete factory capable to create both products, the answer is yes.

In this case, we have another pattern, the Abstract Factory that is responsible to create families of products. But remember, an abstract factory class is not an abstract factory.

Tests

We can test our factory method to check if the created products are instances of domain classes. We will use Jest but you can use the testing library of your choice.

First of all, I will test the PassengerAirplaneFactory

let passengerAirplaneFactory;
    beforeEach(() => {
        passengerAirplaneFactory = new 
             PassengerAirplaneFactory();
    });

Then, I will test:

If the PassengerAirplaneFactory is an instance of it.
If the PassengerAirplaneFactory is an instance of AirplaneFactory.
If the PassengerAirplaneFactory returns an Airplane product and a PassengerAirplane product.
And if the PassengerAirplaneFactory doesn't return a CargoAirplaneFactory product.


describe('Passenger airplane factory', () => {

    let passengerAirplaneFactory;
    beforeEach(() => {
        passengerAirplaneFactory = new 
            PassengerAirplaneFactory();
    });

    it('is a instance of Airplane factory', () => {             
        expect(passengerAirplaneFactory)
            .toBeInstanceOf(AirplaneFactory);
    });

    it('is a instance of Passenger airplane factory', () => {
        expect(passengerAirplaneFactory)
            .toBeInstanceOf(PassengerAirplaneFactory);
    });
    it('creates a airplane and passenger 
    airplane product', () => {
        const E195 = passengerAirplaneFactory
            .create('PR-ABC', 
                'Embraer', 
                'E195', 
                 118); 
        expect(E195).toBeInstanceOf(Airplane);
        expect(E195).toBeInstanceOf(PassengerAirplane);
    });
    it('does not create a cargo airplane product', () => {
        const E195 = passengerAirplaneFactory
            .create('PR-ABC', 
                'Embraer', 
                'E195', 
                118); 
        expect(E195).not.toBeInstanceOf(CargoAirplane);
    });
});

To test CargoAirplaneFactory, we have conditionals similar to PassengerAirplaneFactory.


describe('Cargo airplane factory', () => {

    let cargoAirplaneFactory;
    beforeEach(() => {
        cargoAirplaneFactory = new CargoAirplaneFactory();
    });

    it('is a instance of Airplane factory', () => {    
        expect(cargoAirplaneFactory)
                .toBeInstanceOf(AirplaneFactory);
    });

    it('is a instance of Cargo airplane factory', () => {            
        expect(cargoAirplaneFactory)
            .toBeInstanceOf(CargoAirplaneFactory);
    });

    it('creates a airplane and cargo airplane product', () => 
    {
        const B747 = cargoAirplaneFactory
            .create('PR-DEF', 'Boeing', 'B747', 137); 
        expect(B747).toBeInstanceOf(Airplane);
        expect(B747).toBeInstanceOf(CargoAirplane);
    });

    it('does not create a passenger airplane product', () => 
    {
        const B747 = cargoAirplaneFactory
              .create('PR-DEF', 'Boeing', 'B747', 137); 
        expect(B747).not.toBeInstanceOf(PassengerAirplane);
    });
});

Now we can check the results of our test.

Finally, this is the Factory pattern. I hope this was useful to help you.

Happy studying!

Danilo Silva

Software developer with experience at clean code, patterns and telecommunication hardware and software development.

Linkedin
Github
E-mail

Design Patterns: Factory - Primeiros passos com Typescript 🇧🇷

Danilo Silva — Fri, 10 Mar 2023 20:04:15 +0000

O que são Design Patterns?

Olá devs. Hoje iremos começar a falar sobre design patterns, ou no português claro, padrões de projeto para desenvolvimento de software. No dia-a-dia da pessoa desenvolvedora, enfrentamos diversos problemas de refatoração, necessidade de reaproveitar partes do nosso código, escrever um código limpo e legível ou aumentar a performance do código para que ele consiga ser escalável.

Todos esses problemas foram compartilhados pela comunidade por muito tempo e o resultado para solucioná-los proposto pela comunidade de grandes engenheiros de software foi uma série de paradigmas para arquitetar um código.

O resultado de trabalhos assim que geraram a orientação a objetos, os 04 pilares da orientação a objetos, os paradigmas do SOLID e o design patterns.

O design patterns, ou padrões de projeto, são um conjunto de padrões de desenvolvimento de software que visa resolver um problema e melhorar a qualidade do seu código. Eles miram a criação de uma arquitetura de software que garanta resolver da melhor maneira problemas de escalabilidade, manutenibilidade e clareza do seu software.

Lembre-se, por ser padrões, eles não são blocos de código para se colocar no seu projeto mas formas de melhor escrever e planejar a arquitetura do seu código. Portanto, não se limitam a uma linguagem apenas mas a varias. Iremos fazer a prática com Typescript mas você pode ficar a vontade para implementar na linguagem de sua escolha.

Padrão Factory

O padrão Factory é um dos padrões criacionais (Factory, Abstract Factory, Builder, Prototype e Singleton), ou seja, um padrão de projeto relacionado à criação de objetos que propõe o desenvolvimento de um método fábrica responsável pela instância dos objetos de uma classe.

Com a implementação do padrão factory, seu código não irá instanciar mais nenhum objeto de classe relacionadas a domínios ou regras de negócio. O seu código irá chamar esse método fábrica que irá instanciar o objeto e devolvê-lo para você, ou seja, objetos de classes não serão criados mais com um new. Esses objetos criados e devolvidos pelos métodos fábrica são chamados de produtos.

Mas qual a vantagem de aplicar o padrão factory?

Primeiramente, você desacopla a instância do objeto do resto do seu código. Isso quer dizer que a regra de negócio que precisa de um objeto (produto) não precisa saber das regras do mesmo.

A segunda vantagem é que você, ao criar um método fábrica, tem acesso a todos os novos objetos criados. Se você precisa adicionar uma funcionalidade toda vez que um objeto é instanciado, você precisa apenas modificar o seu método fábrica e em todos os lugares que necessitam de um produto novo terão a funcionalidade aplicada. Sem esse padrão, você teria que procurar no seu código toda vez que o new de uma classe é chamado.

Nesse momento, você pode pensar: mas era só adicionar a funcionalidade que eu quero no construtor da classe. O problema é que você pode ferir 03 paradigmas do SOLID de uma só vez (S, O e D). Vamos a um exemplo para ilustrar melhor:

Digamos que você tenha um software responsável por uma loja de automóveis e nele existe uma classe responsável pela entidade Car. Essa classe está cheia de regras de negócio relacionadas aos cálculos dos impostos e documentos de um carro.

Então temos a seguinte modificação: 'Toda vez que um carro novo for instanciado, devemos registrar em um log a adição deste carro'. Aqui temos que criar uma classe Log responsável por gravar esses registros, sejam eles em arquivo ou utilizando um banco de dados.

Se chamarmos uma instância da classe Log dentro do construtor da classe Car, estamos ferindo o princípio de responsabilidade única, já que a classe Car tem que ser responsável apenas pelos carros.

Deixamos de aplicar o princípio aberto/fechado também já que uma classe está aberta a adição de regras mas fechada para modificações, ainda mais uma modificação em um construtor.

Por último, não aplicamos o princípio de inversão de dependência, já que a classe Car não pode ser reutilizada devido ao alto acoplamento com a classe Log. Imagine que você deseja reaproveitar todas as regras de negócios dos carros em outro sistema. Além da classe Car, você teria de levar também a classe Log.

A terceira vantagem é que você pode não criar um objeto novo com o new no método fábrica. Dependendo da aplicação, podemos retornar um objeto previamente criado ao invés de criar um novo. Neste caso, usamos um outro padrão de projeto criacional chamado Singleton

Iniciando a Prática

Para nossa prática, vamos criar um software de uma empresa aérea e a nossa primeira classe é a classe Airplane. Por enquanto, não teremos métodos complexos nem muitos atributos. Apenas os atributos prefix, manufacturer e aircraft para guardar de modo privado o prefixo, fabricante e modelo de uma aeronave.

Nos métodos, teremos os getters apenas e todos os atributos serão atribuídos no construtor da classe Airplane. Nossa classe Airplane implementará uma interface com o nome IAirplane.

interface IAirplane {
    prefix: string;
    manufacturer: string;
    aircraft: string;
}

class Airplane implements IAirplane {
    constructor(private _prefix: string,
        private _manufacturer: string,
        private _aircraft: string) {}

    get prefix(): string {
        return this._prefix
    }

    get manufacturer(): string {
        return this._manufacturer;
    }

    get aircraft(): string {
        return this._aircraft;
    }

}

A partir desse momento, toda vez que precisássemos de uma instância da classe Airplane iríamos simplesmente chamar o método new com o código:

const embraerE195 = new Airplane('PR-ABC','Embraer','E195');

Entretanto iremos aplicar o padrão de projeto Factory. Sua implementação será através de uma nova classe chamada AirplaneFactory. Essa classe terá o método fábrica chamado create que irá gerar um novo produto do tipo Airplane. Portanto, no nosso código, a classe Factory será a única que poderemos instanciar com o método new.

Existem algumas vertentes que sugerem que tanto a classe Factory quanto o método Factory sejam estáticos. Dessa forma, o método new seria, de fato, chamado apenas dentro dos métodos factory. Entretanto essa é uma forma equivocada de se construir a factory já que a classe estática impede que a mesma seja estendida. Veremos mais adiante sobre a possibilidade de criar produtos abstratos e concretos.

Com isso, teremos no nosso código a classe e método factory

class AirplaneFactory {
    public create (prefix: string, manufacturer: string, aircraft: string): Airplane {
        return new Airplane(prefix, manufacturer, aircraft);
    } 
};

e na utilização, teremos

const airplaneFactory = new AirplaneFactory();

const embraerE195 = airplaneFactory.create('PR-ABC','Embraer','E195');

Note que sempre o método fábrica deve ter um produto do mesmo tipo da classe da regra de negócio, mesmo que seja um produto abstrato.

Aumentando a complexidade: Classes concretas e abstratas.

Iremos aumentar a complexidade do nosso exemplo. Teremos que na nossa regra de negócio, o avião não é uma entidade fechada mas que pode ser estendida para aviões de passageiros e aviões de carga. Também iremos definir que a classe Avião será abstrata, ou seja, não poderemos instanciar um objeto avião, apenas Avião de passageiros ou avião de carga.

No nosso novo diagrama, temos as classes PassengerAirplane e CargoAirplane, cada um com um atributo a mais em relação à classe abstrata Airplane. Também definimos as interfaces estendidas IPassengerAirplane e ICargoAirplane.

Iremos então modificar a classe Airplane para que seja abstrata

abstract class Airplane implements IAirplane {
    constructor(private _prefix: string,
        private _manufacturer: string,
        private _aircraft: string) {}

    get prefix(): string {
        return this._prefix
    }

    get manufacturer(): string {
        return this._manufacturer;
    }

    get aircraft(): string {
        return this._aircraft;
    }
}

Então iremos criar as classes concretas

interface IPassengerAirplane extends IAirplane {
    passengerCapacity: number;
    buyTicket(): void;
}


class PassengerAirplane extends Airplane implements IPassengerAirplane {

    constructor(prefix: string, manufacturer: string, aircraft: string, private _passengerCapacity: number) {
        super(prefix, manufacturer, aircraft);
    }

    get prefix(): string {
        return super.prefix
    }

    get manufacturer(): string {
        return super.manufacturer;
    }

    get aircraft(): string {
        return super.aircraft;
    }

    get passengerCapacity(): number {
        return this._passengerCapacity;
    }

    public buyTicket(): void {
        console.log(`New ticket emitted to ${this.manufacturer} ${this.aircraft} - Prefix: ${this.prefix}`);
    }
}

interface ICargoAirplane extends IAirplane {
    payload: number;
    loadCargo(weight: number)
}

class CargoAirplane extends Airplane implements ICargoAirplane {
    constructor(prefix: string, manufacturer: string, aircraft: string, private _payload: number) {
        super(prefix, manufacturer, aircraft);
    }

    get prefix(): string {
        return super.prefix
    }

    get manufacturer(): string {
        return super.manufacturer;
    }

    get aircraft(): string {
        return super.aircraft;
    }

    get payload(): number {
        return this._payload;
    }

    public loadCargo(weight: number){
        console.log(`${weight} loaded to ${this.manufacturer} ${this.aircraft} - Prefix: ${this.prefix}`);
    }
}

Por fim, devemos alterar a nossa classe e método fábrica. Nesse momento, como temos uma fábrica produzindo um produto do tipo Airplane, devemos manter os produtos concretos respeitando esse tipo e se temos dois produtos possíveis (avião de passageiros e avião de carga), teremos duas fábricas concretas respeitando uma fábrica abstrata.

A fábrica abstrata deixa de ter a implementação do método fábrica mas apenas a definição de um método abstrato.
As fábricas concretas estendem a fábrica abstrata e implementam os métodos fábrica concretos de acordo com suas especificidades.

Note pelo diagrama de classe que tanto as classes Airplane como AirplaneFactory são classes abstratas. Dessa maneira, as fábricas PassengerAirplaneFactory e CargoAirplaneFactory se tornam as fábricas concretas que geram os produtos concretos PassengerAirplane e CargoAirplane.

As fábricas concretas implementam o método create que agora é um método abstrato na AirplaneFactory. Apesar dos produtos serem diferentes, os produtos respeitam a interface IAirplane. Isso demonstra o fato de não criarmos o método fábrica como estático.

Vamos às implementações

abstract class AirplaneFactory {
    public abstract create (prefix: string, 
       manufacturer: string, 
       aircraft: string, 
       payload: number, 
       passengerCapacity: number): Airplane
};

class PassengerAirplaneFactory extends AirplaneFactory {
    public create (prefix: string, 
       manufacturer: string, 
       aircraft: string, 
       passengerCapacity: number): PassengerAirplane {
        return new PassengerAirplane(prefix,
           manufacturer,
           aircraft,
           passengerCapacity);
    } 
};

class CargoAirplaneFactory extends AirplaneFactory {
    public create (prefix: string,
       manufacturer: string, 
       aircraft: string, 
       payload: number): CargoAirplane {
        return new CargoAirplane(prefix,
           manufacturer,
           aircraft,
           payload);
    }
};

Por fim, vamos implementar as nossas classes fábricas concretas

const passengerAirplaneFactory = new 
    PassengerAirplaneFactory();

const cargoAirplaneFactory = new 
    CargoAirplaneFactory();

const E195 = passengerAirplaneFactory
    .create('PR-ABC', 
        'Embraer', 
        'E195', 
         118);

const KC390 = cargoAirplaneFactory
    .create('PR-DEF', 
        'Boeing', 
        'B747', 
         137);

E195.buyTicket();
KC390.loadCargo(100);

Note que no exemplo, as únicas instâncias com o método new são das nossas classes factory. Criamos dois objetos, um chamado E195 criado como um avião de passageiros com a fábrica concreta PassengerAirplaneFactory e outro objeto KC390 criado como um avião de carga com a fábrica concreta CargoAirplaneFactory.

Temos um exemplo chamando os métodos buyTicket e loadCargo para cada um desses objetos apesar de ambos serem do tipo Airplane.

Podemos nos questionar sobre o uso da classe AirplaneFactory. Se não podemos instanciar ela, não seria mais simples implementar apenas as fábricas concretas? A resposta é não, pois assim, perdemos a herança já que os dois produtos são produtos concretos de uma classe abstrata Airplane. Caso precisássemos adicionar uma classe para controlar aviões comerciais, todos eles devem respeitar a interface IAirplane e devem ser produtos do tipo Airplane.

Além disso, se você se questionou se podemos criar uma classe Factory concreta que tenha a capacidade de criar ambos os tipos de produto, a resposta é sim.

Nesse caso, temos o próximo padrão de projeto que é o Abstract Factory ou fábrica abstrata. Não trataremos dele aqui mas nesse padrão, a fábrica abstrata fica responsável por criar famílias de produtos concretos sem a necessidade de especificar a classe concreta. Mas lembre-se, que o AirplaneFactory do nosso exemplo não é um abstract factory. Desse modo, tornar uma classe fábrica abstrata não se enquadra no padrão de projeto Abstract factory.

Testando o Factory

Podemos fazer testes do nosso Factory para conferir se os produtos estão respeitando as instâncias das classes de domínio, especialmente nos casos de classes concretas e abstratas que devem implementar uma mesma interface.

Vamos realizar um teste em Jest mas você pode utilizar a biblioteca de testes da sua escolha e de acordo com a linguagem de programação que está utilizando.

Primeiro irei testar o PassengerAirplaneFactory. Como em todos os it eu irei usar uma instância nova do factory, irei colocar no beforeEach.

let passengerAirplaneFactory;
    beforeEach(() => {
        passengerAirplaneFactory = new 
             PassengerAirplaneFactory();
    });

Depois irei testar cinco pontos:

Se a PassengerAirplaneFactory é uma instância dela mesma.
Se a PassengerAirplaneFactory é uma instância da AirplaneFactory.
Se a PassengerAirplaneFactory cria um produto do tipo Airplane e do tipo PassengerAirplaneFactory.
E se a PassengerAirplaneFactory cria um produto que não é do tipo CargoAirplaneFactory.

Com todos esses testes, o código para testar a PassengerAirplaneFactory ficará da seguinte maneira:


describe('Passenger airplane factory', () => {

    let passengerAirplaneFactory;
    beforeEach(() => {
        passengerAirplaneFactory = new 
            PassengerAirplaneFactory();
    });

    it('is a instance of Airplane factory', () => {             
        expect(passengerAirplaneFactory)
            .toBeInstanceOf(AirplaneFactory);
    });

    it('is a instance of Passenger airplane factory', () => {
        expect(passengerAirplaneFactory)
            .toBeInstanceOf(PassengerAirplaneFactory);
    });
    it('creates a airplane and passenger 
    airplane product', () => {
        const E195 = passengerAirplaneFactory
            .create('PR-ABC', 
                'Embraer', 
                'E195', 
                 118); 
        expect(E195).toBeInstanceOf(Airplane);
        expect(E195).toBeInstanceOf(PassengerAirplane);
    });
    it('does not create a cargo airplane product', () => {
        const E195 = passengerAirplaneFactory
            .create('PR-ABC', 
                'Embraer', 
                'E195', 
                118); 
        expect(E195).not.toBeInstanceOf(CargoAirplane);
    });
});

Para os testes do CargoAirplaneFactory, temos as mesmas condições do caso do PassengerAirplaneFactory mas testando se ele gera produtos de CargoAirplane e Airplane e não de PassengerAirplane.


describe('Cargo airplane factory', () => {

    let cargoAirplaneFactory;
    beforeEach(() => {
        cargoAirplaneFactory = new CargoAirplaneFactory();
    });

    it('is a instance of Airplane factory', () => {    
        expect(cargoAirplaneFactory)
                .toBeInstanceOf(AirplaneFactory);
    });

    it('is a instance of Cargo airplane factory', () => {            
        expect(cargoAirplaneFactory)
            .toBeInstanceOf(CargoAirplaneFactory);
    });

    it('creates a airplane and cargo airplane product', () => 
    {
        const B747 = cargoAirplaneFactory
            .create('PR-DEF', 'Boeing', 'B747', 137); 
        expect(B747).toBeInstanceOf(Airplane);
        expect(B747).toBeInstanceOf(CargoAirplane);
    });

    it('does not create a passenger airplane product', () => 
    {
        const B747 = cargoAirplaneFactory
              .create('PR-DEF', 'Boeing', 'B747', 137); 
        expect(B747).not.toBeInstanceOf(PassengerAirplane);
    });
});

Por último e não menos importante, vamos verificar o resultado do nosso teste.

Finalizando, esse foi o padrão Factory. Espero que essa breve introdução tenha ajudado na compreensão do início dos Design Patterns e te estimule a continuar aplicando tanto esse padrão quanto os outros. Bons estudos.

Danilo Silva

Desenvolvedor de software experiente em boas práticas, clean code e no desenvolvimento de software embarcado e de integração com hardwares de controle e telecomunicação.

Linkedin
Github
E-mail

Socket.IO - Primeiros passos

Danilo Silva — Fri, 24 Feb 2023 18:19:36 +0000

Desde o início do desenvolvimento web, muitas pessoas desenvolvedoras enfretaram diversos impedimentos relacionados ao disparo de eventos. Antes mesmo dos diversos frameworks que gerenciam o estado das aplicações, as mesmas que agarravam apenas ao XMLHttpRequest para fazer requisições assíncronas às APIs próprias e de terceiros.

Entretanto, em algumas aplicações, queremos controlar estados e gerar nossos próprios eventos criando uma integração entre cliente e servidor que não necessita exclusivamente de uma API. Para isso, o Socket.IO pode nos ajudar muito.

Mas, o que é o Socket.IO?

O socket.IO é uma biblioteca que permite comunicação bidirecional e baseada em eventos entre um servidor e um cliente e o melhor, com baixa latência. Construído sobre o WebSocket, o mesmo permite reconexão e o envio de pacotes entre cliente e servidor com o menor custo para o seu servidor.

O socket.IO tem suporte para diversas linguagens:

Javascript
Java
Python
Golang
.NET
C++
Swift
Rust
Kotlin ...

Visto isso, vamos a uma pequena introdução utilizando Node.JS. O exemplo mais simples que temos para a utilização do socket.IO é a criação de uma sala de bate-papo. Isso porque temos uma aplicação de troca de mensagens entre diversos clientes em tempo real, cuja comunicação deve passar pelo servidor, seja apenas para gerenciamento ou para salvar em alguma base de dados.

Mas não precisamos salvar em uma base de dados para fornecer uma comunicação em tempo real. Temos apenas que criar uma comunicação baseada em eventos com o Socket.IO

Vamos ao código

Server-side

Primeiro, criamos um server http para o nosso back-end

// server.js
const http = require('http');
server = http.createServer(app);

Depois, vamos criar um novo arquivo chamado Room.js, onde deixaremos todos os nossos eventos do socket.IO e vamos dizer ao nosso server que, ao se conectar, nossos eventos estarão sem gerenciados nesse arquivo.

// server.js
const io = require('socket.io')(server);
const Room = require('./Room')(io);
server.listen(port, () => console.log("Chat online"));

Podemos agora criar o arquivo Room.js para centralizar nossos eventos. E nesse momento, vamos começar a trabalhar de fato com o Socket.IO utilizando apenas dois métodos: on e emit.

O método on é o método que diz qual é o evento que você deseja receber e quais as informações e códigos relacionados ao mesmo. É basicamente o método que serve como sua caixa de entrada.

O método emit, ao contrário do on, é o método que dispara uma mensagem para algum evento e envia as informações. É basicamente o método que serve como caixa de saída.

Relacionando os dois métodos, você pode ter os dois tanto no lado cliente como no lado servidor e para exemplificar, se você tem no server-side o método on e no client-side o método emit, temos

   // server-side
   socket.on('mensagem', function(texto) {
       console.log(texto);
   });

   // client-side
   socket.emit('mensagem', 'Olá pessoas desenvolvedoras do tabnews');

Isso quer dizer que no momento que disparássemos o código do cliente, seja por um botão ou qualquer outra interação qualquer, teríamos um print no back-end da mensagem Olá pessoas desenvolvedoras do tabnews

E como o socket.IO sabe onde direcionar?

Graças ao nome do evento, mensagem, que você escolheu. Enquanto nos métodos emit, temos como parâmetro o nome do evento e alguma informação, nos métodos on temos o mesmo nome de evento e uma função que receberá como parâmetro, todos os outros parâmetros restantes do método emit. Legal né?

Agora, alguns conhecimentos mais avançados. No socket.io, temos o conceito de salas. Na qual cada client pode ser direcionado a uma sala e as mensagens podem ser direcionadas tanto a uma sala como a algun cliente específico. Dessa forma, temos mais 03 métodos interessantes: join, leave e to.

O método join serve para direcionar um cliente a alguma sala. A construção do mesmo é apenas indicar qual o nome da sala. Então temos:

socket.join(nomeDaSala);

O método leave serve para fazer o oposto do método join, ou seja, tirar o cliente de alguma sala. Então temos:

socket.leave(nomeDaSala);

O método to, por último serve para enviar uma mensagem em determinada sala. Ele se une ao método emit mas garantindo que apenas os clientes associados à determinada sala recebam a mensagem. Então temos:

socket.to(nomeDaSala).emit('mensagem', 'Olá pessoas desenvolvedoras do tabnews');

O resto do funcionamento é o mesmo. Trazendo esse contexto para o nosso Room.js, temos o seguinte bloco de código

 function listen(socket){
    const io = _io;

    socket.on('join', function(sala){
        socket.join(sala);
    });

    socket.on('leave', function(sala){
        socket.leave(sala);
    });

    socket.on('mensagem', function(Sala, Mensagem){
        socket.to(Sala).emit('msg', Mensagem);
    });
 }

module.exports = function(io){
    _io = io;
    return {listen};
};

Client-side

Agora para o nosso lado cliente, temos basicamente, todos os mesmos eventos mas com construções inversas. Onde temos on de um lado, temos emit do outro.

 socket.on('msg', function(Mensagem){
     // Código relacionado a receber uma mensagem no cliente.
 });

 socket.emit("join",nomeDaSala);

 socket.emit("leave", nomeDaSala);

Repositório completo

Para facilitar na absorção, deixei um repositório pronto como uma sala básica de bate-papo com socket.IO. Não utilizei muitos frameworks e para ser absorvido, independentemente da tecnologia de front-end que você utiliza, deixei com JQuery que é mais simples de entender.

O repositório pode ser encontrado aqui.

O que mais posso fazer com Socket.IO

Apesar da sala de bate-papo ser o exemplo mais didático da utilização dessa biblioteca, podemos fazer inúmeras aplicações com Socket.IO

Jogos online
SIP Server (VoIP)
WebRTC ...

Inclusive, com o Socket.IO, podemos fazer uns clones funcionais bem interessantes, como o clone de softwares como:

Discord
Zoom
Twitch

Mas esses clones e a explicação de WebRTC, caso gostem desse conteúdo, deixamos para uma próxima.

Espero que gostem. Bons estudos