DEV Community: Natanael Alves

Implementando MongoDB no Symfony

Natanael Alves — Sat, 01 Feb 2025 19:03:33 +0000

Eaí! Estava estudando mais sobre NoSQL com o MongoDB e decidi implementar o Mongo como banco de dados na API de um projeto que eu havia feito anteriormente com o Symfony.

Explicando rapidamente o projeto: é um compartilhador de arquivos. O usuário envia um arquivo e recebe um link de compartilhamento. Assim, qualquer pessoa com acesso a esse link pode visualizar o arquivo.

Nesse fluxo do projeto, o Mongo será utilizado para armazenar dados importantes do arquivo enviado pelo usuário, como id, nome, extensão e data de upload. Quando alguém acessar o link de compartilhamento, a API poderá recuperar o arquivo do serviço onde está armazenado (no caso, o Cloudflare R2) e retornar o arquivo correto para o usuário.

Requisitos

Antes de trabalhar com o Mongo no projeto, precisamos preparar o PHP para dar suporte ao Mongo. Para isso, a própria documentação do PHP tem instruções de como fazer isso: https://www.php.net/manual/en/mongodb.installation.php

Também precisamos de um servidor com o Mongo rodando. Existem várias formas de obter isso, e eu utilizei um serviço do próprio Mongo chamado MongoDB Atlas Cluster, que possui um tier gratuito para testes.

Importante

A implementação do Mongo em um projeto Symfony é bem simples, mas existem algumas considerações importantes:

Não existe mais ORM, agora é ODM (sigla para Object-Document Mapper)
Por isso, não existe EntityManager, agora é DocumentManager
Enfim, não existem mais Entidades, agora são Documentos, assim, criamos os documentos na pasta src/Document

Implementação

Agora sim, vamos para a implementação.

Instale o módulo do mongo no projeto

composer require doctrine/mongodb-odm-bundle
# Do you want to execute this recipe? 'yes'

Em config/packages/doctrine_mongodb.yaml, apague tudo e cole

doctrine_mongodb:
  auto_generate_proxy_classes: true
  auto_generate_hydrator_classes: true
  connections:
    default:
      server: "%env(resolve:MONGODB_URL)%"
  default_database: "%env(resolve:MONGODB_DB)%"
  document_managers:
    default:
      auto_mapping: true
      mappings:
        App:
          dir: "%kernel.project_dir%/src/Document"
          mapping: true
          type: attribute
          prefix: 'App\Document'
          is_bundle: false
          alias: App

Crie as variáveis de ambiente MONGODB_URL e MONGODB_DB, depois coloque respectivamente a conexão com seu servidor MongoDB e o nome do Database que você criou para o projeto. Também comentei a conexão do sqlite que havia antes.

Crie os documentos do seu projeto. É bem parecido com criar uma entidade, exceto que:

Invés de ORM é ODM
Invés de "table" é "colletion"
Invés de "Entity" é "Document"
Invés de "Column" é "Field"

Meu exemplo:

<?php

namespace App\Document;

use Doctrine\ODM\MongoDB\Mapping\Annotations as ODM;

#[ODM\Document(collection: 'files')]
class File
{
  #[ODM\Id]
  public ?string $id = null;

  public function __construct(
      #[ODM\Field]
      private ?string $name = null,
      #[ODM\Field]
      private ?int $size = null,
      #[ODM\Field]
      private ?string $type = null,
      #[ODM\Field]
      private ?string $key = null,
  ) {
  }

  public function getId(): ?string
  {
      return $this->id;
  }
}

Crie o repository do documento

<?php

namespace App\Repository;

use App\Document\File;
use Doctrine\Bundle\MongoDBBundle\ManagerRegistry;
use Doctrine\Bundle\MongoDBBundle\Repository\ServiceDocumentRepository;

class FileRepository extends ServiceDocumentRepository
{
    public function __construct(ManagerRegistry $registry)
    {
        parent::__construct($registry, File::class);
    }

    public function add(File $entity): File
    {
        $this->getDocumentManager()->persist($entity);

        $this->getDocumentManager()->flush();

        return $entity;
    }
}

Onde utilizava App\Entity\File troque para App\Document\File
A utilização do document para inserir, atualizar etc. é a mesma como era com as entidades. Pode ver um exemplo no método upload do FileController:
```
// ...
$file = new File($fileDTO->name, $fileDTO->size, $fileDTO->type, $fileKey);
$file = $this->fileRepository->add($file);
```
Agora é só testar

Conclusão

Decidi utilizar o Mongo neste projeto mais por estudo. Tanto as tecnologias SQL quanto NoSQL serviriam para este projeto. No entanto, cada caso é um caso. É necessário avaliar qual tipo de banco é mais adequado para resolver o problema em questão. Às vezes os bancos relacionais são a opção certa, outras vezes armazenar em documentos é melhor. DEPENDE.

Minha experiência com Symfony e Angular

Natanael Alves — Sun, 26 Jan 2025 13:56:17 +0000

Há algum tempo, tenho feito um ciclo de estudos para conhecer ferramentas além das do meu dia a dia. Nesse processo, estou me familiarizando com o framework Symfony do PHP e estudando o framework Angular para front-end, além de outras tecnologias.

Essas duas ferramentas me chamaram muito a atenção pois, apesar de compartilharem vários conceitos com o Laravel e o Vue (minha stack atual), as preocupações durante o desenvolvimento são um pouco diferentes.
Um exemplo para mim é que no Symfony senti uma necessidade maior de aplicar os princípios do SOLID (principalmente o "D") do que no Laravel. Isso não é necessariamente ruim — pelo contrário. Enquanto no Laravel muitos processos são abstraídos a ponto de parecerem "mágicos", no Symfony percebi que tenho mais controle sobre a aplicação. Como sou eu quem cria a estrutura do projeto, sei exatamente o que cada método faz e como faz.

No Angular, apesar de achar verboso, utilizar o paradigma Orientado à Objetos permitiu que a minha imersão no framework foi mais ágil, pois só precisa declarar as propriedades e métodos que preciso na classe e usar; se precisar algum comportamento diferente, basta adicionar um decorator que resolve. Mas não que a abordagem de outros frameworks sejam ruim.

Enfim, essa é minha perspectiva após sair da minha “bolha” e experimentar ferramentas novas além das que estou habituado. Estou estudando também sobre outro assuntos, como mensageria, NoSQL, observalidade… está sendo uma experiência dahora.

Quatro palavras da mensageria

Natanael Alves — Sun, 26 Jan 2025 13:46:11 +0000

As quatro palavras fundamentais quando falamos de mensageria são: Producer, Exchange, Queue e Consumer.

Para facilitar a compreensão, vamos usar um exemplo real de e-commerce, que envolve vários serviços como recebimento de pedidos, processamento de pagamentos, atualização de estoque, notificação ao cliente e logística de entregas.

Producer:

É quem inicia a comunicação entre os serviços. No nosso exemplo, tudo começa com o pedido do cliente, então nosso producer é a API que recebe esses pedidos. Ao receber um pedido, o producer envia uma mensagem para nossa Exchange com todos os dados necessários para os outros serviços. Conforme recebe mais pedidos, a API continua adicionando mensagens na Exchange.

Exchange:

É como uma fila particular de mensagens do producer, responsável por direcionar as mensagens para o destino correto. O producer adiciona mensagens com os dados de cada pedido nessa fila. A Exchange, seguindo o esquema FIFO (First In, First Out), encaminha essas mensagens para determinadas Queues — outras filas com propósito diferente. A Exchange pode ter diferentes tipos, o que altera sua forma de distribuir as mensagens.

Queue:

Assim como a Exchange, a Queue recebe mensagens — especificamente aquelas que a Exchange direcionou, contendo os dados dos pedidos. Seu propósito é armazenar essas mensagens para que os Consumers conectados possam obtê-las.

Consumer:

O consumer obtém as mensagens da Queue seguindo o FIFO, acessa os dados do pedido e os processa. Em nosso e-commerce, exemplos de consumers são: o serviço que processa pagamentos conforme o valor do pedido, o que atualiza o estoque baseado na quantidade, e o que notifica o cliente. Esses serviços processam os dados sem prender o usuário em telas de carregamento, permitindo que ele continue fazendo outros pedidos.

Um detalhe importante: um Consumer também pode atuar como Producer e vice-versa. Por exemplo, o serviço de pagamento pode enviar mensagens para outros sistemas informando se o pagamento foi bem-sucedido. Os outros serviços podem então cancelar ou desfazer ações anteriores, e a API de pedidos pode retornar uma mensagem sobre a falha no pagamento.

Exemplo do esquema de mensagens:

Vazou a senha na linha de comando?

Natanael Alves — Wed, 16 Oct 2024 16:09:01 +0000

Relato
Estava eu acessando o terminal do servidor de produção e - sem querer querendo - executei um comando junto com uma senha de acesso que não deveria estar ali quando executasse esse comando. Agora, a senha estava exposta no histórico de comando do terminal. Felizmente encontrei uma forma de resolver isso e vou compartilhar para caso um dia, quem sabe, você precisar por algum motivo - mas ninguém precisar sabe que um dia você precisou fazer isso, certo?

Como fazer

Primeiro, você executa o comando history para saber em qual linha o comando a ser apagado está. Digamos que o comando está na linha 1234.
Agora, só precisamos usar a flag -d do comando history para apagar uma linha específica do histórico, assim:

history -d 1234

Para garanti que a linha foi apagada do histórico, usamos a flag -w para atualizar o histórico, assim:

history -w

Se precisar de uma solução mais drástica para deletar um intervalo de linhas, você pode utilizar um for loop:

for i in {[fim]..[início]}; do history -d $i; done

Se precisa de algo ainda mais bruto, você pode apagar todo o histórico do terminal com a flag -c

history -c

Se quiser uma segurança a mais, no aquivo de configurações do terminal, você pode informar que comandos com certas palavras-chaves não vão ser registrado no histórico de comando. No meu caso, o arquivo de configs é o .bashrc e nele eu disse que qualquer comando que tenha o termo "senha" ou "pass..." devem ser ignorados do histórico. Para isso, precisa apenas adicionar o seguinte trecho no arquivo de configuração:

export HISTIGNORE="*senha*:pass*:*history*-d*"

O valor atribuído à HISTIGNORE é uma expressão regular e você pode adicionar várias separando-as por ":" .

Conclusão
Espero que isso nunca aconteça com você, mas, se um dia acontecer, está aí a solução e ninguém além de você vai saber disso hehehe. Mas tome cuidado pra não precisa usar essa artimanha de novo, blz?. Espero que tenham gostado dessa e até a próxima.

Execute processos no linux sem interrupções com o nohup

Natanael Alves — Tue, 24 Sep 2024 12:11:01 +0000

Relato
Certo dia, já próximo ao fim do expediente, chegou uma demanda de um cliente solicitando o backup de 4 anos de dados dele registrados em um dos sistemas da empresa. Inicialmente, pensei em gerar um dump dos dados das tabelas e estava funcionando bem, exceto, pelo fato de que estava demorando muito pra terminar o processo e eu precisava ir embora, mas no outro dia esse backup devia ser entregue sem falta. E fui para resolver isso que encontrei o comando nohup.

O que é o nohup?
É um comando no Linux que permite que você execute processos sem encerrá-los quando você fecha o terminal ou faz logout - o que era meu caso, pois estava acessando o servidor via SSH.

Sintaxe

nohup [seu comando] &

O nohup joga o comando para segundo plano e o & joga a execução do nohup para segundo plano para liberar seu terminal. O output e os erros do seu comando, por padrão, vão ser escritos num arquivo chamado nohup.out no diretório atual; porém, você pode especificar arquivos diferentes - veremos em frente.

Caso de uso
No meu caso, era um projeto Laravel e que criei um comando artisan para gerar o backup do cliente. Então, acessei o servidor via SSH, executei meu comando artisan com o nohup e fechei a sessão. Ficou assim:

nohup php artisan generateClientBackup &

Output do comando
Meu comando mostrava no terminal quando terminava o dump de uma tabela, mas, como estava em segundo plano, eu perdia esse feedback. Pra resolver isso, eu redirecionei esses outputs do comando para um arquivo específico e o comando ficou o seguinte:

nohup php artisan generateClientBackup > output.log 2>$1 &

Obs.: em alguns caso, o comando podia dar erro e eu precisava desse feedback também. Então, mandei que os erros fossem para output.log usando 2>$1, onde "2" representa a saída de erro e "$1" representa o arquivo output.log - mas pode-se especificar um nome para o arquivo de erro trocando $1 pelo nome do arquivo.

Cancelar processo em segundo plano
Se por algum motivo você precisar cancelar o processo depois de ter executado, pode usar o comando kill informando o PID (Process ID) do processo:

Obtém o ID do processo:

ps aux | grep [seu comando]

Depois de encontrar o PID, use o comando:

kill [PID]

Bônus: seu comando espera um prompt?

echo "valor_que_voce_quer_informar" | nohup php artisan blablabla > output.log 2>&1 &

O valor escrito pelo comando echo serve como valor padrão para o prompt solicitado pelo seu comando.

Conclusão
Com isso, você pode executar processos demorados sem precisar se preocupar em deixar seu terminal aberto o tempo todo. Mas ainda assim tem que ficar de olho se seu comando não retornou algum erro. Espero que tenham gostado dessa e até a próxima.

Enums e lang no Laravel

Natanael Alves — Tue, 17 Sep 2024 08:08:25 +0000

Relato
Num projeto que trabalhei, havia um campo de select que tinha valores definidos e que não iriam ter alteração. Então, para listar os itens desse select, resolvi criar uma classe de enumeração e daí descrever esse valores. Porém, o projeto precisava dar suporte às linguagens inglês e espanhol, e o texto das opções do select precisavam de adaptar a isso sem perder a referência do respectivo item do enum. Ou seja, se eu selecionasse o item "cavalo", eu precisava que o sistema soubesse que esse item ainda é "cavalo" mesmo ele aparecendo como "horse" ou "caballo". Foi pra manter a integridades dos dados que criei a seguinte estrutura integrando o enum e o lang no projeto.

O que são os Enums
Uma breve introdução. A partir da versão 8.1 do PHP, foi introduzida uma classe especial para enumerar valores. Na prática, quer dizer que podemos criar uma classe que os valores das suas propriedades serão constantes. Um exemplo são status, pois se deixar livre provavelmente ao longo do código vai ter um status "ativo", outro "Ativo", outro "Active" slá. Mas seu amarra o status a um enum e usar o enum invés de digitar a string, terei a certeza que em qualquer lugar do código o valor vai ser sempre aquele que está no enum.

enum Status
{
    case ATIVO = "ativo";
    case INATIVO = "inativo";
    case PENDENTE = "pendente";
}

Enums e o lang
Como o enum é uma classe, eu posso criar métodos para a minha classe normalmente. Então, criei o método display() que será o responsável por tratar a visualização do meu valor do enum adaptando-o para o idioma que o usuário está usando, porém, sem alterar o valor original no meu item do enum. Ou seja, para o usuário, o status aparece "Pendiente", ou "Pending", ou "Pendente"; mas no banco está salvo somente como "pendente" - que é o valor original e por ele eu consigo pegar o meu item do enum, e desse item usar o método display que mostrar ele traduzido para o usuário.
Mas antes de mostrar o exemplo, uma introdução ao lang do Laravel. O lang é uma pasta na raiz do projeto para armazenar traduções que o seu projeto vai dar suporte. Cada idioma tem uma pasta, e nessa pasta arquivos para contextos de traduções. Nesses arquivos tem um array, onde a chave é uma representação da palavra e o valor é a tradução para o respectivo idioma.

Configurando o método display
Na pasta lang, vou criar um arquivo status.php para cada pasta de idioma com o seguinte array:

<?php
[
    Status::ATIVO->value => "Ativo",
    Status::INATIVO->value => "Inativo",
    Status::PENDENTE->value => "Pendente",
];

Corrijo os valores do array para a respectiva traduções do respectivo idioma.
E meu método display vai buscar a tradução do item do enum nesses arquivos status.php e retornar esse valor.

public function display(): string
{
    return trans('status.'.$this->value);
}

Exemplo de uso:

// EN
echo Status::ATIVO->display(); // Active

// PT_BR
echo Status::INATIVO->display(); // Inativo

// ES
echo Status::PENDENTE->display(); // Pediente

Conclusão
Com isso, eu garanto que meu valor do enum continue constante no meu código, mas ele se adapta ao idioma do usuário usando o método display sem perder a integridade dos dados. Além também de ficar flexível caso eu adicione um novo idioma ao sistema. Espero que tenham gostado dessa e até a próxima.