DEV Community: Mateus Vinícius

Ponteiros, stack e heap em Go

Mateus Vinícius — Sun, 03 Mar 2024 21:20:56 +0000

Pointers

Ponteiros são variáveis cujo valor é um endereço na memória, e esse endereço pode conter qualquer tipo de valor - uma string, um int, uma struct e etc.

A sintaxe básica de ponteiros em Go é relativamente simples, mas iremos entrar nos detalhes ao decorrer do texto:

// declarando uma variável do tipo int
var foo int = 3 

// exibindo na tela o endereço na memória da variável "foo"
// O resultado será algo como: 0xc000110010
fmt.Println(&foo) 

// declarando uma variável do tipo ponteiro
// cujo endereço apontado é um variável do tipo int.
// estamos apontando para o endereço da variável foo
var bar *int = &foo

// exibindo na tela o valor da variável "bar", que é um endereço na memória. 
// o resultado será o mesmo do Println anterior
// já que ambos apontam para o mesmo endereço na memória
fmt.Println(bar) 

// exibindo na tela o valor original contido no endereço
// Resultado: 3
fmt.Println(*bar)

Primeiro é importante diferenciar os diferentes usos do operador *, também conhecido como star operator.

Star operator num tipo é chamado de pointer type, e indica que aquela variável é o ponteiro para algo - como int, string etc -, esse algo é chamado de base. Por exemplo, o código abaixo indica que a variável baz é um pointer type de base string:

var string name = "Matt"
var baz *string = &name

Já se o uso do star operator seguido de uma variável é uma forma de obter o valor original do endereço na memória que o ponteiro está salvando. Chamamos isso de dereferencing.

var name string = "Matt"
var baz *string = &name
fmt.Println(*baz) // Resultado: "Matt"

Apesar da sintaxe simples, o uso apropriado de ponteiros no Go pode se tornar complexo devido ao fato de não ser sempre claro qual será o comportamento do compilador na alocação de memória. Basicamente um ponteiro pode ser salvo na stack ou no heap, e a escolha de um ou outro é muitas vezes implícita.

Stack

Stack - ou pilha - é uma estrutura de dado que salva cada bloco de código que é executado numa goroutine, de forma isolada e ordenada, e cada bloco é chamado de frame. Exemplo, no código abaixo temos uma função main, que chama uma função greetings, que chama a função fmt.Println:

package main

import "fmt"

func main() {
    name := "Matt"
    greetings(name)
}

func greetings(name string) {
    fmt.Println(name)
}

Executando o código, esse seria o comportamento da stack:

Após a execução do frame terminar, a stack automaticamente se limpa sozinha, jogando fora toda a memória alocada em cada frame e finalizando nosso programa.

Normalmente frames não podem acessar endereços na memória de fora dele, então se um ponteiro for criado num frame e apenas acessado nesse frame, aquela memória normalmente será alocada dentro da stack, no próprio frame, e será zerada no momento em que esse frame terminar a sua execução e for removido da stack. O mesmo vale caso o ponteiro seja criado num frame e passado pra baixo na execução dos frames filhos, por exemplo no código abaixo:

package main

import "fmt"

func main() {
    name := "Matt"
    greetings(&name)
}

func greetings(name *string) {
    fmt.Println(*name)
}

A função greetings recebe um ponteiro que aponta para o endereço na memória da variável name, e essa variável está salva dentro do frame main, que não será removido da stack até a função greetings e fmt.Println terminarem sua execução, então é seguro manter a variável salva lá.

Importante mencionar que, caso a variável passada não seja um ponteiro e sim uma string, por exemplo, o valor é copiado ao passar de um frame para o outro, pois, como dito anteriormente, frames normalmente não podem acessar memória de fora do seu próprio bloco de execução.

Dado o comportamento de self cleaning, ou seja, de remover da stack o frame assim que ele finaliza sua execução, a stack não precisa de ajuda do garbage collector, o que melhora a performance do código.

Heap

Mas existem situações em que não seria seguro manter a memória salva no próprio frame, pois ele pode ser acessado de fora mesmo após o frame ser removido da stack, o que causaria a perda do seu valor, retornando apenas nil. Por exemplo, no trecho abaixo:

package main

import "fmt"

func main() {
    name := createName()
    greetings(name)
}

func createName() *string {
    name := "Matt"
    return &name
}

func greetings(name *string) {
    fmt.Println(*name)
}

A função createName cria o ponteiro que aponta para a variável name, mas ao finalizar sua execução a função greetings ainda precisa acessar esse valor. O comportamento da stack, nesse caso, seria esse:

Mas se o frame da função createName foi removido da stack após sua execução, o que significa que toda a memória foi zerada, como a função greetings ainda assim conseguiu acessá-lo? A resposta é que, nesse caso, a memória não foi alocada dentro do frame na stack, mas sim num lugar de fora, chamado heap.

O heap é o local que guarda essas memórias alocadas que precisam ser compartilhadas entre frames e até entre stacks, sem que sejam apagadas após a execução do frame que as criou.

Dado esse comportamento pode parecer muito tentador usar apenas memória alocada no heap, mas, como não há o comportamento de self cleaning, o heap precisa de ajuda do garbage collector do Go, e isso têm um custo computacional, criando cada vez mais latência no programa.

Mas nem sempre a alocação em memória do Go é tão previsível assim, por isso destaquei o "normalmente" ao descrever os comportamentos de alocação na stack e no heap, mas isso será melhor explorado num momento futuro. Por ora basta entender que cada tipo de alocação tem suas vantagens e desvantagens, e que usar ponteiros, apesar de parecer simples, pode trazer certa complexidade e custos por trás.

Channels por baixo dos panos

Mateus Vinícius — Sat, 25 Nov 2023 19:31:20 +0000

Channels são canais de comunicação e sincronização entre goroutines. A comunicação é feita através do envio de dados entre goroutines e a sincronização é feita pausando e retomando o processamento de uma goroutine quando necessário.

Podemos criar uma nova channel, com o seguinte código:

ch := make(chan Task, 3)

O tipo chan Task significa que estamos criando uma channel que envia e recebe um dado de tipo Task, enquanto o parâmetro 3 representa a quantidade de dados que a channel pode guardar ao mesmo tempo na sua fila, iremos explorar o que isso significa muito em breve.

Por debaixo dos panos o valor da variável ch passa a ser um ponteiro para uma estrutura de dados chamada hchan, que é nada mais do que uma struct com 4 propriedades principais: buffer, sendx, recvx e lock. Cada propriedade possui um papel fundamental no funcionamento das channels.

O buffer é uma fila que guarda cópias dos dados enviados para a channel. Quando uma goroutine envia um dado para uma channel, o buffer armazena e mantém um cópia desse dado - chamamos esse processo de enqueue - e, quando uma goroutine recebe esse dado, ele é removido do buffer e uma cópia fica com a goroutine que o consome - esse processo chamamos de dequeue.

Sendx representa o índice do dado sendo enviado para a fila. No nosso exemplo acima de uma fila com 3 elementos, se uma goroutine envia o primeiro dado para a channel o sendx passa a ser 1, se envia mais outro o sendx passa a ser 2, se envia mais outro o sendx passa a ser...0. Essa é a definição de uma fila circular, pois o último elemento se conecta ao primeiro. O valor do sendx seria zero porque o próximo elemento depois do terceiro é o primeiro, portanto se a fila está cheia - já possui 3 elementos - e eventualmente o primeiro elemento da fila for removido, quando uma goroutine enviar para a channel um novo dado, ele ficará guardado no índice 1 - e ai o valor do sendx volta a ser 1 - e assim sucessivamente, de forma circular.

Recvx funciona da mesma forma que a propriedade sendx, mas é referente ao índice do dado sendo recebido por uma goroutine.

Lock consiste em um mutex, que é um tipo primitivo de dado usado para evitar race condition - ou seja, evitar que diferentes threads manipulem o mesmo dado compartilhado, no caso a channel, de foma simultânea, causando comportamentos inesperados ou corrupção de dados. Se duas goroutines tentarem fazem operações simultâneas na mesma channel apenas uma conseguirá o lock, e a outra deverá aguardar o unlock da primeira para realizar sua própria operação.

Podemos visualizar o fluxo de funcionamento de uma channel enquanto fila circular com o diagram criado por @akankshadokania.

Um ponto importante que pode ser levantado é: Já que a fila circular possui um tamanho fixo de quantidade de elementos que podem ser salvos ao mesmo tempo, o que acontece se uma goroutine enviar mais um dado para a channel que já está cheia?

Usando nossa channel de 3 elementos como exemplo, imaginando que ele já possui 3 Tasks no buffer, o sendx e recvx seriam ambos 0 e o runtime do Go, sabendo que o índice 0 do buffer ainda está ocupado, bloquearia a execução da goroutine que tentou enviar o dado para a channel e apenas desbloquearia quando o recvx passasse a ser 1, ou seja, quando o primeiro elemento fosse removido da fila, assim permitindo o envio do dado para a channel.

Portanto channels são uma ferramenta poderosa por possuir essas características interessantes: São goroutine-safe, ou seja, possuem a capacidade de lidar com múltiplas goroutines sem levar a problemas de race condition; Possuem capacidade de salvar dados, como vimos no ponto sobre a propriedade buffer; Possui semântica FIFO - First In First Out -, ou seja, a fila do buffer recebe e envia os dados em ordem; Podem enviar dados entre goroutines e podem bloquear/desbloquear a execução de goroutines, dependendo da situação.

Goroutines por baixo dos panos

Mateus Vinícius — Sat, 11 Nov 2023 21:54:33 +0000

Goroutine é a implementa do Go de uma corrotina, que é uma solução que existe em diversas linguagens de programação e tem como objetivo criar concorrência gerenciando a execução de funções, de forma que cada função seja executada por uma thread do sistema operacional.

A primeira vista, esse conceito pode parecer similar a uma thread pool, que é um design pattern que consiste em múltiplas threads do sistema operacional e uma fila de processamento, e funciona basicamente da seguinte forma: o nosso programa envia para a fila execuções que devem ser processadas e deixa as threads do sistema operacional atuarem como consumers, puxando esses itens da fila e os processando de forma concorrente. Pense numa thread pool como um load balancer de threads.

Entretanto, Goroutines são diferentes de uma thread pool, e os motivos ficarão claros ao longo do texto, mas podemos adicionar que, por exemplo, cada goroutine não corresponde necessariamente a uma thread real do sistema operacional - inclusive duas goroutines podem eventualmente ser processadas na mesma thread -, e não há um caminho direto entre o que precisa ser processado e está na fila e as threads que irão processar, todo esse percurso é mediado pela estratégia do runtime do Go.

Ao executarmos um programa que cria várias goroutines, o runtime do Go, através do seu scheduler, precisa gerenciar quando e em qual thread essas goroutines vão ser processadas.

Imaginemos que, na nossa execução, temos 2 threads do sistema operacional, o scheduler do Go então vai redirecionar nossas goroutines para serem processadas em uma dessas threads. Num cenário de 4 goroutines para serem processadas pelas 2 threads, o scheduler redireciona a goroutine A e B para ser processada pela thread 1, e a goroutine C e D para ser processada pela thread 2.

E ao contrário de uma thread pool o scheduler do Go não é passivo, ele pode decidir pausar a execução de uma função numa thread, caso haja um bloqueio, por exemplo, e redirecionar essa execução para outa thread, enquanto as threads de uma pool apenas consomem e executam todo pedaço de programa chega na fila. Existe muito mais estratégia e coordenação em tempo de execução numa goroutine do que existe numa thread pool crua.

Goroutine é uma ferramenta poderosíssima do Go porque permite a implementação de concorrência de forma rápida e leve, porque conta com um scheduler que gerencia, como um maestro, em qual thread e quando um pedaço do programa será executado, e pelo fato de cada goroutine criada não necessariamente corresponder a criação de uma nova thread do sistema operacional, o que as torna muito menos custosa e mais fáceis de serem criadas, já que existem numa camada de permissão bem acima das threads do kernel.

Não use funções puras com Go

Mateus Vinícius — Sun, 22 Oct 2023 15:44:03 +0000

Um mantra muito comum no mundo do desenvolvimento é que funções puras são sempre melhores, mas isso nem sempre é verdade, pelo menos não no ecossistema do Go, e esse é um padrão amplamente adotado pela comunidade.

O que é uma função pura?

Uma função pura é aquela que segue princípios de determinismo e imutabilidade. Ela retorna o mesmo resultado para o mesmo conjunto de argumentos de entrada, sem depender de variáveis externas, tornando o comportamento previsível e fácil de entender. Além disso, não modifica o estado de variáveis ou objetos fora de seu escopo, que é o chamado side effect, mas sim cria e retorna um novo valor com base em seus argumentos, evitando efeitos colaterais indesejados.

Qual o padrão usado no lugar das funções puras?

Go te permite acessar ponteiros diretamente, assim como linguagens low-level como C e C++, e se tornou um padrão da comunidade dar preferência a funções que recebem como argumento um ponteiro (isto é, o endereço na memória) para algum valor, como uma struct, e manipular esse valor diretamente dentro da função.

Um exemplo desse padrão pode ser visto no GORM, lib de ORM muito popular.

package main

import (
  "gorm.io/gorm"
  "gorm.io/driver/sqlite"
)

type Product struct {
  gorm.Model
  Code  string
  Price uint
}

func main() {
  db, err := gorm.Open(sqlite.Open("test.db"), &gorm.Config{})
  if err != nil {
    panic("failed to connect database")
  }

  // Migrate the schema
  db.AutoMigrate(&Product{})

  product := Product{
    Code: "D42", 
    Price: 100
  }
  // Create
  db.Create(&product)

  // Read
  db.First(&product, 1) // find product with integer primary key
  db.First(&product, "code = ?", "D42") // find product with code D42

  // Update - update product's price to 200
  db.Model(&product).Update("Price", 200)
  // Update - update multiple fields
  db.Model(&product).Updates(Product{Price: 200, Code: "F42"}) // non-zero fields
  db.Model(&product).Updates(map[string]interface{}{"Price": 200, "Code": "F42"})

  // Delete - delete product
  db.Delete(&product, 1)
}

A variável product é uma struct cujo ponteiro é passado como argumento nas funções de update, create e etc, dessa forma, o retorno da operação já é preenchido dentro desse variável. No caso do create, por exemplo, a variável product passaria a ter todas as propriedades do registro que foi criado (ex: um uuid gerado automaticamente pelo banco de dados). No caso do update, o valor da struct é modificado para corresponde aos novos valores da operação de atualização.

O padrão do ecossistema do Go é reaproveitar variáveis declaradas no mesmo escopo, por isso a preferência no uso de ponteiros.

Qual a vantagem de usar funções impuras em Go?

Em suma, performance. Uma função pura retorna uma nova struct contendo as propriedades do registro de cada uma das operações, então o create criaria uma nova struct contendo os dados criados, o update criaria uma nova struct contendo os dados modificados e assim sucessivamente.

func GetUserBalance(c *gin.Context) {
    id := c.Param("id")

    if id == "" {
        sendError(c, http.StatusBadRequest, "missing id parameter")
        return
    }

    user, err := getUser(id, db.Client)

    if err != nil {
        sendError(c, http.StatusInternalServerError, err.Error())
        return
    }

    sendSuccess(c, http.StatusOK, gin.H{"balance": user.Wallet.Balance})
}

func getUser(id string, client *gorm.DB) (schema.User, error) {
    user := schema.User{}

    if err := client.Preload("Wallet").Where("id = ?", id).First(&user).Error; err != nil {
        return user, err
    }

    return user, nil
}

No exemplo acima getUser é uma função pura que, dado um id e um client do banco, retorna sempre uma nova cópia da struct schema.User{}.

Se cada operações gera uma cópia de uma struct então nos encontramos em um cenário onde, durante um dado processamento, vão haver diversas cópias da mesma struct salvas na memória, mesmo que só precisemos de uma delas ao final da operação. Isso é um desperdício de memória e vai diretamente contra os objetivos do Go em ser uma linguagem performática, otimizada e com baixo consumo de RAM.

Conclusão

Funções puras são extremamente úteis num cenário de paradigma funcional, elas são fáceis de testar e seu comportamento é previsível, mas toda solução possui tradeoffs e, nesse caso, é sacrificado o consumo de memória. No ecossistema do Go, onde o baixo consumo de RAM é padrão, funções puras fazem pouco sentido e desperdiçam o potencial da linguagem que nos fornece tantas ferramentas para lidar com ponteiros.

Quando menos é mais - Escalando uma API em Golang

Mateus Vinícius — Mon, 09 Oct 2023 20:25:26 +0000

Resolvi fazer a minha implementação da rinha de backend essa semana, e a experiência que tive foi bastante interessante e até contra-intuitiva em alguns pontos, nesse artigo pretendo listar exatamente as técnicas que aprendi para escalar minha aplicação.

Fazendo um resumo breve, a Rinha de Backend foi uma competição criada pelo @zanfranceschi onde cada participante sobe um serviço, com um limite máximo de 3GB de RAM e 1.5 CPUs, contendo no mínimo 4 elementos: 2 instâncias de uma API feita em qualquer linguagem, 1 nginx para baleancear a carga entre as APIs e um banco para persistência de dados em disco. Esse serviço precisa aguentar um teste de estresse com Gattling, cujo código do teste foi feito pelo próprio @zanfranceschi em Scala.

No final minha implementação conseguiu aguentar o teste de estresse de 58 mil requisições em 3min, dando a média de quase 281 requisições por segundo.

Pra entender os requisitos da implementação basta acessar o repositório da Rinha.
Para ver minha implementação basta acessar o meu repositório. No meu caso, implementei a API em Golang e usei o banco postgres para persistência em disco.

Aprendi muitas coisas importantes sobre escalabilidade com esse desafio, e aqui vou pontuar as que mais fizeram diferença no resultado final da performance da minha aplicação:

Índice em campo único

Um dos pontos do stress test é fazer uma massiva busca por termos.
Dado um termo, a API deverá retornar os 50 primeiros resultados de registros no banco (que são as pessoas), cujo termo esteja presente no campo "apelido", "nome" ou em algumas das "stacks", que representa um array de strings.

Para facilitar a consulta, criei um campo no banco chamado de "search_index", esse campo, do tipo varchar, une todos os outros campos num único texto, assim a pesquisa pode ser direcionada unicamente para este campo.

Além disso, adicionei um índice do tipo GiST nesse campo, o que aumentou drasticamente a performance das consultas.

Channels e goroutines para processamento concorrente

Channels são canais de comunicação entre threads no Golang, e isso é útil para delegar a tarefa de inserir no banco de dados para uma thread diferente daquela que está lidando com a requisição do Gattling, assim podemos responder à requisição mais rapidamente.

Fiz com que a rota para criação de uma pessoa não inserisse no banco diretamente, mas sim enviasse para um channel, onde do outro lado há um worker recebendo esses dados numa goroutine. O worker recebe a pessoa da channel e insere num slice e, quando o slice atingir 1000 pessoas, o worker faz um batch insert no banco de dados.

Num projeto em produção, onde eu deveria me preocupar com consistência dos dados, substituiria a channel por um sistema de filas como kafka ou rabbitMQ, ou até mesmo filas do Redis, para que os dados não fiquem em memória, mas não era necessidade para o desafio, então optei por sacrificar a consistência por ganho de performance.

A vantagem foi que a inserção é feita em apenas uma operação, usando apenas uma conexão com o banco, e gerenciado por um worker que está rodando numa thread diferente da requisição dos usuários.

Cache

Utilizei Redis para criar gerenciamento do cache de cada pessoa. Ao acessar a rota de criar pessoa a API, antes de enviar o recurso para o channel, salva o ID e o apelido no cache.

Esse cache otimizou a consulta, já que o endpoint de consultar pessoa poderia buscar os dados direto no cache com o ID, mas também otimizou a criação, já que existe uma constraint que impede a pessoa de ser registrada caso o apelido já esteja em uso por outra pessoa. Então antes de enviar para o channel a API faz uma busca por apelido no cache, e, caso já esteja em uso, retorna imediatamente uma mensagem de erro.

Limitação de conexão do nginx e postgres

Essa foi a parte mais interessante, e esse é o tópico que dá nome ao artigo...
A ganho mais significativo de performance que a minha implementação teve foi, sem dúvidas, quando DIMINUI DRASTICAMENTE a quantidade de conexões máximas, tanto do nginx quanto do postgres.

Minha configuração inicial do nginx permitia até 2048 conexões simultâneas na minha instância, e a do postgres permitia até 300 conexões no máximo. O problema é que, dado um cenário de recursos limitados - 3GB de RAM e 1.5 CPUs -, o maior gargalo está no fluxo de entrada de novas requisições.

Cada conexão com o postgres é um fork de um processo, e isso custa CPU, portanto, num cenário de escassez, a solução mais eficiente é limitar o número máximo de requisições simultâneas, assim o banco consegue gerenciar de forma mais eficiente as conexões existentes. Diminuí o número máximo de conexões de 300 pra 30, e com cada API tendo um pool máximo de 15, e isso já diminuiu o uso de CPU do postgres de 100% no pico para, no máximo, 50%. Foi uma mudança considerável.

Quanto ao nginx, diminuí o número de worker connections para 256, a ideia é que, como as requests virão de qualquer forma, o mais importante é controlar o fluxo de entrada para que conexões não sejam feitas em quantidades maiores do que o postgres e redis são capazes de lidar. Isso aumenta o tempo de espera do cliente para a conexão ser estabelecida, mas o mesmo tempo impede um overhelm da nossa aplicação e diminui o consumo de recursos de forma concorrente.

No fim, a maior lição aprendida é que, no quesito escalabilidade, as vezes menos é mais. Simplificar a aplicação, abrir mão de processamentos desnecessários e limitar as conexões para garantir que a CPU dará conta do fluxo de entrada pode fazer mais diferença do que otimização com algoritmos, refatoração do código ou buscar o framework/linguagem perfeita.

Usando postgres como message broker

Mateus Vinícius — Sun, 13 Aug 2023 19:23:52 +0000

Em muitos cenários de desenvolvimento, a necessidade de um message broker é inegável. No entanto, adotar soluções como Kafka ou RabbitMQ nem sempre é a opção mais viável ou desejável. Neste tutorial, vamos explorar uma abordagem alternativa e interessante: transformar uma tabela comum do Postgres em um message broker robusto, garantindo a integridade e consistência das mensagens processadas.

O que é um message broker? Trata-se de um sistema que gerencia e armazena uma fila de mensagens, sendo crucial para a comunicação assíncrona entre diferentes partes de um sistema. No nosso caso, o objetivo é criar um sistema onde diferentes sistemas e threads possam consumir mensagens da fila, assegurando que cada mensagem seja processada apenas uma vez, evitando corrupções ou duplicações indesejadas.

Preparando o Terreno

A ideia central é simples: um producer envia ordens de pagamento para uma tabela que atua como fila, com status inicial "PENDING". Em seguida, três clusters de uma aplicação Node executam cron jobs a cada 1 minuto, desempenhando o papel de consumers. Cada job verifica as ordens de pagamento pendentes na tabela, processa o pagamento e atualiza o status para "COMPLETED". O desafio é garantir que uma ordem seja processada apenas uma vez, mesmo com múltiplos consumidores operando simultaneamente.

O objetivo deste artigo não é ensinar como criar uma aplicação com Node do zero, mas apenas mostrar como utilizar o Postgres como message broker numa API feita como Node, por isso iremos pular alguns passos de setup básico.

Também, para fins didáticos, usaremos NestJS como framework para a API, pm2 para o gerenciamento dos clusters da aplicação e prisma para modelagem e como camada de comunicação com nosso banco de dados.

Você pode obter o projeto-base no repositório anti-duhring/postgres-queue-broker.

Primeiro de tudo é necessário iniciar um novo projeto Nest:

nest new postgres-queue-broker

Após isso, iremos instalar os pacotes pm2, @nestjs/schedule para gerenciamento dos cron jobs e o @prisma/client:

npm i pm2 @nestjs/schedule @prisma/client

Esse será o schema da nossa tabela Order, que conterá as ordens de pagamentos:

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Order {
  id        String    @id             @default(uuid())
  message   String
  status    String
  createdAt DateTime  @default(now()) @map("created_at")
  updatedAt DateTime  @updatedAt      @map("updated_at")
}

Após isso, iremos criar um módulo para ser o nosso Producer, ele será responsável por criar uma nova ordem de pagamentos e enviar para a nossa tabela Order.

nest g resource order

order.service.ts:

import { Injectable } from '@nestjs/common';
import { PrismaService } from '../prisma/prisma.service'
import { orderStatus } from '../../common/orderStatus.enum'

@Injectable()
export class OrderService {
    constructor(private readonly prisma: PrismaService) {}

    async create(message: string) {
        const order = await this.prisma.order.create({
            data: {
                message,
                status: orderStatus.PENDING
            }
        })

        return order
    }
}

Trabalhando com Locks Inteligentes

Para alcançar esse objetivo, iremos explorar as funcionalidades do Postgres: as cláusulas FOR UPDATE e SKIP LOCKED. O FOR UPDATE bloqueia as linhas retornadas por uma consulta, garantindo que nenhuma outra transação possa modificá-las até que a transação atual seja concluída. Por sua vez, o SKIP LOCKED permite que uma consulta ignore linhas que estejam bloqueadas, possibilitando o salto sobre linhas já bloqueadas por outros consumidores.

Sabendo isto, iremos criar o módulo do nosso consumer, que consistirá num cron job_ que roda a cada 1min, obtendo as ordens de pagamento pendentes, processando e atualizando seu status:

nest g resource consumer

consumer.service.ts

import { Injectable } from '@nestjs/common';
import { PrismaService } from '../prisma/prisma.service';
import { orderStatus } from '../../common/orderStatus.enum';
import { Cron } from '@nestjs/schedule';

@Injectable()
export class ConsumerService {
  constructor(private readonly prisma: PrismaService) {}

  async getPendingOrders() {
    const pendingOrders = await this.prisma.$queryRaw`
                select o.*
                from "Order" o 
                where o.status = 'PENDING'
                order by o.created_at asc 
                for update skip locked
        `;

    return pendingOrders as any[];
  }

  @Cron('0 * * * * *')
  async processOrders() {
    const pendingOrders = await this.getPendingOrders();

    for await (const order of pendingOrders) {
      await this.prisma.order.update({
        where: {
          id: order.id,
        },
        data: {
          status: orderStatus.COMPLETED,
        },
      });
      console.log(`Order ${order.id} has been processed`);
    }
  }
}

Esta consulta permite que cada job consumer obtenha uma ordem de pagamento pendente e a bloqueie, impedindo que outros jobs acessem a mesma ordem simultaneamente. Uma vez que a ordem é processada e o status é atualizado, ela é liberada para futuros consumidores.

Importante mencionar que, num cenário real, é necessário ter cautela com a quantidade de itens carregados, por isso um LIMIT para limitar a quantidade de itens obtidos por cada job pode evitar gargalos e erros de out of memory.

Rodando nossa aplicação

Por fim, basta realizar a build da aplicação.

npm run build

E executar os 3 clusters com o pm2:

pm2 start dist/main.js -i 3

É possível monitorar os logs dos clusters com seguinte comando:

pm2 logs main

Dessa forma podemos ver que cada ordem de pagamento é processada por apenas um cluster:

Conclusão

O uso do Postgres como um message broker alternativo pode ser uma solução valiosa em cenários onde a complexidade do Kafka ou do RabbitMQ não é justificada. Aproveitar as funcionalidades nativas do Postgres, como FOR UPDATE e SKIP LOCKED, possibilita a criação de um sistema robusto que garante a integridade e consistência das mensagens processadas.

Ao explorar essa abordagem, você poderá aprimorar a comunicação assíncrona em seus sistemas, evitando problemas de duplicação e corrupção de mensagens. Dessa forma, o Postgres se mostra não apenas como um excelente banco de dados, mas também como um aliado poderoso na construção de soluções de integração confiáveis. Experimente essa abordagem em seus projetos e desfrute dos benefícios de um message broker sólido e eficiente.

Para saber mais

Esse artigo foi fortemente inspirado pela palestra do Rafael Ponte no canal da ZUP, fica aqui a recomendação para entender a implementação com mais detalhes:
https://www.youtube.com/watch?v=FF6Am0N6eq4&t=3275s

Usando mensageria com Amazon SQS + Node

Mateus Vinícius — Thu, 11 May 2023 13:22:42 +0000

O que é um serviço de mensageria

O serviço de mensageria é uma forma de trocar informações entre diferentes partes de uma aplicação ou sistema de forma organizada e eficiente. Ele ajuda a separar as partes da aplicação e facilita a sua manutenção e desenvolvimento.

Imaginando uma aplicação de e-commerce em que o serviço de compra de produtos fica separado do serviço que processa o pagamento e efetivamente realiza a transação entre as contas bancárias, a forma mais segura e efetiva de realizar a comunicação entre eles é via mensageria.

Com mensageria, o serviço de compra de produtos vai enviar uma mensagem para uma fila com as informações de transação, enquanto o serviço de pagamento vai buscar as mensagens nesta fila e realizar as transações. Dessa forma é possível garantir que, mesmo que o serviço de compra de produtos caia, ou esteja passando por uma demanda gigantesca que possa comprometer o processamento de novas requisições, os pagamentos ainda assim serão processados de forma correta. Isso também garante que, mesmo havendo milhares de pagamentos na fila para serem processados, o usuário não precisará aguardar a transação ser realizada, já que uma vez enviado o pagamento para fila, é garantido que ele será consumido pelo serviço de processamento do pagamento, independemente do tempo que demore.

Objetivo neste tutorial

Neste tutorial iremos criar um exemplo básico de um serviço de e-commerce (producer) que se comunica com um serviço de pagamento (consumer), e toda a comunicação será feita via mensageria.

Setup

Como o objetivo é entender o funcionamento de um serviço de mensageria utilizando Amazon SQS, não iremos nos aprofundar tanto na criação dos serviços de e-commerce e pagamento. Em vez disso, vamos nos concentrar na comunicação entre os dois usando como base um projeto hospedado no repositório: https://github.com/anti-duhring/amazon-sqs-tutorial

Abra o terminal e digite:

git clone https://github.com/anti-duhring/amazon-sqs-tutorial.git

Após isso, instale as dependências da aplicação com o comando:

npm install

Executando a aplicação

Iremos executar ambos os serviços: producer e consumer.

Vá até o root da pasta local do repositório que você acabou de clonar e abra dois terminais.

Em um deles, digite o comando:

npm run start:producer

No outro, digite o comando:

npm run start:consumer

Entendendo o funcionamento

A aplicação consiste em dois serviços: producer e consumer.

Producer: Uma simulação de um e-commerce, que possui uma rota /request-transfer, cujo objetivo é enviar ao serviço de pagamento (consumer) uma requisição com o número da conta que fará o pagamento, o número da conta que receberá o pagamento e a quantia de dinheiro a ser transferido.
Consumer: Um exemplo de um serviço de pagamento que recebe as informações por meio da rota /process-transfer e realiza a transação.

Por ora a comunicação entre os dois serviços está sendo feita de forma direta, ou seja, dentro da própria rota /request-transfer o producer recebe as informações do pagamento e já dispara uma requisição para a rota /process-transfer do consumer, que realiza a transação.

Agora, vamos adaptar o projeto para que o producer não precise mais se comunicar diretamente com o consumer. Em vez disso, o producer será responsável apenas por enviar os pedidos de transação para uma fila, e o consumer será responsável apenas por buscar esses pedidos constantemente e processá-los.

Criando nossa fila principal

Vá até o serviço Amazon SQS no seu console da AWS.

Após acessar a página do Amazon SQS, clique no botão "Create queue" (criar fila).

Dentro da página de criação da fila você verá uma série de opções para configuração. Entre elas, destaco aqui o type (tipo) da fila:

O tipo da fila, pode ser standard(comum) ou FIFO (First In First Out). Filas comuns não possuem ordem nas mensagens, enquanto as FIFO ordena a fila em forma de pilha, onde a primeira mensagem que foi criada será a primeira a ser encontrada ao buscar mensagens dessa fila.

Para os propósitos deste tutorial, vamos usar as seguintes configurações que já são atribuídas por padrão pelo próprio SQS:

Clique no link Info ao lado da configuração para entender melhor o que cada propriedade representa.

Após ter criado a fila copie o URL gerado no final.

Criando o service de comunicação com o Amazon SQS

Para facilitar a comunicação da nossa aplicação com o Amazon SQS, vamos criar um service, dentro da pasta src/service, que terá três funções principais: enviar uma mensagem para a fila, recuperar mensagens da fila e deletar mensagens da fila.

Esse service será útil para desacoplar o SQS da nossa aplicação, permitindo que ele seja facilmente adaptado para funcionar com outros serviços de fila também.

Criando a classe SqsService

Vamos começar com uma classe com apenas dois atributos, ambos privados, client e queueUrl.

export class SqsService {
    #client
    #queueUrl

    constructor() {
    }

}

A ideia é que client seja uma instância do SQSClient do pacote @aws-sdk/client-sqs, que serve pra estabelecer uma conexão com a nossa fila. Enquanto que queueUrl será o URL da fila copiado anteriormente, que deverá ser passado via constructor, assim vamos poder usar o service para outras filas, se for preciso.

Adicionando o client do SQS no constructor

Agora precisamos adicionar o SQSClient no constructor, e atribuí-lo como valor da propriedade client.

import { SQSClient } from "@aws-sdk/client-sqs";
import * as dotenv from 'dotenv';

dotenv.config()

export class SqsService {
    #client
    #queueUrl

    constructor(queue) {
        this.#client = new SQSClient({
            region: process.env.AWS_REGION,
            credentials: {
                accessKeyId: process.env.AWS_ACCESS_KEY_ID,
                secretAccessKey: process.env.AWS_ACESS_KEY
            }
        })

        this.#queueUrl = queue
    }

}

Perceba que, para estabelecer uma conexão, o client requere algumas informações, que são parte da interface SQSClientConfig: region, accessKeyId e secretAccessKey. Essas informações são referentes a sua conta da AWS e não devem ser compartilhadas, por isso iremos usar um arquivo .env pra criar variáveis de ambiente.

Basta criar um arquivo .env no root do projeto com as seguintes variáveis:

AWS_REGION=REGIÃO (ex: us-east-1)
AWS_ACCESS_KEY_ID=ID DO USUÁRIO
AWS_ACESS_KEY=CHAVE DE ACESSO
AWS_MAIN_QUEUE_URL=URL DA SUA FILA

Adicionando método para enviar mensagens para fila

Agora precisamos criar um método que irá enviar uma mensagem para a nossa fila usando o client.

O método terá como parâmetro um objeto com duas propriedades: body e attributes. O body será o texto que ficará no corpo da mensagem, enquanto attributes é um valor opcional que fornece mais informações sobre a mensagem.

Aqui está um exemplo do objeto, mas você pode entender melhor suas propriedades na documentação oficial da AWS:

{
    body: 'MENSAGEM QUE IRÁ NO CORPO',
    attributes: {
        'VALOR_OPCIONAL1': {
            DataType: 'String',
            StringValue: 'VALOR DO ATRIBUTO'
        }
    }
}

Nosso método de enviar mensagem será assim:

import { SQSClient } from "@aws-sdk/client-sqs";
import * as dotenv from 'dotenv';

dotenv.config()

export class SqsService {
    #client
    #queueUrl

    constructor(queue) {
        this.#client = new SQSClient({
            region: process.env.AWS_REGION,
            credentials: {
                accessKeyId: process.env.AWS_ACCESS_KEY_ID,
                secretAccessKey: process.env.AWS_ACESS_KEY
            }
        })

        this.#queueUrl = queue
    }

    async sendMessage({ body, attributes }) {
        try {

            const sendMessageCommand = new SendMessageCommand({
                QueueUrl: this.#queueUrl,
                MessageBody: body,
                MessageAttributes: attributes,
                DelaySeconds: 0
            })

            const response = await this.#client.send(sendMessageCommand)


            return response
        } catch(err) {
            throw err
        }
    }

}

Agora podemos enviar mensagens para a fila com o nosso service!

Adicionando método para buscar mensagens na fila

Além de enviar mensagens, precisamos também de um método para buscar mensagens na fila e retornar uma array delas:

async receiveMessages() {
    try {
        const receiveMessageCommand = new ReceiveMessageCommand({
            QueueUrl: this.#queueUrl,
            MaxNumberOfMessages: 10,
            WaitTimeSeconds: 20,
            MessageAttributeNames: ['All']
        })
        const response = await this.#client.send(receiveMessageCommand)
        const messages = response?.Messages?.length? response.Messages : []

        return messages
    } catch(err) { 
        throw err
    }
}

Entendendo as propriedades:

QueueUrl: A URL da nossa fila.
MaxNumberOfMessages: O número máximo de mensagens a serem retornadas. O Amazon SQS nunca retorna mais mensagens do que esse valor (no entanto, menos mensagens podem ser retornadas).
WaitTimeSeconds: A duração (em segundos) pela qual a chamada aguarda a chegada de uma mensagem na fila antes de retornar.
MessageAttributeNames: Atributos que serão recebidos.

Para saber mais sobre as propriedades consulte a documentação oficial sobre a interface ReceiveMessageCommandInput da AWS.

Adicionando método de deletar mensagem da fila

Após a mensagem ser recebida e a transação ser concluída pelo consumer, é importante excluir a mensagem para evitar processamento duplicado.

Para isso, vamos criar um método em nosso service que receberá um parâmetro chamado ReceiptHandle, que é um identificador associado ao recebimento de uma mensagem. Um novo identificador de recebimento é gerado cada vez que uma mensagem é recebida. Ao excluir uma mensagem, é necessário fornecer o ReceiptHandle mais recente associado a ela para garantir que a mensagem correta seja excluída.

async deleteMessage(receiptHandle) {
    try {
        const deleteMessageCommand = new DeleteMessageCommand({
            QueueUrl: this.#queueUrl,
            ReceiptHandle: receiptHandle
        })

        await this.#client.send(deleteMessageCommand)
    } catch(err) {
        throw err
    }
}

Entendendo as propriedades:

QueueUrl: link da nossa fila.
ReceiptHandle: Identificador da nossa mensagem.

Para saber mais sobre as propriedades consulte a documentação oficial sobre a interface DeleteMessageCommandInput da AWS.

Usando o service de comunicação com o Amazon SQS no producer

Agora que criamos o service de comunicação com o Amazon SQS, podemos finalmente modificar a nossa rota /request-transfer do producer. Em vez de disparar uma requisição diretamente para a rota /process-transfer do consumer, o producer enviará uma mensagem com as informações do pagamento para a nossa fila, para que o consumer possa recebê-la e consumi-la no momento adequado.

Nossa rota /request-transfer terá, agora, o seguinte conteúdo:

Primeiro criamos uma nova instância do SqsService e, após isso, chamamos o método sendMessage(), passando como body as informações da nossa transação. Como o body precisa ser uma string, o método JSON.stringify() é chamado para converter nosso objeto com as informações da transação em texto.

app.post('/transfer', async(req, res) => {
    const { 
        fromAccount,
        toAccount,
        amount
    } = req.body;

    try {
        const sqsService = new SqsService(process.env.AWS_MAIN_QUEUE_URL)
        await sqsService.sendMessage({
            body: JSON.stringify({
                fromAccount,
                toAccount,
                amount
            })
        })

        res.status(200).json({ message: 'Sua transação será processada' })
    } catch(err) {
        console.log(err)
        res.status(500).json({ message: 'Erro interno' })
    }
})

Consumindo as mensagens da fila no consumer

Agora que o producer envia as mensagens para a fila e não se conecta mais diretamente ao consumer, precisamos criar um worker que busque constantemente por transações em nossa fila e as processe. Para isso, usaremos uma biblioteca bem conhecida do Node.js para agendamento de tarefas, chamada node-cron. Com ela, poderemos atribuir uma tarefa a ser executada repetidamente pelo consumer. Essa tarefa será buscar novos pedidos de transações na fila e, no nosso caso, para facilitar a visualização do que está acontecendo, vamos definir um intervalo de 1 minuto. Ou seja, o consumer buscará novas transações na fila e as processará a cada 1 minuto.

Criando a task agendada com node-cron

Para criar uma task com node-cron que seja executada a cada 1min, basta substituirmos nossa rota /process-transfer por essa função:

import cron from 'node-cron'

cron.schedule('* * * * *', () => {
    console.log('Running every minute')
})

Agora sempre que o nosso serviço consumer estiver sendo executado, uma task será realizada automaticamente a cada 1min.

Consumindo mensagens do Amazon SQS dentro da task

Agora que nossa task está sendo executada a cada 1min, precisamos fazer com que ela busque mensagens que estão na nossa fila, para isso, iremos criar uma nova instância do SqsService e chamar o método receiveMessages() que criamos anteriormente.

cron.schedule('* * * * *', async() => {
    const sqsService = new SqsService(process.env.AWS_MAIN_QUEUE_URL)
    const messages = await sqsService.receiveMessages()
    console.log(messages)
})

O output será uma array de objetos Message, que são as nossas mensagens:

Removendo mensagens da fila

Agora que o nosso consumer já recebe as mensagens da fila de forma autônoma, isto é, sem precisar ser "chamado" pelo producer, vamos implementar um protótipo que simula o processamento da transação de cada mensagem. Ao final do processamento, a mensagem será removida da fila.

É importante destacar que toda mensagem precisa ser removida da fila após ser consumida, para evitar que ela seja processada duas vezes.

A função que iremos adicionar faz um loop por cada mensagem recebida e simula seu processamento com um setTimeout dentro de uma Promise, demorando 5 segundos pra cada mensagem:

cron.schedule('* * * * *', async() => {
    const sqsService = new SqsService(process.env.AWS_MAIN_QUEUE_URL)
    const messages = await sqsService.receiveMessages()

    for(let i = 0; i < messages.length; i++) {
        await new Promise(resolve =>
            setTimeout(() => {
                console.log(`Simulando processamento da mensagem ${messages[i].MessageId}...`)
                resolve()
            }, 5000)
        )
    } 
})

Após o processamento precisamos remover a mensagem da fila. Pra isso iremos chamar o método deleteMessage() do nosso SqsService. Ele recebe como parâmetro o ReceiptHandle da mensagem.

cron.schedule('* * * * *', async() => {
    const sqsService = new SqsService(process.env.AWS_MAIN_QUEUE_URL)
    const messages = await sqsService.receiveMessages()

    for(let i = 0; i < messages.length; i++) {
        await new Promise(resolve =>
            setTimeout(() => {
                console.log(`Simulando processamento da mensagem ${messages[i].MessageId}...`)
                resolve()
            }, 5000)
        )

        await sqsService.deleteMessage(messages[i].ReceiptHandle)
        console.log(`Mensagem ${messages[i].MessageId} processada e removida da fila...`)
    } 
})

Pronto! Criamos um serviço de pagamentos que se comunica via mensageria com o Amazon SQS. Perceba que, agora, o serviço que pede que pagamentos sejam feitos e o serviço que de fato processa o pagamento são totalmente independentes um do outro, o que facilita a escalabilidade e manutenção.

Shallow Copy vs Deep Copy no JavaScript

Mateus Vinícius — Wed, 26 Apr 2023 18:47:36 +0000

Uma shallow copy de um objeto é uma cópia que, embora aponte para uma referência diferente do objeto original, suas propriedades ainda apontam para as mesmas referências na memória. Portanto, embora sejam objetos diferentes, a alteração do valor de uma propriedade do objeto original também alterará o valor da mesma propriedade na cópia, e vice-versa.

É possível criar uma shallow copy usando o método Object.assign, spread operator e etc.

const person = {
    name: 'Tom',
    age: 55,
    bestFriend: {
        name: 'Rob',
        age: 33
    }
}

// Shallow copy
const person2 = {...person}

console.log(person === person2) // false

console.log(person.bestFriend === person2.bestFriend) // true

person.bestFriend.name = 'Ben'

console.log(person.bestFriend.name) // Ben
console.log(person2.bestFriend.name) // Ben

Importante lembrar que, no JavaScript, todo valor primitivo (como número, string, etc.) é armazenado diretamente no objeto, e não apenas sua referência na memória. Por isso, mesmo em uma shallow copy de um objeto, suas propriedades primitivas serão diferentes e a modificação do valor no objeto original não afetará o valor na cópia, e vice-versa.

const person = {
    name: 'Tom',
    age: 55,
    bestFriend: {
        name: 'Rob',
        age: 33
    }
}

// Shallow copy
const person2 = {...person}

console.log(person === person2)

person.name = 'Bob'
console.log(person.name) // Bob
console.log(person2.name) // Tom

Já a deep copy é o oposto de uma shallow copy, sendo uma cópia do objeto em que todas as referências apontam para locais diferentes na memória em relação ao objeto original. Dessa forma, alterar o valor de uma propriedade no objeto original não afetará o valor da mesma propriedade na cópia, e vice-versa.

É possível criar uma deep copy de um objeto usando o método JSON.parse, a biblioteca lodash do Node ou uma função recursiva que utilize spread operator.

const person = {
    name: 'Tom',
    age: 55,
    bestFriend: {
        name: 'Rob',
        age: 33
    }
}

// Deep copy
const person2 = JSON.parse(JSON.stringify(person))

console.log(person === person2) // false

console.log(person.bestFriend === person2.bestFriend) // false

person.bestFriend.name = 'Ben'

console.log(person.bestFriend.name) // Ben
console.log(person2.bestFriend.name) // Rob

Compreender as diferenças entre shallow copy e deep copy pode ajudar a evitar erros ou mudanças inesperadas nos valores dos objetos.

Criando um algoritmo de pesquisa em largura em grafos

Mateus Vinícius — Tue, 11 Apr 2023 20:08:54 +0000

Grafos são estruturas de dados que consistem em vértices (ou nós) conectados por arestas (ou arcos). Eles são amplamente utilizados em várias áreas, como ciência da computação, matemática, física, biologia, entre outras.

Na ciência da computação, por exemplo, os grafos são usados para representar relações entre objetos, como usuários em uma rede social, ou para modelar rotas e caminhos em mapas, como as ruas no Google Maps. Eles permitem a análise de dados complexos, possibilitando a descoberta de padrões e informações úteis. Vejamos o seguinte grafo:

Para responder perguntas como "existe um caminho do vértice A ao vértice B?" ou "qual é o caminho mínimo do vértice A ao vértice B?", uma das soluções é utilizar o algoritmo de pesquisa em largura (BFS - breadth-first search). Ele começa no vértice A e expande sua pesquisa para os vértices conectados a ele, que são B e C. Em seguida, avança para os vértices conectados a B e C, e assim por diante, buscando em largura.

Vamos criar um exemplo de algoritmo de pesquisa em largura usando JavaScript, para responder a seguinte questão: Qual o caminho mais curto do vértice A ao vértice F?

Primeiro vamos definir as vértices e suas conexões como um objeto:

const connections = {
    A: [ 'B', 'C' ],
    B: [ 'A', 'D', 'F' ],
    C: [ 'A', 'D', 'E' ],
    D: [ 'B', 'C' ],
    F: [ 'B', 'E' ],
    E: [ 'C', 'F' ]
}

Estamos dizendo que A se conecta com B e C, que B se conecta com A, D e F e assim sucessivamente.

Agora vamos começar a criar nosso algoritmo. Primeiro precisamos que ele faça um loop por todos os vértices do grafo e identifique quais já foram visitados.

function findShortestPath(graph, startNode, endNode) {
    // fila dos vertices que serão visitados
    const queue = [startNode];
    // objeto contendo os vértices que já foram visitados
    const visited = { [startNode]: true };
    // objeto que vai identificar quais os vértices anteriores a um determinado vértice pra montarmos o caminho
    const predecessor = {};

    // Loop enquanto houverem vértices para ser visitados
    while (queue.length) {
        // Obtém e remove o primeiro vértice da lista
        const currNode = queue.shift();

        // RESTO DO NOSSO ALGORITMO
    }

    return null;
}

Agora precisamos fazer com que, a cada novo vértice buscado, a função obtenha o vértice anterior que se ligue a ele e adicione o caminho no nosso objeto predecessor.

function findShortestPath(graph, startNode, endNode) {
    const queue = [startNode];
    const visited = { [startNode]: true };
    const predecessor = {};

    while (queue.length) {
      const currNode = queue.shift();
      // Obtém os vértices que estão conectados ao vértice atual
      // aqui são chamados de vizinhos
      const neighbors = graph[currNode];

      // Itera sobre cada vértice vizinho
      for (const neighbor of neighbors) {

        // Apenas continua a busca se ele ainda não tiver sido visitado
        if (!visited[neighbor]) {
            visited[neighbor] = true;
            // Adiciona no objeto predecessor o vértice que está ligado a ele
            predecessor[neighbor] = currNode;
            // Adiciona ele mesmo na fila de vértices para serem pesquisados
            queue.push(neighbor);

            // RESTO DO NOSSO ALGORITMO
        }
      }
    }

Agora que o algoritmo já busca todos os vértices do nosso grafo, precisamos fazer com que ele obtenha o vértice de destino e, a partir do objeto predecessor, construa o caminho de volta ao ponto inicial.

function findShortestPath(graph, startNode, endNode) {
    const queue = [startNode];
    const visited = { [startNode]: true };
    const predecessor = {};

    while (queue.length) {
      const currNode = queue.shift();
      const neighbors = graph[currNode];

      for (const neighbor of neighbors) {
        if (!visited[neighbor]) {
          visited[neighbor] = true;
          predecessor[neighbor] = currNode;
          queue.push(neighbor);

          // Observa se o vizinho que está sendo checado atualmente...
          // é o nosso destino
          if (neighbor === endNode) {
            // Começa a reconstruir o caminho mais curto a partir do vértice...
            // de chegada
            const shortestPath = [endNode];
            // Obtém o vértice atual de onde os vizinhos foram obtidos
            let prevNode = currNode;

            // Loop enquanto o caminho ainda não tiver sido reconstruído...
            // até o ponto de partida
            while (prevNode !== startNode) {
                // Adiciona no começo da array `shortestPath` o vértice `prevNode`
                shortestPath.unshift(prevNode);
                // Obtém o predecessor do `prevNode` e faz dele o `prevNode` atual
                prevNode = predecessor[prevNode];
            }

            shortestPath.unshift(startNode);
            return shortestPath;
          }
        }
      }
    }

    return null;
}

Ao executar o nosso código vemos o resultado da busca:

const connections = {
    A: [ 'B', 'C' ],
    B: [ 'A', 'D', 'F' ],
    C: [ 'A', 'D', 'E' ],
    D: [ 'B', 'C' ],
    F: [ 'B', 'E' ],
    E: [ 'C', 'F' ]
}

const shortestPath = findShortestPath(connections, 'A', 'F');

console.log(shortestPath); // ['A', 'B', 'F']

Podemos ver que o caminho mais curto do vértice ao vértice F de fato é A -> B -> F:

O algoritmo de busca em largura é uma ferramenta essencial na resolução de problemas que envolvem a descoberta do menor caminho entre dois pontos em um grafo. Mas é importante lembrar que cada aplicação pode ter suas particularidades e o algoritmo de pesquisa em largura não é o único e pode não ser o melhor algoritmo de busca pelo menor caminho em muitos casos.

Saber implementar um algoritmo de pesquisa em largura pode ajudar a solucionar problemas complexos em diversas áreas, como redes de transporte, otimização de rotas e até mesmo jogos.

Como algoritmos melhoram a performance do seu código

Mateus Vinícius — Sun, 26 Mar 2023 19:39:51 +0000

Algoritmos são conjuntos de instruções que direcionam um computador para realizar uma tarefa específica. Eles estão presentes em todas as áreas da programação e são essenciais para otimizar o desempenho do código. O objetivo desse artigo é introduzir a importância dos algoritmos usando como exemplo a performance na ordenações de listas.

Imagine o seguinte cenário: temos uma lista de 10 números [3, 7, 2, 8, 1, 6, 9, 4, 5, 0] e queremos que seja ordenada do menor para o maior.

Nesse caso, dois algoritmos bastante conhecidos (não são os únicos e nem os melhores, mas servem como exemplo) na área de ordenação de listas são o bubble sort e o quick sort.

O bubble sort funciona da seguinte maneira: ele percorre a lista diversas vezes, comparando cada elemento com o seu sucessor e trocando o lugar de ambos caso necessário. Esse processo é repetido até que a lista esteja completamente ordenada. O tempo de execução médio desse algoritmo é O(n^2).

Nota: O() é uma notação de medida de complexidade de tempo chamada Big O. Em resumo, serve pra descrever quantas ações aquele algoritmo precisa performar pra que atinja seu objetivo

Imaginando nosso caso hipotético de uma lista com 10 números, cada número precisaria percorrer toda a lista e comparar os valores, o que são 10 ações pra cada elemento, por isso a complexidade de tempo é n^2, que no caso seria 10^2 = 10*10, que é igual a 100. Ou seja, o bubble sort requere 100 ações pra ordenar uma lista de 10 números. Extrapolando o exemplo pra uma lista de 100 números, a quantidade de ações requeridas sobe pra 10.000 (ou 100^2 = 100*100)!

Por outro lado, o quick sort é um algoritmo que utiliza uma estratégia conhecida como "dividir para conquistar". Ele escolhe um elemento da lista como pivô e, em seguida, divide a lista em duas partes: uma contendo elementos menores que o pivô e outra contendo elementos maiores que o pivô. Esse processo é repetido até que toda a lista esteja ordenada.

Voltando ao nosso caso de uma lista com 10 números, o quick sort escolheria um elemento do array para ser o pivô. Neste caso, vamos escolher o elemento do meio, que é o número 1.

O array é dividido em duas partes: uma parte com valores menores que o pivô e outra com valores maiores ou iguais ao pivô.
A parte dos menores valores fica à esquerda do pivô, e a parte dos maiores valores fica à direita do pivô. Os valores iguais ao pivô podem ficar em qualquer uma das partes.

A lista então é dividida em [3, 2, 1, 4, 0] e [7, 8, 6, 9, 5].

Agora devemos repetir o processo pra ambas as listas.

Vamos escolher um novo pivô para cada parte, e dividir o array novamente em duas partes: uma com valores menores que o pivô e outra com valores maiores ou iguais ao pivô.

Para a lista da esquerda, escolhemos o elemento 2 como pivô e dividimos em [1, 0] e [3, 2, 4]. Para a lista da direita, escolhemos o elemento 8 como pivô e dividimos em [7, 6, 5] e [9].

Agora repetimos o processo até que todas as partes do array tenham tamanho 1 ou 0. Quando uma parte do array tem tamanho 1 ou 0, significa que ela já está ordenada.

Ao final, o resultado será nossa lista ordenada da seguinte forma: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9].

O tempo de execução médio do quick sort, portanto, é O(n * log2(n)), que significa, nesse caso, 10 * log2(10) = 10 * 3,321 = 33,2. Extrapolando o exemplo pra uma lista de 100 números temos 100 * log2(100) = 100 * 6,643 = 664,3. Ou seja, o algoritmo de quick sort precisa performar, em média, 664,3 ações pra ordenar uma lista de 100 números, bem menor do que o tempo de execução do bubble sort, que precisa de 10.000 ações!

Apenas com o uso de algoritmos e matemática diminuímos em quase 1.400% o tempo de execução do nosso código, por isso o domínio do assunto é tão crucial para programadores.

Em resumo, os algoritmos são ferramentas importantes para a otimização do desempenho do código. Conhecer os fundamentos da programação é essencial para auxiliar na resolução de problemas de forma correta e eficiente.

Dica de leitura: Entendendo Algoritmos: Um Guia Ilustrado Para Programadores e Outros Curiosos, Aditya Y. Bhargava.

Como criar uma docker image para sua API feita com Java?

Mateus Vinícius — Tue, 21 Feb 2023 14:52:23 +0000

Introdução

Uma Docker Image é um pacote executável que contém todas as ferramentas e softwares necessários para executar uma aplicação, incluindo, além do próprio código-fonte, bibliotecas, dependências, configurações e variáveis de ambiente. Ao executar uma Docker Image o resultado é a criação de um container , que é o ambiente isolado onde o conteúdo da imagem irá rodar.

O container é como se fosse uma miniatura do sistema operacional, que isola a aplicação do ambiente em que está sendo executada. Esse isolamento permite que ela funcione de forma independente do sistema operacional ou hardware da máquina utilizada.

As Docker Images permitem que nós possamos criar ambientes de desenvolvimento e produção consistentes, sem conflitos ou problemas de compatibilidade. É o fim definitivo para o problema "Mas na minha máquina funciona!".

Além disso, as imagens podem ser compartilhadas no Docker Hub, e reutilizadas por outras equipes de desenvolvimento, tornando o processo de desenvolvimento mais eficiente e escalável.

O objetivo deste tutorial será a criação de uma imagem especificamente para uma API Java com Spring Boot. Será usado Maven para gerenciamento e build, na sua versão 3.8.7.

Instalando o Docker

Primeiro é necessário instalar o Docker no seu computador. A própria documentação da ferramenta já traz tutoriais simplificados, com passo-à-passo específico para cada sistema operacional, basta escolher uma opção e seguir os comandos.

Criando o Dockerfile

O Dockerfile é o arquivo que conterá as instruções para a construção da Docker Image, como uma receita de cozinha que descreve todos os ingredientes e passos necessários para criar uma refeição. No caso do Dockerfile, as instruções descrevem o que deve ser incluído na imagem Docker, como o sistema operacional, as bibliotecas e as dependências, e como configurar o ambiente para a aplicação.

O primeiro passo é criar um arquivo de nome Dockerfile, sem extensão, dentro da pasta raiz da aplicação.

- app
    - .idea/
    - .mvn/
    - src/
    - target/
    - .gitignore
    - Dockerfile
    - HELP.md
    - mvnw
    - mvnw.cmd
    - pom.xml

O arquivo irá apontar para uma Docker Image que será usada como base para a criação da nossa própria imagem e também conterá todos os comandos necessários para a build da aplicação e sua execução.

Escolhendo a imagem base

Por termos escolhido o Maven 3.8.7 como compilador e gerenciamento e o JDK 19 para a execução da aplicação Java, deveremos usar como base a Docker Image maven:3.8.7-eclipse-temurin-19-alpine, que já contém ambas as ferramentas e suas dependências instaladas sob um sistema operacional linux.

A escolha da imagem base vai variar conforme as necessidades, sendo possível utilizar desde uma imagem base de um Ubuntu novo, e dentro do próprio Dockerfile configurar comandos para que o Maven e a JDK sejam instalados, quanto utilizar uma imagem já com ferramentas pré-instaladas, como é o caso da maven:3.8.7-eclipse-temurin-19-alpine.

Adicionando a imagem base ao arquivo Dockerfile

Agora iremos adicionar conteúdo ao arquivo Dockerfile, e o primeiro passo será apontar para a imagem base, e isso é feito com o comando FROM image-name.

# Start with maven:3.8.7-eclipse-temurin-19-alpine base image
FROM maven:3.8.7-eclipse-temurin-19-alpine

# Maintaner data 
LABEL maintainer="Mateus Vinícius <mateus.limavn@gmail.com>"

# End

O comando LABEL é usado para adicionar informações e metadados à imagem que está sendo criada, como o nome do mantenedor, a versão da imagem, a descrição da aplicação e etc. Essa prática ajuda na organização e identificação das imagens, já que o comando docker images exibe essas informações registradas no LABEL juntamente com as informações da própria imagem.

Adicionando comandos para a build da aplicação

Após apontarmos a imagem que será usada como base, é hora de configurar os comandos que serão executados para fazer a build da nossa aplicação Java. O build será feito com o comando mvn package.

# Start with maven:3.8.7-eclipse-temurin-19-alpine base image
FROM maven:3.8.7-eclipse-temurin-19-alpine

LABEL maintainer="Mateus Vinícius <mateus.limavn@gmail.com>"
# Set the working directory to /app
WORKDIR /app

# Copy the source code to the container
COPY . .

# Build the application with Maven
RUN mvn package

#End

O comando WORKDIR define o diretório de trabalho padrão para as próximas instruções do arquivo. Isso permite que os comandos que serão executados saibam qual é o caminho do diretório da aplicação sem que seja necessário repetir o caminho absoluto a todo momento. O padrão é usar o diretório /app.

Já o comando COPY <fonte> <destino> copia o conteúdo da imagem para o container que será criado, que é o ambiente de execução da aplicação. Nesse caso todo o conteúdo da imagem será copiado para o container.

Para fazer a build da aplicação Java utilizaremos o comando mvn package do Maven, por isso ele é chamado com o RUN, que serve para executar outros comandos ou instruções.

Definindo as variáveis de ambiente

A maioria dos projetos utilizam variáveis de ambiente, elas são usadas tanto pelas aplicações quanto pelo próprio sistema operacional para acessar as configurações definidas.

No caso da aplicação Java que é usada de exemplo, as variáveis de ambiente estão sendo chamadas dentro do arquivo application-prod.properties da seguinte forma:

spring.datasource.url=${DATASOURCE_URL}
spring.datasource.driver-class-name=org.postgresql.Driver
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect
spring.datasource.username=${DATASOURCE_USERNAME}
spring.datasource.password=${DATASOURCE_PASSWORD}

No caso, os valores ${DATASOURCE_URL}, ${DATASOURCE_USERNAME} e ${DATASOURCE_PASSWORD} são as variáveis de ambiente. Elas estão definindo a url de conexão com o banco de dados, o usuário root desse banco e a sua senha.

Pra facilitar o reaproveitamento da imagem o ideal é que essas propriedades de configuração da aplicação que sejam dinâmicas passem a ser atribuídas à variáveis de ambiente, assim o desenvolvedor poderá modificá-las antes de executar o container.

Mas é importante, também, atribuir valores padrão à essas variáveis, e é pra isso que serve o comando ENV.

# Start with maven:3.8.7-eclipse-temurin-19-alpine base image
FROM maven:3.8.7-eclipse-temurin-19-alpine

LABEL maintainer="Mateus Vinícius <mateus.limavn@gmail.com>"
# Set the working directory to /app
WORKDIR /app

# Copy the source code to the container
COPY . .

# Build the application with Maven
RUN mvn package

# Set environment variables if needed
ENV DATASOURCE_URL=jdbc:postgresql://localhost:5432/db
ENV DATASOURCE_USERNAME=postgres
ENV DATASOURCE_PASSWORD=postgrespassword

#End

Informando as portas que o container estará executando

As portas que serão expostas para que a API receba requisições são definidas com o comando EXPOSE, e, nesse caso, utilizaremos a padrão 8080.

# Start with maven:3.8.7-eclipse-temurin-19-alpine base image
FROM maven:3.8.7-eclipse-temurin-19-alpine

LABEL maintainer="Mateus Vinícius <mateus.limavn@gmail.com>"
# Set the working directory to /app
WORKDIR /app

# Copy the source code to the container
COPY . .

# Build the application with Maven
RUN mvn package

# Set environment variables if needed
ENV DATASOURCE_URL=jdbc:postgresql://localhost:5432/db
ENV DATASOURCE_USERNAME=postgres
ENV DATASOURCE_PASSWORD=postgrespassword

# Expose default Spring Boot port
EXPOSE 8080

#End

Definindo o comando para execução do arquivo jar

Agora que o container já fez a build da aplicação, configurou as variáveis de ambiente e expôs as portas para requisições, chegou o momento de definir o comando para executar o arquivo jar que é gerado pela build do Maven.

Para isso iremos utilizar o comando CMD, que recebe uma array de argumentos que será executado em uma linha do terminal.

O comando para executar uma aplicação java, que está compilada num arquivo jar, e utilizando o profile de produção é java -jar target/myapp-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod, portanto, o comando CMD correspondente será CMD ["java", "-jar", "target/myapp-0.0.1-SNAPSHOT.jar", "--spring.profiles.active=prod"].

Ao final nosso arquivo Dockerfile ficará com o seguinte conteúdo:

# Start with maven:3.8.7-eclipse-temurin-19-alpine base image
FROM maven:3.8.7-eclipse-temurin-19-alpine

LABEL maintainer="Mateus Vinícius <mateus.limavn@gmail.com>"
# Set the working directory to /app
WORKDIR /app

# Copy the source code to the container
COPY . .

# Build the application with Maven
RUN mvn package

# Set environment variables if needed
ENV DATASOURCE_URL=jdbc:postgresql://localhost:5432/db
ENV DATASOURCE_USERNAME=postgres
ENV DATASOURCE_PASSWORD=postgrespassword

# Expose default Spring Boot port
EXPOSE 8080

# Run the jar file
CMD ["java", "-jar", "target/myapp-0.0.1-SNAPSHOT.jar", "--spring.profiles.active=prod"]

#End

Criando a Docker Image

Já com o Docker instalado e o arquivo Dockerfile configurado, podemos realizar a build da imagem. Para isso, basta abrir no terminal ou prompt de comando a pasta da aplicação - a mesma em que o arquivo Dockerfile se encontra - e executar o comando docker image build -t myapp-api .

O Docker irá executar todos os comandos presentes no arquivo Dockerfile, o que inclui a build da aplicação usando o mvn build, e, ao fim, irá gerar a imagem automaticamente.

Para ver e executar a imagem gerada, basta rodar o comando docker images no terminal ou prompt de comando.

Conclusão

Com a imagem gerada rodar a aplicação se torna muito mais fácil, já que basta rodar o comando docker run <nome-da-imagem> para que o container de execução seja criado.

Agora você pode salvar essa imagem num repositório no Docker Hub para executar em qualquer servidor ou máquina pessoal, sem se preocupar com a configuração do ambiente ou problemas de incompatibilidade. Sua aplicação pode rodar em qualquer lugar!