DEV Community: Janduy Monroe

Formatos de serialização: do hype ao hippie

Janduy Monroe — Thu, 18 Jan 2024 12:08:17 +0000

A Necessidade Emergente de Serialização: Uma Viagem ao Passado

A história dos formatos de serialização remonta aos primórdios da computação, quando a troca eficiente de dados entre sistemas tornou-se uma demanda crescente. Com o advento da comunicação entre computadores e a necessidade de representar dados complexos de forma estruturada, os desenvolvedores se viram diante do desafio de criar métodos eficazes para serializar e desserializar informações.

Os Primeiros Esforços e Projetos: Pioneirismo na Serialização de Dados

Nos primeiros dias da computação, a serialização não era uma preocupação proeminente, pois as interações entre sistemas eram limitadas e os dados frequentemente simples. À medida que as aplicações começaram a se tornar mais sofisticadas e a interoperabilidade entre sistemas se tornou essencial, os primeiros esforços para padronizar a representação de dados ganharam destaque.

Um marco inicial foi a ascensão de formatos como o ASN.1 (Abstract Syntax Notation One) na década de 1980, desenvolvido para descrever estruturas de dados independentes de máquina. Esse formato foi essencial em protocolos de comunicação, como o SNMP (Simple Network Management Protocol), evidenciando a necessidade de uma abordagem estruturada na representação de dados.

Na década de 1990, com o crescente uso da web, o XML (Extensible Markup Language) emergiu como uma resposta à demanda por uma linguagem de marcação que pudesse representar dados de maneira hierárquica e extensível. Sua natureza legível por humanos e máquinas o tornou amplamente adotado em serviços web e integração de sistemas.

À medida que as aplicações se tornavam mais orientadas a serviços e distribuídas, a eficiência tornou-se uma prioridade. Surgiram então formatos binários como o Protocol Buffers (protobuf), desenvolvido pelo Google, e o Apache Thrift, utilizado pelo Facebook. Essas tecnologias buscaram otimizar a serialização para melhorar o desempenho em ambientes distribuídos.

A evolução continuou com o destaque do JSON (JavaScript Object Notation) na década de 2000, oferecendo uma alternativa leve e fácil de usar em comparação com o XML. O JSON se tornou predominante em aplicações web devido à sua simplicidade e compatibilidade com várias linguagens.

No início do século XXI, o MessagePack entrou em cena como uma alternativa binária eficiente ao JSON, otimizando ainda mais o tamanho dos dados serializados. O formato YAML, com sua sintaxe limpa e amigável, também ganhou popularidade, especialmente em configurações de aplicativos e arquivos de configuração.

A era do smartphone e o JSON

O JSON ganhou imensa popularidade devido à sua simplicidade, leveza e facilidade de leitura, características essenciais para a comunicação eficiente entre sistemas web. Sua adoção generalizada nas APIs de serviços web contribuiu para a simplificação do desenvolvimento de aplicativos, especialmente no contexto dos smartphones.

Nos primórdios dos smartphones, onde os recursos de largura de banda e poder de processamento eram limitados, o JSON se destacou como uma escolha ideal para a troca de dados entre aplicativos e servidores. Sua eficiência na serialização e desserialização de informações permitiu uma experiência mais ágil para os usuários, impulsionando a evolução dos aplicativos móveis.

A capacidade do JSON de representar dados de forma estruturada e hierárquica também facilitou a criação de interfaces de usuário dinâmicas e interativas em dispositivos móveis. A portabilidade e a simplicidade do JSON desempenharam um papel crucial na revolução dos smartphones, permitindo que aplicativos acessassem e trocassem dados de maneira eficiente, independentemente do sistema operacional.

Integração de Formatos de Serialização com Protocolos de Comunicação

Na paisagem diversificada dos formatos de serialização, observamos uma distinção crucial quanto à integração com protocolos de comunicação. Alguns formatos têm seus próprios protocolos dedicados, enquanto outros se adaptam a protocolos estabelecidos. Essa diferenciação desempenha um papel significativo na interoperabilidade e desempenho dos sistemas.

Formatos com Protocolo Próprio:

Protocol Buffers (protobuf): Desenvolvido pelo Google, o Protocol Buffers possui seu próprio protocolo de comunicação. Esse protocolo é otimizado para a eficiente serialização e desserialização de dados, tornando-o particularmente adequado para ambientes distribuídos e comunicação interprocessual.

Apache Thrift: Similar ao protobuf, o Apache Thrift possui seu próprio protocolo. Criado pelo Facebook, o Thrift oferece suporte a diversas linguagens de programação e é projetado para facilitar a comunicação eficiente entre sistemas heterogêneos.

Formatos Integrados a Protocolos Estabelecidos:

JSON (JavaScript Object Notation): O JSON é agnóstico em relação ao protocolo de comunicação, sendo amplamente utilizado em conjunção com protocolos estabelecidos, como HTTP. Sua simplicidade e leveza o tornam uma escolha popular para APIs RESTful em aplicações web.

XML (Extensible Markup Language): Similar ao JSON, o XML é frequentemente utilizado em conjunto com protocolos como HTTP e SOAP (Simple Object Access Protocol). Sua estrutura hierárquica e extensibilidade o tornam adequado para diversos cenários de comunicação.

MessagePack: Como um formato binário eficiente, o MessagePack é versátil e pode ser utilizado em conjunto com diferentes protocolos, adaptando-se facilmente a ambientes que requerem otimização de tamanho e desempenho.

YAML (YAML Ain't Markup Language): O YAML é comumente utilizado em configurações de aplicativos e, similar ao JSON, pode ser integrado a protocolos estabelecidos, proporcionando flexibilidade na escolha do protocolo de comunicação mais adequado ao contexto.

A escolha entre formatos com protocolo próprio e aqueles integrados a protocolos estabelecidos depende das necessidades específicas de um projeto. Enquanto formatos com protocolo próprio oferecem otimizações específicas, os integrados a protocolos estabelecidos proporcionam flexibilidade e interoperabilidade em ecossistemas variados. Essa decisão estratégica impacta diretamente na eficiência da comunicação entre sistemas e na experiência geral do usuário.

E a grande questão. Qual o melhor???

Contras:

Eficiência de Espaço: Menos eficiente em termos de espaço em comparação com formatos binários.
Menos Compatível com Alguns Serviços: Pode ser menos compatível com alguns serviços que favorecem formatos mais compactos.

Em suma, a escolha entre esses formatos de serialização e seus protocolos associados depende das necessidades específicas do projeto, considerando critérios como eficiência, legibilidade, adoção na comunidade e suporte nos principais provedores de nuvem.

Executando GitHub Actions Localmente

Janduy Monroe — Tue, 16 Jan 2024 17:27:16 +0000

O que é o Github Actions???

GitHub Actions é uma plataforma de integração contínua e entrega contínua (CI/CD) que permite automatizar seus pipelines de construção, teste e implantação. Com ela, é possível criar fluxos de trabalho que constroem e testam cada pull request no seu repositório, ou implantar pull requests mesclados na produção.

Um fluxo de trabalho (workflow) é um processo automatizado configurável que executará um ou mais jobs. Esses fluxos são definidos por meio de arquivos YAML no seu repositório. Um evento é uma atividade específica em um repositório que aciona a execução de um fluxo de trabalho, como a criação de um pull request ou o envio de commits para um branch. Um job é um conjunto de passos em um fluxo de trabalho que pode ser executado simultaneamente com outros jobs.

Embora o GitHub Actions seja excelente para automatizar fluxos de trabalho, às vezes é útil executar suas ações localmente na máquina de desenvolvimento. Isso permite testar os fluxos em um ambiente mais controlado antes de enviar alterações para o repositório.

E como fazer isso?

Pré-requisitos:

Certifique-se de ter instalados na sua máquina o Git, Docker e Act caso não estejam é só seguir esse workflow:

Git

Windows:

Instale o Git para Windows baixando e executando o instalador em https://git-scm.com/download/win.

Linux:

Use o seguinte link
https://git-scm.com/book/pt-br/v2/Come%C3%A7ando-Instalando-o-Git.

Docker

Windows:

Instale o Windows Subsystem for Linux (WSL) seguindo as instruções em https://docs.microsoft.com/en-us/windows/wsl/install-win10.

Instale o Docker Desktop for Windows baixando e executando o instalador em https://docs.docker.com/desktop/install/windows-install/. Opte por usar o docker com o WSL pois com o hyper-V fica bem pesado.

Abra o PowerShell como administrador e execute o comando:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Linux:

Instale o Docker seguindo as instruções em https://docs.docker.com/engine/install/.

act

Windows:

Instale o act com o comando
choco install act-cli

Caso não tenha o chocolatey instalado siga os passos no próprio site: https://docs.chocolatey.org/en-us/choco/setup.

Linux:

Instale o act seguindo o passo a passo: https://lindevs.com/install-act-on-ubuntu.

Depois de tudo configurado e funcionando

Vamos botar pra funcionar.

Clone seu repositório para sua máquina local.

Crie um novo arquivo de workflow no diretório .github/workflows do seu repositório.

No arquivo do workflow, defina os passos que deseja executar localmente.

Abra seu terminal e navegue até o diretório onde seu repositório está localizado.

Execute o comando act --list para listar todos os fluxos de trabalho no repositório.

Para executar um job específico, use o comando act -j <Nome do Job>. Caso queira que seja executado todo o workflow execute apenas este comando act

Executar GitHub Actions localmente é uma muito bom para testar seus fluxos e garantir que eles funcionem conforme esperado antes de enviar alterações para seu repositório.

Evite encher o seu action com testes.

Agora na minha máquina roda e ainda publica.

IHostedService Vs BackgroudService

Janduy Monroe — Wed, 13 Dec 2023 14:46:36 +0000

IHostedService e BackgroundService no .NET

O .NET fornece duas interfaces para implementar tarefas em segundo plano: IHostedService e BackgroundService.

IHostedService é uma interface abstrata que fornece métodos para iniciar, parar e reiniciar uma tarefa em segundo plano.

BackgroundService é uma classe base que implementa a interface IHostedService. Ela fornece métodos e propriedades adicionais para facilitar a implementação de tarefas em segundo plano.

Comparação entre IHostedService e BackgroundService

A principal diferença entre IHostedService e BackgroundService é que BackgroundService fornece uma implementação padrão para os métodos StartAsync(), StopAsync() e DisposeAsync(). Isso pode facilitar a implementação de tarefas em segundo plano, mas também pode limitar a flexibilidade.

Se você precisa de controle total sobre a implementação de uma tarefa em segundo plano, deve usar IHostedService.

Quando usar um ou outro?

Em geral, BackgroundService é recomendado para tarefas que podem ser executadas por um longo período de tempo, sem a necessidade de interação com a interface do usuário. Isso inclui tarefas como:

Envio de e-mail
Download de arquivos
Processamento de dados
Monitoramento de sistemas

IHostedService é recomendado para tarefas que precisam ser executadas de forma mais rápida, ou que precisam interagir com a interface do usuário. Isso inclui tarefas como:

Envio de push notifications
Requisição de dados da API
Atualização de dados na tela

No entanto, a escolha do tipo de implementação a ser usada depende de uma série de fatores, como o tempo de execução da tarefa, a necessidade de interação com a interface do usuário e as preferências do desenvolvedor.

Aqui estão alguns critérios que podem ser usados para ajudar a tomar a decisão:

Tempo de execução da tarefa: Se a tarefa for executada por um longo período de tempo, BackgroundService é a melhor opção. Isso ocorre porque BackgroundService usa um thread separado para executar a tarefa, o que evita que ela bloqueie a interface do usuário.
Necessidade de interação com a interface do usuário: Se a tarefa precisar interagir com a interface do usuário, IHostedService é a melhor opção. Isso ocorre porque IHostedService permite que a tarefa seja executada no mesmo thread que a interface do usuário, o que facilita a interação entre as duas.
Preferências do desenvolvedor: Em última análise, a escolha do tipo de interface a ser usada depende das preferências do desenvolvedor. Alguns desenvolvedores preferem a flexibilidade que IHostedService oferece, enquanto outros preferem a simplicidade de BackgroundService.

Implementando uma tarefa em segundo plano com IHostedService

Para implementar uma tarefa em segundo plano com IHostedService, você deve criar uma classe que implemente a interface. A classe deve implementar os seguintes métodos:

StartAsync(): Task - Este método é chamado quando a tarefa em segundo plano é iniciada.

StopAsync(): Task - Este método é chamado quando a tarefa em segundo plano é interrompida.

DisposeAsync(): Task - Este método é chamado quando a tarefa em segundo plano é descartada.

De forma bastante simplificada podemos implementa-lá da seguinte forma:

public class MyHostedService : IHostedService
{
    public Task StartAsync(CancellationToken cancellationToken)
    {
        // Execute the background task
        return Task.Run(() =>
        {
            // Do something in the background
        });
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        // Cleanup any resources used by the background task
        return Task.CompletedTask;
    }

    public Task DisposeAsync()
    {
        // Dispose of any resources used by the background task
        return Task.CompletedTask;
    }
}

Para registrar uma tarefa em segundo plano implementada por IHostedService, você pode usar o método AddHostedService() da classe Host da seguinte forma:

using Microsoft.Extensions.Hosting;

namespace MyApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // Create the host
            var host = new HostBuilder()
                .ConfigureServices((services) =>
                {
                    // Register the background service
                    services.AddHostedService(new MyHostedService());
                })
                .Build();

            // Start the host
            host.Run();
        }
    }
}

Implementando uma tarefa em segundo plano com BackgroundService

A classe BackgroundService fornece uma implementação padrão para os métodos StartAsync(), StopAsync() e DisposeAsync(). Isso facilita a implementação de tarefas em segundo plano.

Para implementar uma tarefa em segundo plano com BackgroundService, você deve criar uma classe que herde da classe BackgroundService. A classe herdada pode substituir os métodos StartAsync() e StopAsync() para fornecer a funcionalidade desejada, mas pode ser usada apenas o método Execute e deixar abstraído pela classe mãe as implementações de start e stop.

public class MyBackgroundService : BackgroundService
{
    protected override async Task StartAsync(CancellationToken cancellationToken)
    {
        // Execute the background task
        await Task.Run(() =>
        {
            // Do something in the background
        });
    }
}

Para registrar uma tarefa em segundo plano implementada por BackgroundService, você pode usar o método AddHostedService() da classe Host.

using Microsoft.Extensions.Hosting;

namespace MyApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // Create the host
            var host = new HostBuilder()
                .ConfigureServices((services) =>
                {
                    // Register the background service
                    services.AddHostedService(new MyBackgroundService());
                })
                .Build();

            // Start the host
            host.Run();
        }
    }
}

Entenda bem cada implementação e assim poderá fazer a melhor escolha. E as functions?!?! Aí é outra história.