DEV Community: pedrovian4

Monólitos Modernos com Internacionalização:InertiaJS, React & Laravel.

pedrovian4 — Sun, 02 Feb 2025 20:22:21 +0000

InertiaJS é um adpater para aplicações monólitos usarem frameworks/bibliotecas e afins do ecossistema JavaScript. Esse artigo vai se limitar em somente em como fazer uma internacionalização usando ainda as ferramentas out of box do laravel.

Internacionalização padrão laravel. 🌎️

Nos tópicos de internacionalização ou localização do framework laravel, é deixado explícito que por padrão laravel não vem com os diretórios de internacionalização criados, para isso é necessário rodar php artisan lang:publish. Por padrão laravel criará uma estrutura nesse estilo.


/lang
    /en
        messages.php
    /es
        messages.php

Para usar nesse tutorial do inertia, apague os subdiretórios com en, es, nosso método de internacionalização será usando arquivos json. Antes de avançar para os próximos passos, caso tenham interesse recomendo uma leitura mais detalhada de documentação de internacionalização do laravel. Documentação

Internacionalizando com Inertia 🇧🇷 🇷🇺 🇨🇳 🇿🇦 🇮🇳

1) Definição de língua padrão do seu sistema

Qual a importância disso? Bom, essa será a língua que você estará programando no seu dia a dia, escolha com cuidado, sempre busque usar a língua o qual seu cliente alvos são nativos.

Já escolheu? Certo, então vamos lá.

2) Criação dos arquivos de internacionalização

Dentro do diretório lang/ crie um arquivo com o nome da localização da sua língua do tipo JSON. Exemplo: Em meu sistema a língua padrão é o inglês, mas esse sistema será usado por brasileiros também, então irei criar um arquivo lang/pt_br.json, nesse arquivo irei definir as string em via chave e valor, do inglês para português brasileiro. O arquivo ficará na possível seguinte estrutura.


{
    "Log in":"Entrar",
    "Password": "Senha",
    "Remember me": "Lembrar do ultímo acesso",
    "Email":"E-mail",
    "Forgot your password?":"Esqueci minha senha",
    "Name":"Nome",
    "Confirm Password": "Confirme sua senha",
    "Already registered?": "Já possui um registro?",
    "Register": "Registrar"
}

Chuchu🥒Beleza👍️! Agora você já tem seus arquivo de internacionalização. Você pode criar quantos quiser, apenas garanta que o nome do arquivo seja igual o nome da localização, normalmente essa informação fica no seu env com a chave APP_LOCALE da sua aplicação.

3) Enviando dados para para o frontend.

Essa parte é simples, no seu Inertia Middleware. Coloque o seguinte código.

    $locale = app()->currentLocale();
    $filePath = base_path('lang/' . $locale . '.json');
    $language = File::json($filePath);

agora basta enviar esses dados para frontend, um conselho de amigo é colocar esse código em uma função de helper. Seu middleware estará parecendo algo como.

l é a minha função que traz o arquivo de tradução.


    /**
     * Define the props that are shared by default.
     *
     * @return array<string, mixed>
     */
    public function share(Request $request): array
    {
        $lang = l();
        logs()->debug(["lang" => $lang]);
        return [
            ...parent::share($request),
            'auth' => [
                'user' => $request->user(),
            ],
            'ziggy' => fn() => [
                ...(new Ziggy)->toArray(),
                'location' => $request->url(),
            ],
            'lang' => $lang,
        ];
    }

4) Consumindo no frontend.

Agora que já podemos acessar esses dados pela o hook do inertia de usePage().props, podemos criar uma função de utils em nosso front que nos retorne o valor traduzido.


export function t(key: string) {
    // eslint-disable-next-line react-hooks/rules-of-hooks
    const { lang } = usePage<PageProps>().props;

    if (!lang) return key;

    if (!lang[key]) return key;

    return lang[key];
}

Dessa forma nosso frontend podemos agora escrever nossos componentes da seguinte maneira.

 <InputLabel htmlFor="email" value={t('Email')} />

Assim tornando uma internacionalização mais simples. Claro, há problemas que essa abordagem não trata como pluralização e substituição. Mas o intuito dela é resolver o problema para aplicações com uso simples de internacionalização. Caso sua aplicação precise de coisas além, pode comentar aqui para nós trocarmos uma ideia e quem sabe pensar em uma solução. Até mais 👋

Entendendo memória em transações financeiras

pedrovian4 — Thu, 14 Mar 2024 05:22:25 +0000

O advento do método de pagamento instantâneo PIX, sem dúvida, revolucionou a maneira como lidamos com transações financeiras digitais. No entanto, por trás da simplicidade e velocidade dessas operações, há um desafio crucial a ser enfrentado: como garantir que os dados permaneçam coerentes em meio a uma enxurrada de transações em tempo real?

Exemplificando o problema

Vamos considerar uma situação comum em aplicações financeiras: a transferência de valores entre contas bancárias. Para ilustrar esse cenário, utilizaremos a linguagem de programação Go.

package main

import (
    "fmt"
)

type Conta struct {
    Numero int
    Saldo  float64
}

func transferir(origem, destino *Conta, valor float64) {
    if origem.Saldo >= valor {
        origem.Saldo -= valor
        destino.Saldo += valor
        fmt.Printf("Transferência de R$%.2f da conta %d para a conta %d realizada com sucesso.\n", valor, origem.Numero, destino.Numero)
    } else {
        fmt.Printf("Saldo insuficiente na conta %d para realizar a transferência de R$%.2f.\n", origem.Numero, valor)
    }
}

func main() {
    // Criando contas
    conta1 := Conta{Numero: 1, Saldo: 1000}
    conta2 := Conta{Numero: 2, Saldo: 500}

    // Realizando transferência
    transferir(&conta1, &conta2, 300)

    // Exibindo saldos após transferência
    fmt.Printf("Saldo da conta 1: R$%.2f\n", conta1.Saldo)
    fmt.Printf("Saldo da conta 2: R$%.2f\n", conta2.Saldo)
}

Neste exemplo, criamos duas contas bancárias (conta1 e conta2) com saldos iniciais e realizamos uma transferência de R$300 da conta1 para a conta2, verificando se há saldo disponível antes da transação.

Agora, vamos levar esse exemplo ao extremo, introduzindo concorrência utilizando as goroutines do Go para simular várias transferências simultâneas entre as contas, como múltiplos clientes fazendo diversas requisições de transferência.

package main

import (
    "fmt"
    "sync"
)

type Conta struct {
    Numero int
    Saldo  float64
}

func transferir(origem, destino *Conta, valor float64, wg *sync.WaitGroup) {
    defer wg.Done()
    if origem.Saldo >= valor {
        origem.Saldo -= valor
        destino.Saldo += valor
    }
}

func main() {
    // Criando contas
    conta1 := Conta{Numero: 1, Saldo: 1000}
    conta2 := Conta{Numero: 2, Saldo: 500}

    // Definindo o número de transferências e a quantidade de cada transferência
    numTransferencias := 100
    valorTransferencia := 10

    var wg sync.WaitGroup

    // Iniciando as transferências concorrentes
    for i := 0; i < numTransferencias; i++ {

      // se i é divisível por 10 e espera as outras transações acabarem para continuar as outras 10
       if i%10 ==0 {
           wg.Wait()
       }

        wg.Add(10)
        go transferir(&conta1, &conta2, float64(valorTransferencia), &wg)
    }

    // Aguardando a conclusão de todas as goroutines
    wg.Wait()

    // Exibindo saldos após transferências
    fmt.Printf("Saldo da conta 1: R$%.2f\n", conta1.Saldo)
    fmt.Printf("Saldo da conta 2: R$%.2f\n", conta2.Saldo)
}

Se executarmos esse código acima teremos um cenário parecido com o que teríamos em aplicações de transferências bancarias, mas claro, bem longe da realidade. Executando esse código com concorrência temos nosso primeiro erro de acesso simultâneo na memória o temido DeadLock

Entendendo Deadlock

Para compreendermos o que é um Deadlock, podemos recorrer às nossas aulas de Sistemas Operacionais. Um Deadlock ocorre quando dois ou mais processos ficam bloqueados e incapazes de prosseguir com suas execuções. No contexto da concorrência em Go, podemos inadvertidamente criar um Deadlock ao não gerenciar adequadamente as dependências entre as goroutines.

Imagine que, em nosso exemplo de transferências bancárias, decidimos limitar o número de tarefas em execução simultânea a 1, aguardando cada uma ser concluída antes de iniciar a próxima. Isso, no entanto, contraria a natureza concorrente das operações bancárias, onde várias transferências podem ocorrer simultaneamente.

Atomicidade e gerenciamento de concorrência

Quando falamos de Sistemas de banco de dados, uma coisa muito citada é a atomicidade das operações dentro dele, como no nosso caso não iremos usar um sistema de gerenciamento de banco de dados vamos garantir que nossas operações sejam atômica em memória. Vamos primeiro para definição de uma operação atômica.

Operação Atômica: : A atomicidade é a propriedade que garante que uma operação ocorra como uma única unidade indivisível, sem ser interrompida por outras operações.

Dito isso como garantimos uma atomicidade no nosso código? Antes de irmos para a solução, voltamos mais uma vez em uma das causas do DeadLock a Exclusão Mútua que é a existência de recursos que precisam ser acessados de forma exclusiva, que em nosso exemplo seria os valores das contas que são alterados ali durante as transferências. Visto a essa necessidade, a estrutura de dados Mutex foi criada

Mutex ou Mutual Exclusion

Mutex é uma estrutura de dados essencial em programação concorrente, garantindo exclusão mútua, o que significa que apenas uma tarefa (ou goroutine) pode acessar um recurso compartilhado por vez.

Exclusão Mútua implica que apenas uma solicitação de transação (ou tarefa) pode acessar um recurso compartilhado em determinado momento. No contexto de operações bancárias, cada solicitação de transação é tratada individualmente e com segurança.

O objetivo do mutex é garantir que cada solicitação de transação tenha acesso exclusivo aos recursos compartilhados, como os saldos das contas, evitando conflitos e inconsistências nos dados ao processar múltiplas transações simultaneamente.

Controle de concorrência com channels e mutex

Os Channels são uma estrutura de dados comum em linguagens de programação concorrentes, permitindo a comunicação e sincronização entre processos ou threads. Eles são usados para transferir dados entre diferentes partes do programa de forma segura e eficiente, facilitando a coordenação da execução concorrente.

Os Channels possuem uma estrutura de fila, onde os dados são armazenados temporariamente enquanto aguardam ser lidos por outra parte do programa. Eles garantem que a escrita e a leitura de dados ocorram de maneira assíncrona e segura, evitando problemas como race conditions e deadlocks.

Por exemplo, em um programa que possui duas threads, uma responsável por gerar dados e outra por processá-los, podemos utilizar um Channel para enviar os dados da thread de geração para a thread de processamento. Isso permite que as threads trabalhem de forma independente, sem interferir uma na outra, e ainda assim coordenem suas atividades através da troca de dados pelo Channel.

Contornando o DeadLock

Nesse código abaixo podemos ver o uso do mutex para garantir que o saldo entre as contas que operam de transferências de maneira concorrente tenham exclusão mútua, em seguia são utilizado os channels como um mecanismo de coordenação entre nossas tarefas concorrentes, ou melhor nossas goroutines, nesse exemplo utilizamos um semáforo que controla a quantidade de go routine que podem acessar nosso recurso compartilhado, dessa meneira, evitamos o nosso temido DeadLock.

Outra alteração importante foi a passagem das 10 goroutines sendo adicionadas ao wait group para uma adição individual, enquanto o channel faz a gestão de 10 goroutines em concorrência, o primeiro exemplo estava forçando as 10 no wait group era para forçar nosso DeadLock

package main

import (
    "fmt"
    "sync"
)

type Conta struct {
    Numero int
    Saldo  float64
    mu     sync.Mutex // Mutex para proteger o acesso às contas
}

func transferir(origem, destino *Conta, valor float64, wg *sync.WaitGroup, sema chan struct{}) {
    defer wg.Done()

    sema <- struct{}{} // Adquire um token do semáforo
    defer func() { <-sema }() // Libera o token do semáforo ao finalizar

    origem.mu.Lock()
    defer origem.mu.Unlock()
    destino.mu.Lock()
    defer destino.mu.Unlock()

    if origem.Saldo >= valor {
        origem.Saldo -= valor
        destino.Saldo += valor
    }
}

func main() {
    // Criando contas
    conta1 := Conta{Numero: 1, Saldo: 1000}
    conta2 := Conta{Numero: 2, Saldo: 500}

    // Definindo o número de transferências e o valor de cada transferência
    numTransferencias := 100
    valorTransferencia := 10

    var wg sync.WaitGroup
    sema := make(chan struct{}, 10) // Semáforo com capacidade para 10 tokens

    // Iniciando as transferências concorrentes
    for i := 0; i < numTransferencias; i++ {
        wg.Add(1)
        go transferir(&conta1, &conta2, float64(valorTransferencia), &wg, sema)
    }

    // Aguardando a conclusão de todas as goroutines
    wg.Wait()

    // Exibindo saldos após as transferências
    fmt.Printf("Saldo da conta 1: R$%.2f\n", conta1.Saldo)
    fmt.Printf("Saldo da conta 2: R$%.2f\n", conta2.Saldo)
}

Considerações

É importante destacar que os códigos e exemplos fornecidos têm propósitos puramente educacionais. Enquanto o uso de canais (channels) por si só em condições simples já evita deadlock, a combinação coordenada de mutexes e canais é uma estratégia valiosa, especialmente ao lidar com ambientes mais complexos que compartilham mais do que uma única propriedade de memória ou outras estruturas.

Essa abordagem permite um controle mais refinado sobre o acesso concorrente aos recursos compartilhados, garantindo a consistência e integridade dos dados em ambientes concorrentes.

Aplicações Laravel que gritam seu domínio

pedrovian4 — Wed, 20 Dec 2023 15:29:43 +0000

Laravel rapidamente se tornou a estrela do desenvolvimento PHP, e temos Taylor Otwell para agradecer por isso. Não é apenas um framework; é quase uma varinha mágica para desenvolvedores PHP, transformando tarefas complexas em algo simples. Com seu tool-kit completo, o Laravel revolucionou a maneira como pensamos o desenvolvimento em PHP, tornando-o mais acessível e prazeroso.

Mas aqui está uma consideração importante: às vezes, nossos queridos apps Laravel tendem a se parecer um pouco... uniformes. Não é um "erro" do Laravel, mas sim uma característica intrínseca a muitos frameworks fullstack ou REST que são ricos em funcionalidades. Eles oferecem tantas ferramentas e estruturas prontas que, sem um esforço consciente, podemos acabar com aplicações que, apesar de altamente funcionais, não se destacam em termos de personalidade única (Não gritam seu domínio).

Domínios Gritantes

Sabe como uma primeira impressão pode dizer muito? No mundo do desenvolvimento de software, isso é regra de ouro. E é aqui que a ideia dos "Domínios Gritantes" entra em cena, um conceito cunhado pelo famoso Uncle Bob como "Screaming Architecture". O truque é simples: só de dar uma olhada na estrutura de um software, você já capta a ideia geral do que ele se propõe a fazer. É como se o próprio código te desse as boas-vindas e te contasse sua história.

Aqui um simples exemplo: nosso domínio será uma empresa de logística. Antes de te da contexto gostaria apenas que olhasse para a estrutura de pastas desse modelo de negócio. Leia cuidadosamente cada nome de pasta e cada nome de classe (Lembrando arquitetura de software não é somente organização de arquivos)
Importante: nome de arquivos estão em português para fins de clareza na explicação, mas sempre escreva software em inglês.

app/ │ ├── Models/ │ ├── Produto.php │ ├── Armazem.php │ ├── Transporte.php │ └── Rastreio.php | |__ ProdutoTipo.php | |__ RastreioTipo.php │ ├── Repositories/ │ ├── ProdutoRepository.php │ ├── ArmazemRepository.php │ ├── TransporteRepository.php │ └── RastreioRepository.php │ ├── Contracts/ │ ├── TransporteStrategyInterface.php │ ├── RastreioStrategyInterface.php │ ├── VeiculoInterface.php │ └── RastreioInterface.php │ ├── Strategies/ │ ├── TransporteStrategy.php │ ├── RastreioStrategy.php │ ├── Transporte/ │ │ ├── NavioStrategy.php │ │ ├── CaminhaoStrategy.php │ │ └── AviaoStrategy.php │ └── Rastreio/ │ ├── RastreioTempoRealStrategy.php │ └── RastreioPadraoStrategy.php │ ├── Services/ │ ├── RastreioService.php │ ├── TransporteService.php │ ├── ArmazenamentoService.php │ └── EntregaService.php │ ├── Controllers/ │ ├── ProdutoController.php │ ├── TransporteController.php │ ├── RastreioController.php │ └── ArmazenamentoController.php │ ├── Factories/ │ ├── VeiculoFactory.php │ └── RastreioFactory.php │ └── Jobs/ ├── AtualizarStatusEntrega.php ├── NotificarRastreioTempoReal.php └── ProcessarEntregaProduto.php

Entendo Domínio de logística

No nosso modelo de logística, lidamos principalmente com transporte, o que implica que estamos sempre movimentando algo – neste caso, produtos. No nosso modelo de negócio, oferecemos o rastreamento desses produtos, e o tipo de rastreamento varia conforme o veículo utilizado. Cada meio de transporte, seja por terra, mar ou ar, possui um sistema de rastreio adaptado às suas características e necessidades específicas.

No nosso projeto Laravel voltado para logística, cada elemento da arquitetura não apenas cumpre uma função específica, mas também ecoa fortemente o domínio a que pertence. Com a Separação de Preocupações (SoC) e injeções de dependência bem implementadas, criamos um sistema onde a função de cada parte é claramente definida, refletindo as complexidades do setor logístico. Os Models estabelecem a base, simbolizando entidades críticas como produtos e veículos. As Strategies de transporte e rastreio, adaptáveis através de injeções de dependência, mostram a flexibilidade necessária para o dinamismo do nosso negócio. Os Repositories se dedicam exclusivamente à interação com o banco de dados, mantendo essa lógica separada da camada de negócios.

Os Services lidam com a lógica de negócios, enquanto os Controllers fazem parte da camada de acesso, gerenciando a interação entre a lógica de negócios e as demais interfaces do sistema. Essa clara demarcação de responsabilidades não só atende às necessidades específicas da logística, mas também transmite com clareza o propósito do sistema. Cada componente do software se alinha perfeitamente a um aspecto específico do negócio, tornando a arquitetura intuitiva e eficaz. É uma representação fiel do domínio de logística, facilitando tanto o desenvolvimento quanto a operacionalização do sistema.

a nível de comparação, segue uma arquitetura simplista do que o laravel "impõe" para gerênciar esse domínio.
app/ │ ├── Http/ │ ├── Controllers/ │ │ ├── ProdutoController.php │ │ ├── TransporteController.php │ │ ├── RastreioController.php │ │ └── ArmazenamentoController.php │ │ │ ├── Middleware/ │ │ ├── AuthMiddleware.php │ │ ├── LoggingMiddleware.php │ │ └── ... │ │ │ ├── Requests/ │ │ ├── ProdutoRequest.php │ │ ├── TransporteRequest.php │ │ ├── RastreioRequest.php │ │ └── ArmazenamentoRequest.php │ │ │ └── ... │ ├── Models/ │ ├── Produto.php │ ├── Transporte.php │ ├── Rastreio.php │ └── ... │ └── ...

No caso acima, podemos notar uma arquitetura mais genérica, que pode atender ao domínio, mas ainda não temos uma noção clara do que essa transportadora faz em alguns aspectos.

Documentação viva

A Screaming Architecture, quando aplicada ao nosso domínio de logística, tornou a estrutura do código uma documentação viva e clara. Por exemplo, se tivermos diferentes tipos de veículos de transporte, como navios, caminhões e aviões, cada um com suas estratégias de rastreamento distintas, a arquitetura do código refletirá essa complexidade de maneira evidente.

Imagine que ao navegar pelo código-fonte, um novo desenvolvedor pode identificar facilmente as pastas e classes relacionadas a cada tipo de veículo e suas estratégias de rastreamento. Isso não elimina a necessidade de documentação externa, mas torna essa documentação mais sobre o domínio do negócio em sí do que sobre o que cada parte do código faz, pois a própria estrutura do código comunica como a aplicação lida com esses aspectos do negócio.

Essa clareza arquitetural não apenas simplifica o processo de integração de novos membros da equipe, mas também torna mais eficaz o trabalho contínuo de desenvolvimento, manutenção e expansão da aplicação.

Testabilidade

Quando a arquitetura "grita" o domínio, ela torna o teste de código mais simples e compreensível. Ainda no nosso contexto de logística e temos diferentes estratégias de rastreamento para navios, caminhões e aviões.

Com essa arquitetura clara, podemos facilmente criar testes para cada uma dessas estratégias. Por exemplo, podemos escrever um teste para garantir que a estratégia de rastreamento de navios funcione corretamente. Isso envolveria simular o comportamento de rastreamento de um navio em diferentes situações e verificar se os resultados estão corretos. Segue um exemplo abaixo:


<?php
use PHPUnit\Framework\TestCase;
use GuzzleHttp\Client;
use GuzzleHttp\Handler\MockHandler;
use GuzzleHttp\HandlerStack;
use GuzzleHttp\Psr7\Response;

class NavioRastreioStrategyTest extends TestCase
{
    public function testDeveRetornarCidadeEstadoLink()
    {
        $mockResponse = new Response(200, [], json_encode([
            'latitude' => 42.12345,
            'longitude' => -71.98765,
        ]));
        $mock = new MockHandler([$mockResponse]);
        $handlerStack = HandlerStack::create($mock);
        $httpClient = new Client(['handler' => $handlerStack]);

        $navio = $this->getMockBuilder(Navio::class)
            ->disableOriginalConstructor()
            ->getMock();

        $navioMock->codigo = 'COD123';
        $navioMock->tipo_mercadoria = 'AD234BC';
        /**http client é um parametro opcional
        é setado automaticamente quando uam strategy é chamada
        mas para tornar a class testavel ele pode mockar essa cliente
        **/
        $strategy = new RastreioStrategy($httpClient);
        // Automaticamente chama NavioRastreioStrategy
        $result = $strategy->rastrear($navio);

        $data = json_decode($result, true);

        $this->assertEquals('Exemplo Cidade', $result->cidade->nome);
        $this->assertEquals('Exemplo Estado', $result->estado->nome);
        $this->assertEquals('https://maps.google.com/?q=42.12345,-71.98765', $result->googleMaps->link);
    }
}

Nesse teste conseguimos testar a regra de négocio, é claro é um teste bem feliz que falharia provavelmente, mas a ideia central é como nossa arquitetura que grita tornou nosso caso de um uso tão óbvio a nossa aplicação que foi muito facil criar um teste para esse nosso subdomínio que é rastrear navios.

Conclusão

Usar uma arquitetura que claramente comunica os problemas que o software busca resolver é uma vantagem significativa para sistemas que visam longevidade. Embora possa haver preocupações futuras com a descontinuação do Laravel, não estamos considerando essa variável, pois é improvável.

As vantagens dessa abordagem incluem:

Documentação viva: A documentação do software se concentra no domínio do problema, tornando-a mais relevante e útil.
Testabilidade: A implementação de testes, incluindo o desenvolvimento orientado a testes, permite que o software seja atualizado facilmente a cada nova versão estável do framework.
Escalabilidade: Uma arquitetura gritante não apenas orienta os desenvolvedores sobre o que cada componente representa, mas também implicitamente indica como as coisas devem ser implementadas no futuro, facilitando a escalabilidade à medida que novos recursos são adicionados ao sistema.

Por fim: faça seu código ter personalidade