DEV Community: Nathalia Pavan

Live reload em Go com docker e compile daemon

Nathalia Pavan — Thu, 25 Apr 2024 21:13:55 +0000

Desenvolver aplicações em Go é bastante produtivo, principalmente quando conseguimos combinar ferramentas que automatizam tarefas ~~chatas~~ comuns de desenvolvimento. Neste artigo, vamos explorar como implementar o live reload em uma aplicação Go usando Docker e o pacote CompileDaemon.

Caso só tenha interesse no código, você pode encontrar o projeto no meu GitHub

O que é live reload?

O live reload é uma técnica que permite que as alterações no código sejam automaticamente refletidas na aplicação em execução, sem a necessidade de reiniciar manualmente o servidor. Isso é muito útil durante o desenvolvimento, pois podemos visualizar imediatamente o impacto das alterações realizadas no código.

O que é CompileDaemon?

O CompileDaemon automatiza a recompilação do código em projetos Go, eliminando a tediosa tarefa de reiniciar manualmente o servidor a cada modificação no código. Com ele, as alterações são instantaneamente refletidas na aplicação que está sendo executada, garantindo um processo de desenvolvimento mais dinâmico e eficiente. Ao combiná-lo com o Docker, criamos um ambiente de desenvolvimento onde as alterações são aplicadas sem interrupções, reduzindo o tédio e aumentando nossa produtividade.

Pré-requisitos

Antes de começarmos, certifique-se de ter as ferramentas abaixo instaladas em sua máquina:
Go
Docker
Docker-Compose

Configurando o Projeto

Vamos começar criando um novo projeto Go. Abra seu terminal e crie um diretório e navegue até ele:

mkdir go-live-reload-docker && cd go-live-reload-docker

Execute o seguinte comando para inicializar o módulo do Go e criar o arquivo go.mod:

go mod init go-live-reload-docker

Estrutura do Projeto

Crie os arquivos abaixo manualmente. A estrutura do projeto deve ser a seguinte:

go-live-reload-docker/
├── docker-compose.yml
├── Dockerfile.dev
├── go.mod
└── main.go

docker-compose.yml

Para simplificar o processo de construção e execução da nossa aplicação, vamos utilizar o Docker Compose.

version: "3"

services:
  app:
    container_name: go-live-reload
    build:
      context: .
      dockerfile: ./Dockerfile.dev
    ports:
      - 8080:8080
    volumes:
      - ./:/app

Este arquivo define um serviço chamado app que constrói a aplicação Go usando o arquivo Dockerfile.dev. Ele também mapeia a porta 8080 do contêiner para a porta 8080 do host, permitindo que a aplicação seja acessível localmente.

Dockerfile.dev

Este Dockerfile será usado apenas durante o desenvolvimento e incluirá o pacote CompileDaemon para habilitar o live reload. Aqui está o conteúdo do arquivo Dockerfile.dev:

FROM golang:latest

ENV PROJECT_DIR=/app \
    GO111MODULE=on \
    CGO_ENABLED=0

WORKDIR /app

RUN mkdir "/build"

COPY . .

RUN go get github.com/githubnemo/CompileDaemon

RUN go install github.com/githubnemo/CompileDaemon

ENTRYPOINT CompileDaemon -build="go build -o /build/app -buildvcs=false" -command="/build/app"

Este Dockerfile utiliza a imagem oficial do Go como base e define algumas variáveis de ambiente necessárias. Ele também instala o CompileDaemon e configura um ponto de entrada para executar nossa aplicação com live reload.

main.go

Nosso arquivo main.go contém uma simples aplicação HTTP que responde com uma mensagem. Aqui está o conteúdo do arquivo:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello, Nat!")
    })

    http.ListenAndServe(":8080", nil)
}

Executando a Aplicação

Agora que tudo está configurado, podemos construir e executar a aplicação com Docker. Basta executar os comandos na raiz do projeto:

docker-compose build
docker-compose up -d

Isso construirá a imagem Docker e iniciará o contêiner em segundo plano. Você pode validar a aplicação em seu navegador acessando: http://localhost:8080 🥳

Conclusão

Neste artigo, exploramos como implementar o live reload em uma aplicação Go usando Docker e CompileDaemon. O live reload acelera o ciclo de desenvolvimento, permitindo que os desenvolvedores visualizem instantaneamente as alterações feitas no código. Com o Docker, a configuração do ambiente de desenvolvimento é simplificada e a distribuição da aplicação é facilitada. Espero que este guia tenha sido útil e que você possa aplicar esses conceitos em seus próprios projetos, será um ótimo start pra sair do zero.

Até mais o/

Fontes

https://github.com/githubnemo/CompileDaemon
https://thegodev.com/live-reloading/
https://blog.logrocket.com/using-air-go-implement-live-reload/
https://harrk.dev/live-reloading-a-go-application-with-docker/
https://stackoverflow.com/a/41429055
https://www.youtube.com/watch?v=EoclvPzeD14&ab_channel=Aregularguy

Arquitetura hexagonal: a sinergia dos princípios de desenvolvimento e boas práticas

Nathalia Pavan — Thu, 11 Apr 2024 16:12:30 +0000

Venhamos e convenhamos, desenvolver uma API robusta e escalável nem sempre vai ser um mar de rosas. Em meio a muitas dúvidas, linguagens, frameworks e mais uma infinidade de opções e combinações, a escolha da arquitetura certa pode fazer toda a diferença. Recentemente, enquanto iniciava um projeto pessoal, escolhi um framework unopinionated pra ter mais liberdade e flexibilidade na construção da estrutura e adotei a Arquitetura Hexagonal (eu sempre me agradeço quando começo assim kkkkk).

A Arquitetura Hexagonal, também conhecida como Arquitetura Ports and Adapters, visa separar as preocupações da aplicação em diferentes camadas, facilitando a manutenção, testabilidade e escalabilidade do código. Ela se baseia na ideia de que as regras de negócio devem estar no centro da aplicação, isoladas das dependências externas, como frameworks e bibliotecas.

Durante o desenvolvimento, pude observar que os princípios do SOLID e os padrões de projeto (dentro do meu contexto) simplesmente surgiram de forma natural. Isso ocorre porque a arquitetura promove a separação de responsabilidades e a modularização do código, o que facilita a aplicação desses princípios e padrões.

Particularmente, eu sempre fiquei preocupada pensando se minhas implementações estavam seguindo a sopa de letrinhas 😂 Essa abordagem acaba aliviando a preocupação de estar aplicando ou não esses princípios, pois uma estrutura clara, bem definida e modularizada cria um ambiente propício para esses conceitos. Não é necessário gastar energia pensando se a estrutura está bem definida, pois a própria arquitetura guia o desenvolvimento nessa direção. Acaba virando uma consequência, sabe?

Outro benefício significativo e que estou curtindo muito é a facilitação dos testes unitários. A inversão de dependência promovida por esse tipo de arquietura permite que as dependências externas sejam substituídas por mocks durante os testes, facilitando a criação de casos de teste isolados. Sério, é só alegria kkkk

Em resumo, ao utilizar uma arquitetura bem definida, os conceitos de SOLID e os padrões de projeto se tornam consequências naturais do processo de desenvolvimento. Não precisamos fritar o cérebro pensando explicitamente neles a todo momento, pois eles estão embutidos na própria estrutura da aplicação, são complementares.

Ao iniciar um novo projeto, considere a Arquitetura Hexagonal como uma abordagem para alcançar uma base de código confiável e flexível. Isso vai permitir implementações muito mais intuitivas e fluidas, facilitando a manutenção e aprimoramento do código durante toda sua evolução. Você do futuro ficará muito grato, acredite

Diferença entre armazenamento em sessão e cache

Nathalia Pavan — Thu, 27 Jul 2023 11:39:39 +0000

Intro

Tanto a sessão quanto o cache são mecanismos de armazenamento temporário de dados em aplicações web, porém com propósitos diferentes.

Sessão

A sessão é uma forma de armazenar dados temporários do usuário durante uma sessão de navegação, ou seja, enquanto o usuário estiver interagindo com a aplicação. As informações armazenadas na sessão ficam disponíveis apenas para aquele usuário específico e são mantidas no servidor. As sessões são geralmente usadas para armazenar dados de login do usuário, carrinho de compras, preferências do usuário, entre outras informações que precisam ser mantidas enquanto o usuário está navegando na aplicação.

Cache

Já o cache é uma forma de armazenar dados temporários que são frequentemente acessados pela aplicação, com o objetivo de melhorar o desempenho e reduzir o tempo de resposta da aplicação. As informações armazenadas no cache são geralmente cópias de dados que foram buscados em algum lugar, como no banco de dados, e que são acessados com frequência. Quando a aplicação precisa dos dados novamente, ela verifica primeiro no cache antes de buscar nos locais originais. O cache pode ser armazenado no servidor ou no cliente, dependendo da configuração.

Exemplos para sessões

Aqui estão alguns exemplos de dados que são mais adequados para serem armazenados em sessão ao invés de cache:

Informações do usuário: Quando um usuário faz login em uma aplicação web, suas informações de autenticação, como nome de usuário e senha, devem ser armazenadas em sessão para que a aplicação possa lembrar quem é o usuário durante toda a sessão de navegação.

Carrinho de compras: Quando um usuário adiciona um produto ao carrinho de compras em uma loja virtual, as informações sobre o produto, como nome, preço e quantidade, devem ser armazenadas em sessão. Isso permite que o carrinho de compras acompanhe o usuário durante toda a sessão de navegação.

Preferências do usuário: Se uma aplicação web permite que o usuário personalize sua experiência, como selecionar uma cor de fundo ou um idioma preferido, essas preferências devem ser armazenadas em sessão. Isso garante que as preferências do usuário sejam mantidas enquanto ele estiver navegando na aplicação.

Dados sensíveis: Se uma aplicação web manipula dados sensíveis, como informações médicas ou financeiras, esses dados devem ser armazenados em sessão. Isso garante que apenas o usuário autenticado tenha acesso aos dados e que eles sejam destruídos quando a sessão do usuário terminar.

Esses são apenas alguns exemplos de dados que são mais adequados para serem armazenados em sessão ao invés de cache. Em geral, qualquer dado que seja específico do usuário e precise ser mantido apenas enquanto ele estiver navegando na aplicação deve ser armazenado em sessão.

Exemplos para cache

Aqui estão alguns exemplos de dados que são mais adequados para serem armazenados em cache ao invés de sessão:

Dados estáticos: Se uma aplicação web precisa exibir informações estáticas, como uma lista de países ou um conjunto de regras de negócio, esses dados podem ser armazenados em cache. Isso permite que a aplicação não precise buscar esses dados do banco de dados ou de outra fonte a cada requisição, melhorando assim o desempenho.

Resultados de consultas: Se uma aplicação web precisa realizar consultas frequentes em um banco de dados, os resultados dessas consultas podem ser armazenados em cache. Isso permite que a aplicação possa recuperar os resultados mais rapidamente nas próximas requisições, melhorando assim o desempenho.

Recursos de mídia: Se uma aplicação web precisa exibir imagens, vídeos ou outros recursos de mídia, esses recursos podem ser armazenados em cache. Isso permite que a aplicação não precise buscar esses recursos do servidor a cada requisição, melhorando assim o desempenho.

Dados compartilhados: Se uma aplicação web precisa compartilhar dados entre diferentes usuários, como uma lista de produtos disponíveis em uma loja virtual, esses dados podem ser armazenados em cache. Isso permite que a aplicação possa recuperar os dados mais rapidamente para cada usuário, melhorando assim o desempenho.

Esses são apenas alguns exemplos de dados que são mais adequados para serem armazenados em cache ao invés de sessão. Em geral, qualquer dado que seja comum a vários usuários ou que possa ser compartilhado entre requisições deve ser armazenado em cache.

Melhores práticas

Para armazenamento de sessões e caches, algumas boas práticas incluem:

Utilize um sistema de armazenamento seguro: escolha um sistema que utilize criptografia e que tenha proteção contra ataques.

Limite o tempo de vida das sessões e caches: estabeleça um tempo limite para a vida útil das sessões e caches, evitando que esses dados sejam armazenados por um tempo muito longo.

Escolha um sistema de armazenamento eficiente: selecione um sistema de armazenamento que seja capaz de lidar com o volume de tráfego do seu site ou aplicativo.

Faça backups regulares: mantenha backups das sessões e caches para evitar a perda de dados em caso de falhas do sistema.

Utilize o armazenamento em cache de forma inteligente: utilize o cache para armazenar dados estáticos que não mudam com frequência, como arquivos de imagens ou estilos CSS.

Limite o acesso às sessões e caches: estabeleça políticas de acesso que limitem quem pode acessar as sessões e caches do sistema.

Utilize um sistema de expiração de cache: utilize um sistema que defina o tempo de expiração do cache para evitar que ele armazene dados desatualizados.

Utilize técnicas de compressão de dados: utilize técnicas de compressão para reduzir o tamanho dos dados armazenados em sessões e caches, economizando espaço e melhorando o desempenho do sistema.

Prós e Contras

A melhor forma de armazenamento depende de vários fatores, como a frequência de atualização das configurações, o tempo necessário para buscar as informações da API externa e a sensibilidade das informações. Aqui estão alguns prós e contras de cada opção de armazenamento para ajudar na sua decisão.

Armazenamento em cache

Prós

Melhora o desempenho da aplicação, pois os dados ficam armazenados em memória e podem ser acessados rapidamente;
Reduz a carga na API externa, pois as informações são recuperadas do cache em vez de serem solicitadas repetidamente;
Pode ser configurado para expirar após um determinado período de tempo ou quando ocorrerem atualizações das configurações na API externa, garantindo que as informações estejam atualizadas;

Contras

Se as configurações forem atualizadas com frequência na API externa, o cache pode não ser eficaz e pode ser necessário atualizar as informações com mais frequência;
As informações podem não estar disponíveis imediatamente após uma atualização, já que as informações do cache precisam ser atualizadas manualmente ou quando expirarem.

Armazenamento em sessão

Prós

Garante que as informações sejam atualizadas em tempo real, já que as informações são buscadas da API externa a cada nova sessão;
Permite personalização individual para cada usuário;

Contras

Pode afetar o desempenho da aplicação se muitos usuários estiverem acessando a mesma API externa ao mesmo tempo;
Pode aumentar o tempo de carregamento da página para o usuário, já que as informações precisam ser buscadas da API externa a cada nova sessão;
Pode ser necessário um tempo de sessão muito curto para garantir que as informações sejam atualizadas com frequência, o que pode levar a uma experiência de usuário ruim.
Em geral, se as configurações são atualizadas com frequência na API externa e as informações são sensíveis, é melhor armazená-las em sessão para garantir que elas sejam sempre atualizadas. Se as informações não são sensíveis e as atualizações são raras, o armazenamento em cache pode ser mais adequado para melhorar o desempenho da aplicação. No entanto, é importante avaliar cuidadosamente cada caso e considerar os prós e contras antes de tomar uma decisão.

Conclusão

Em resumo, a principal diferença entre sessão e cache é que a sessão é usada para armazenar dados temporários do usuário durante uma sessão de navegação, enquanto o cache é usado para armazenar dados temporários frequentemente acessados pela aplicação, visando melhorar o desempenho.

É claro que isso aqui é apenas a lasquinha do iceberg, podemos aprofundar muito mais principalmente nas responsabilidades front e back.

Fontes

Aqui estão algumas fontes que você pode consultar para aprender mais sobre o armazenamento em sessão e cache:

Artigo de Alexander Nnakwue, disponível em LogRocket: Caching in Node.js to optimize app performance

Artigo de Joseph Chege, disponível em OpenReplayBlog: Understanding Sessions Management And Authentication With Node.Js

Artigo do Blog da AWS sobre cache em aplicações web, disponível em: https://aws.amazon.com/pt/caching/

Livro "High Performance Web Sites" de Steve Souders, que aborda técnicas de otimização de desempenho, incluindo o uso de cache: High Performance Web Sites [BOOK]

Aumentando a Produtividade com o Class-Validator no DTO do NestJS

Nathalia Pavan — Thu, 20 Jul 2023 23:26:39 +0000

Intro

No mundo acelerado do desenvolvimento de software, ser produtivo é crucial. Reduzir o tempo gasto na escrita de código repetitivo e de validação de dados pode ser uma tarefa desafiadora. Felizmente, o NestJS, um popular framework para construção de aplicações Node.js, oferece uma solução chic para esse problema - o class-validator. Neste artigo, exploraremos como o class-validator pode ser utilizado no DTO (Data Transfer Object) do NestJS, proporcionando uma maneira fácil e eficiente de validar os dados recebidos e, assim, aumentar sua produtividade.

O que é o Class-Validator

O class-validator é uma biblioteca de validação para classes em TypeScript. Ele fornece uma maneira declarativa de definir as regras de validação, eliminando a necessidade de escrever manualmente. Essa biblioteca é extremamente útil no contexto do NestJS, pois pode ser integrada perfeitamente aos DTOs usados para transferir dados entre as camadas da aplicação.

Github do projeto class-validator: https://github.com/typestack/class-validator

Esse pacote não é específico no NestJS, mas resolvi escrever esse artigo com o framework pois sou modinha e no momento ele está me fazendo muito feliz a cada descoberta kkkkkk Se você gostar tanto como eu, poderá implementar facilmente em qualquer aplicação escrita em Typescript.

Benefícios do Class-Validator no DTO do NestJS

Ao utilizar o class-validator no DTO do NestJS, teremos benefícios significativos:

Redução do código repetitivo: O class-validator permite definir as regras de validação diretamente nas propriedades do DTO, eliminando a necessidade de escrever funções de validação separadas para cada campo. Isso reduz drasticamente a quantidade de código repetitivo, tornando a manutenção e evolução do código muito mais fácil.
Melhor legibilidade: Ao declarar as regras de validação diretamente no DTO, o código se torna mais legível e autoexplicativo. As regras de validação ficam intimamente ligadas às propriedades correspondentes, tornando o código mais compreensível para outros desenvolvedores.
Validações pré-definidas: O class-validator oferece uma infinidade de validações pré-definidas, como validação de tipo, validação de tamanho mínimo/máximo, validação de formato de e-mail, entre outras. Essas validações podem ser facilmente aplicadas às propriedades do DTO com o uso de decoradores, poupando tempo e esforço.
Validações personalizadas: Além das validações pré-definidas, o class-validator permite a criação de validações personalizadas para atender às necessidades específicas da aplicação. Isso nos dá uma flexibilidade adicional para lidar com casos de validação mais complexos e específicos do domínio.

Exemplo prático

Vamos implementar um exemplo onde temos uma API de criação de postagens em um blog. Para criar uma nova postagem, precisamos garantir que o título seja uma string com no mínimo 5 caracteres e que o conteúdo da postagem não esteja vazio. Além disso, cada postagem pode ter uma lista de tags associadas a ela. Veja o exemplo:

import { Controller, Post, Body } from '@nestjs/common';
import { IsString, MinLength, IsNotEmpty, IsArray, ArrayNotEmpty, ArrayMaxSize, ArrayUnique } from 'class-validator';

class CreatePostDto {
  @IsString()
  @MinLength(5)
  title: string;

  @IsString()
  @IsNotEmpty()
  content: string;

  @IsArray()
  @ArrayNotEmpty()
  @ArrayMaxSize(5)
  @ArrayUnique()
  tags: string[];
}

@Controller('posts')
export class PostsController {
  @Post()
  createPost(@Body() createPostDto: CreatePostDto) {
    // Restante da lógica para criar a postagem
  }
}

No exemplo acima, temos o DTO CreatePostDto, que possui as propriedades title, content e tags. Utilizamos decorators específicos para cada propriedade:

Para o title, utilizamos:
@IsString() para garantir que seja uma string;
@MinLength(5) para exigir um mínimo de 5 caracteres no título.

Para o content, utilizamos:
@IsString() para garantir que seja uma string;
@IsNotEmpty() para garantir que não esteja vazio.

Para as tags, utilizamos uma série de decorators para validar a lista de tags:
@IsArray() para garantir que seja um array;
@ArrayNotEmpty() para garantir que não esteja vazio;
@ArrayMaxSize(5) para limitar o tamanho máximo do array em 5 elementos;
@ArrayUnique() para garantir que não haja valores duplicados na lista.

Assim, ao receber uma requisição no endpoint de criação de postagens, o NestJS aplicará as regras de validação definidas no DTO CreatePostDto. Se algum dos campos não atender às regras de validação, uma resposta de erro será retornada automaticamente.

O uso do Class Validator nesse contexto permite garantir que os dados de entrada atendam aos critérios estabelecidos para a criação de uma postagem, como o tamanho mínimo do título, a presença de conteúdo e a validação das tags associadas à postagem. Isso contribui para a integridade dos dados, a consistência das informações em sua API e felicidade do time hehe

Se você não estiver utilizando o Class Validator, precisará implementar as verificações de validação manualmente em seu código. Aqui está um exemplo de como você poderia realizar as mesmas validações sem o uso do Class Validator:

import { Controller, Post, Body, BadRequestException } from '@nestjs/common';

class CreatePostDto {
  title: string;
  content: string;
  tags: string[];
}

@Controller('posts')
export class PostsController {
  @Post()
  createPost(@Body() createPostDto: CreatePostDto) {
    if (!createPostDto.title || createPostDto.title.length < 5) {
      throw new BadRequestException('O título deve ser uma string com no mínimo 5 caracteres');
    }

    if (!createPostDto.content || createPostDto.content.trim() === '') {
      throw new BadRequestException('O conteúdo da postagem não pode estar vazio');
    }

    if (!createPostDto.tags || !Array.isArray(createPostDto.tags) || createPostDto.tags.length === 0) {
      throw new BadRequestException('A lista de tags deve ser um array não vazio');
    }

    const uniqueTags = Array.from(new Set(createPostDto.tags));
    if (uniqueTags.length !== createPostDto.tags.length) {
      throw new BadRequestException('A lista de tags não pode conter valores duplicados');
    }

    if (createPostDto.tags.length > 5) {
      throw new BadRequestException('A lista de tags não pode ter mais do que 5 elementos');
    }

    // Restante da lógica para criar a postagem
  }
}

Nesse exemplo, dentro do método createPost, você realiza manualmente as verificações de validação para o DTO CreatePostDto.

Para o campo title, você verifica se ele existe e se possui pelo menos 5 caracteres.
Para o campo content, você verifica se ele existe e se não está vazio, removendo espaços em branco extras.
Para o campo tags, você verifica se ele existe, é um array não vazio, não possui valores duplicados e tem no máximo 5 elementos.
Se alguma das verificações falhar, você pode lançar uma exceção adequada (como BadRequestException no NestJS) para indicar que a validação falhou e retornar uma resposta de erro.

Conclusão

Embora seja possível realizar as validações manualmente, o uso do Class Validator simplifica o processo e fornece uma abordagem declarativa e consistente para validar objetos. Com validações pré-definidas e personalizadas, ele também oferece recursos adicionais, como mensagens de erro customizadas e validação de objetos aninhados. Portanto, o Class Validator pode ser uma opção mais produtiva e conveniente para lidar com a validação em suas APIs.

Espero que esse singelo artigo tenha demonstrado como o uso do class-validator no DTO do NestJS pode melhorar a produtividade e facilitar suas implementações no dia a dia. Ao utilizar essa abordagem em seus projetos, você estará agilizando o desenvolvimento e garantindo a integridade dos dados recebidos. Experimente em seu próximo projeto!

Obrigada por ler até aqui :D

Initial Commit

Nathalia Pavan — Wed, 07 Oct 2020 03:16:18 +0000

Hello World!