DEV Community: Vitor Braggion

A Fast Resume Why You Should Learn About Design Patterns

Vitor Braggion — Tue, 08 Oct 2024 19:18:26 +0000

🎯 Why Should You Learn Design Patterns?

A lot of devs discuss design patterns, and a lot of companies ask about them in the hiring process. I think they’re right, it’s really important because design patterns are solutions to common problems in Software Engineering, and they are always developed with the best practices that have been refined over time.

If you have no idea about design patterns, it’s similar to a professional football player having no idea about football tactics, like 4-3-3. Or a professional player of League of Legends not knowing the best way to play well in the jungle when he’s playing as a jungler. Maybe you don’t know about football tactics or about the best practices in your favorite game, but probably you’re not a professional. As a developer, if you earn money by coding, you’re a professional or would like to be. If you are a Software Engineer or want to improve your skills, you should know about it, especially if you’re working on an OOP project.

At least try to understand some design patterns: what problems they're trying to solve, what their pros and cons are, and how to use them accordingly. It's a good idea to consider them as guidelines rather than fixed solutions. It shouldn't mean you cannot tweak them to match your current requirements.

Design patterns are like having different keys to open a lot of different gates quickly. So just know which ‘gate’ it is and use the best 'key’ for it. This way, you can leverage an existing concept rather than reinvent it, increasing quality and decreasing the time spent on it. Regarding maintenance, it’s easier to support our code because many people are familiar with them, so it can be easier to maintain.

🟢 Types of Design Patterns

Below are the different types of design patterns with their meanings:

🏭 Creational Design Patterns

These patterns focus on the process of object creation. They abstract the instantiation process, making it more flexible by decoupling the client from the specifics of object creation. This helps in managing how objects are created, ensuring they are created in a controlled and consistent environment.

As a quick example, we can use the Singleton Pattern, which focuses on limiting the number of instances of a class to just one, sharing this instance with whoever needs it. It’s common in database connections, logging services, and other services. It's a good idea to ensure consistency and reduce resource usage.

🏗️ Structural Design Patterns

Structural patterns deal with relationships between classes or objects. They simplify the structure by identifying relationships between entities, allowing for easier maintenance and flexibility in object composition. These patterns ensure that if changes are made, they can be handled smoothly without altering the whole structure (low coupling).

As a quick example, we have the Adapter Pattern, which provides a common solution to connect two different interfaces as a link. Imagine you’re from the US and you're traveling to Europe. You need to buy a plug adapter to use your phone charger; this plug adapter could be our Adapter pattern in this context.

🎭 Behavioral Patterns

Behavioral patterns focus on object interaction and responsibility. They define how objects communicate and cooperate with each other while maintaining low coupling. These patterns help manage algorithms, responsibilities, and communication between objects effectively.

As a quick example, we have the Observer pattern, which provides us with a common solution to ‘listen’ for modifications to an object. So if there are any updates, it can notify all subscribers.

📝 In Summary

In summary, it’s really important that you know more about this. You can use these patterns when you face a specific problem instead of reinventing a solution, probably spending more time and increasing the difficulty of maintenance because many developers know about these patterns. They have been refined using the best practices of Software Engineering.

Let’s Stay in Touch:

Hi guys,

After leaving my startup and traveling around the world, I am now more at peace and recently focused on diving into my knowledge of Software Engineering. I would like to share this knowledge as a way to learn more and meet new people.

I will write about some design patterns and create code to solve common problems. If you’re interested in these topics, follow me, and let’s stay in touch to share knowledge! :)

If you have any tips, please let me know.

Below are my social networks:

Effective Real-Time Database Monitoring with Supabase and PostgreSQL: A Guide to Minimizing Overhead and Managing I/O

Vitor Braggion — Tue, 20 Aug 2024 16:04:44 +0000

How to Efficiently Monitor PostgreSQL with Supabase: Real-Time Data, Event Triggers, and Minimizing Overhead

Hello Developers,

Have you ever wondered how to continuously monitor your database to perform actions within your application? Whether it's displaying real-time data to users or automatically triggering events based on data changes (like notifications), you might be curious about the best approach to achieve this. Is polling the database constantly for updates the best solution? This method can be a major headache and lead to unnecessary overhead on both your application and database (I've seen companies struggle with this and end up reworking their systems after a while!).

The key is to minimize I/O operations, as processing costs can be quite high. Efficiently managing I/O operations is crucial.

There are simple solutions available that require minimal setup and provide almost everything you need out-of-the-box. One excellent example is Firebase Realtime Database, which abstracts many complexities by automatically syncing data changes to your client. It's highly recommended, especially for mobile applications. However, if you're already using a different database and migrating to Firebase isn't feasible, or if you prefer to stick with PostgreSQL, there are alternative solutions available.

Today, I'll demonstrate how to monitor your PostgreSQL database using a fascinating open-source library called Supabase, which is often considered an open-source alternative to Firebase. Supabase offers a variety of useful modules, including Fire Storage, Realtime Database, Authentication/Authorization, Functions, Auto-generated APIs, and more. For this example, we'll use the realtime module.

Before diving into the code, it’s important to understand the underlying concepts and mechanics of Supabase. This project is built with Elixir using the Phoenix framework and utilizes logical replication to listen for and replicate changes in your PostgreSQL database.

What is Logical Replication and WAL?

In essence, logical replication is a method for replicating data, including full datasets or changes, to another location. It typically involves a publish-subscribe model where the publisher gathers changes from one or more tables (publication) and the subscriber listens for and collects these changes.

In the context of databases, logical replication refers to replicating data between two or more databases. It captures changes (e.g., INSERTS, UPDATES, DELETES) at the database level and sends these updates to target databases.

This is usually done via Write-Ahead Logging (WAL), which logs changes before they are executed. WAL ensures data integrity, atomicity, and durability, and is widely used in event-driven systems. In a database context, any change to data files is first logged before being applied to the database.

Implementation of Supabase With Postgres

Now, let’s focus on implementing a small project to test Supabase and monitor our database in real-time. We’ll create an application that lists all services according to their status (pending, in progress, and completed) without repeatedly querying the database for updates. Our goal is to make the application real-time, updating instantly with any changes. This approach can significantly reduce the load on your database in larger projects.

In essence, we will use Supabase Realtime to listen for all modifications in our PostgreSQL database and transmit these updates to our NodeJS application. This application will handle the modified data and push updates to clients via WebSocket.

I will outline the main components of the project and provide an explanation of each. At the end, I will share a link to the repository where you can view the complete project code.

Project Structure: An Overview

This will be our project structure. Below are details of the main components:

/docker-compose.yml: This file contains the Docker Compose configuration, defining two containers. One container runs Supabase Realtime, responsible for monitoring changes in the database. The other container hosts our PostgreSQL database.

version: '3'

services:
  realtime:
    image: supabase/realtime:v1.0.0
    ports:
      - "4000:4000"
    environment:
      DB_HOST: postgres-realtime_db_1
      DB_NAME: postgres
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_PORT: 5432
      PORT: 4000
      # JWT_SECRET: SOMETHING_SUPER_SECRET
      SECURE_CHANNELS: 'false'
    networks:
      - realtime-network
    depends_on:
      - db

  db:
    build: database/.
    restart: always
    environment: 
      POSTGRES_PASSWORD: postgres
    ports:
      - "5432:5432"
    networks:
      - realtime-network

networks:
  realtime-network:
    driver: bridge

/database: This directory contains the Docker configurations for our database as well as the settings required for real-time monitoring.

Here’s the structure of our database:

/database/Dockerfile: This Dockerfile is invoked by the docker-compose.yml and uses a PostgreSQL image. It runs a script located at /database/scripts/00-init.sql to set up the database tables and apply necessary configurations to enable Supabase to monitor changes in the database.
/database/scripts/00-init.sql: This SQL script contains the code to create the database tables and configure the database so that Supabase can effectively listen for changes.

Script for creating tables and inserting data:


CREATE TABLE public.status (
  id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  name VARCHAR(255
);
INSERT INTO 
    public.status (name) 
VALUES 
    ('PENDDING'),
    ('IN_PROGRESS'),
    ('CONCLUDED');

CREATE TABLE public.service (
  id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  status_id bigint REFERENCES public.status NOT NULL
);

INSERT INTO 
    public.service (name, status_id)
VALUES 
    ('Reboque', 1),
    ('Bateria', 3),
    ('Pane Seca', 1),
    ('Troca de Luz', 2);

Configuring PostgreSQL for Supabase Realtime: Setting Up WAL for Change Capture

Supabase uses Write-Ahead Logging (WAL) to capture modifications in our database. Therefore, we need to configure certain settings in PostgreSQL to enable Supabase Realtime to work effectively.

-- adds information necessary to support logical decoding.
-- Each level includes the information logged at all lower levels.
ALTER SYSTEM SET wal_level='logical'; 

-- Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients
-- (i.e., the maximum number of simultaneously running WAL sender processes). 
-- 10 already is the default value
-- RECOMMENDATIONS: If you are replicating, you want to set this to the maximum number of standby servers you mighy possibly have
-- Performance impact when set above zero, but no additional penalty for setting it higher.s
ALTER SYSTEM SET max_wal_senders='10'; 

-- Specifies the maximum number of replication slots (see streaming-replication-slots) that the server can support
-- 10 already is the default value
ALTER SYSTEM SET max_replication_slots='10';

-- Create the Replication publication 
CREATE PUBLICATION supabase_realtime FOR ALL TABLES;

-- Send the previus values
ALTER TABLE public.service REPLICA IDENTITY FULL;
ALTER TABLE public.status REPLICA IDENTITY FULL;

All these configurations are necessary and are tailored to the project we will create. For instance, they involve setting up the specific tables for our project. In our final project, I have included these configurations and the table creation script to be executed automatically when starting our Docker containers.

/server: This directory contains the code for our project, which is responsible for receiving updates identified by Supabase Realtime and sending them to the client via WebSocket.

Inside this project, everything is organized according to its specific responsibilities.

/server/services/: This directory will include all the services used in our project.
- Database: Responsible for executing queries on our database. This service will be utilized primarily at the project startup to fetch all initial data. Afterward, it will only handle updates for any changes that occur.

const pg = require('pg');

class Database {
  pgPool;
  pgClient;

  constructor() {
    this.pgPool = new pg.Pool({
      host: '0.0.0.0',
      user: 'postgres',
      password: 'postgres',
      database: 'postgres',
      port: 5432,
    });
  }

  async connect() {
    try {
      this.pgClient = await this.pgPool.connect();
    } catch (error) {
      console.log('Connection error' , error)
    }
  }

  async query({ text, params }) {
    const res = await this.pgClient.query(text, params);

    return res;
  }

  disconnect() {
    this.pgClient.release();
  }

  async disconnectPool() {
    await this.pgPool.end();
  }
}

module.exports = Database;

DatabaseListener: Responsible for listening to changes identified by Supabase in our database. We will use the @supabase/realtime-js library to facilitate this.

const { RealtimeClient } = require('@supabase/realtime-js'); // "@supabase/realtime-js": "^1.3.3",

class DatabaseListener {

    // creating the connection with our supabase realtime, it's running on docker at port 4000
  socket = new RealtimeClient(process.env.REALTIME_URL || 'ws://localhost:4000/socket');

  constructor() {
      // when start our DatabaseListner, we'll connect and listen our connection
    this.socket.connect();

    this.socket.onOpen(() => console.log('Socket opened.'));
    this.socket.onClose(() => console.log('Socket closed.'));
    this.socket.onError((e) => console.log('Socket error', e.message));
  }

    // generic method to listen our database by channel
  _on(eventName, callback, channel = '*') {
    const databaseChanges = this.socket.channel(`realtime:${channel}`);

    databaseChanges.on(eventName, (e) => {
      console.log('EVENT', e);
      callback(e);
    });
    databaseChanges.subscribe();
  }

    // method to listen all modifications from our database (update, insert, delete') by channel
  onAll(callback, channel = '*') {
    this._on('*', callback, channel);
  }

    // method to listen updates events in our database by channel
  onUpdate(callback, channel = '*') {
    this._on('UPDATE', callback, channel);
  }

    // method to listen inserts events in our database by channel
  onInsert(callback, channel = '*') {
    this._on('INSERT', callback, channel);
  }

    // method to listen deletes events in our database by channel
  onDelete(callback, channel = '*') {
    this._on('DELETE', callback, channel);
  }
}

module.exports = DatabaseListener;

Socket: Responsible for managing the WebSocket connection with our client (frontend in our case) to transmit database modifications.

const socket = require('socket.io'); // "socket.io": "^4.4.0"

class Socket {

  io = null;

  constructor(server) {
      // starting socket server
    this.io = socket(server);
  }

  getIo() {
     // method to get the socket connection
   return this.io; 
  }

    // method listen the socket connection 
  onConnection(callback) {
    console.log(`Connected socket ${socket.id}`);

    this.io.on('connection', (socket) => {
      callback(socket);
    });
  }

    // emit an event with some data to our clients
  sendToAllSubscribers(eventName, data) {
    this.io.emit(eventName, data);
  }

}

module.exports = Socket;

/server/models/: This directory contains all the models for interacting with our database tables. Each model is organized by table, and since we are only interacting with the 'Services' table, we will have just this model.

Service: This file will establish a connection with our database to fetch all services and their statuses. It will be called only at the start of the application to retrieve all initial data. After that, it will focus solely on listening for changes, thus avoiding multiple database queries.

const Database = require('../../services/Database');

class Service {

    // Don't allow instance this class, it'll be possible just use static methods
  constructor() {
    throw new Error('It is not instantiable')
  }

    // method to fetch all services in our database. We'll use this method when our server start
  static async findAll() {
    let servicesFound = [];

    try {
      const database = new Database();
      await database.connect();

      const result = await database.query({
        text: 'SELECT * FROM public.service',
        params: []
      });

      servicesFound = result?.rows || [];

    } catch (error) {
      console.log(error);
    }

    return servicesFound;
  }

}

module.exports = Service;

/server/controllers: This directory will contain the business logic required to make the project work. It will utilize the models and services from the project. In our case, there will be only one controller.

ServiceController: This controller will fetch all 'Services' from our database and send them to the client via WebSocket. It will also listen for any changes in the database and, if any are detected, will send these updates to the clients via WebSocket.

const DatabaseListener = require('../../services/DatabaseListener');
const Service = require('../../models/Service');

// variable to help us to map our services by status
const helperToServiceMapStatus = {
  1: 'servicesPendding',
  2: 'servicesInProgress',
  3: 'servicesConcluded'
};

class ServiceController {

    // instance of ous Database Listener
  static databaseChanges = new DatabaseListener();
  // arrays that our services in database will be saved by status. It'll be saved in memory and it'll send for our clients by socket
  // warn: all services will be saved in memory, so you should be alert about the size of these list. Maybe in a production it's better you save it in a kind of database, like redis
  static servicesDto = {
    servicesPendding: [],
    servicesInProgress: [],
    servicesConcluded: []
  };

    // don't allow instance this class, it'll be just allowed use static methods
  constructor() {
    throw new Error('It is not instantiable')
  }

    // method to fetch all service from database, separe it by status and send to our clients by socket
  static async fetchServicesFromDatabaseAndSend(socket) {
    const servicesFound = await Service.findAll();

    servicesFound.map(service => {
      const serviceKey = helperToServiceMapStatus[service.status_id];
      ServiceController.servicesDto[serviceKey].push(service);
    });

    socket.onConnection((_socket) => {
      console.log(`Socket connection `, _socket.id);
      socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
    })
  }

    // listing all service status update in our database, then send it to our clients by socket
  static listenAndSendServicesStatus(socket) {

            // listing updates in our table 'service' in the public schema with status_id equals 1
      ServiceController.databaseChanges.onUpdate((e) => {
        ServiceController._managementState(e.old_record, e.record);
        socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
      }, 'public:service:status_id=eq.1');

            // listing updates in our table 'service' in the public schema with status_id equals 2
      ServiceController.databaseChanges.onUpdate((e) => {
        ServiceController._managementState(e.old_record, e.record);
        socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
      }, 'public:service:status_id=eq.2');

            // listing updates in our table 'service' in the public schema with status_id equals 3
      ServiceController.databaseChanges.onUpdate((e) => {
        ServiceController._managementState(e.old_record, e.record);
        socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
      }, 'public:service:status_id=eq.3');
    }

    // method to help us to manage our data that we're sending our client 
  static _managementState(oldRecord, newRecord) {
      const oldService = helperToServiceMapStatus[oldRecord.status_id];
      const newService = helperToServiceMapStatus[newRecord.status_id];

      ServiceController.servicesDto[oldService] = ServiceController.servicesDto[oldService].filter(_service => (_service.id != oldRecord.id));
      ServiceController.servicesDto[newService].push(newRecord);
    }

}

module.exports = ServiceController;

/server/src/server.js : Será onde iremos configurar nosso servidor para rodar o nosso frontend utilizando express e além disso iniciar nosso projeto backend.


const express = require('express'); //"express": "^4.17.1",
const path = require('path');
const app = express();
const server = require('http').createServer(app);
const Socket = require('../services/Socket');
const ServiceController = require('../controllers/ServiceController');

app.use(express.static(path.join(__dirname, '../../public')));
app.set('views', path.join(__dirname, '../../public'));
app.engine('html', require('ejs').renderFile);
app.set('view engine', 'html');

app.use('/public', (req, res) => {
  res.render('index.html');
});

(async () => {
    // starting our socket
  const socket = new Socket(server);

    // fetching our all database data and sending to our clients by socket
  ServiceController.fetchServicesFromDatabaseAndSend(socket);
  // listing our database changes and sending it to our clients by socket
  ServiceController.listenAndSendServicesStatus(socket);
})();

server.listen(8181);

/public/index.html: This is our frontend project, featuring a simple layout that lists the services from our database according to their status. It will establish a WebSocket connection with our backend to receive status updates for the services.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Services</title>
</head>
<body>
  <h2>Pendding Services</h2>
  <ul id="pendding"></ul>
  <br><br>

  <h2>In Progress Services</h2>
  <ul id="inProgress"></ul>
  <br><br>

  <h2>Concluded Services</h2>
  <ul id="concluded"></ul>
  <br><br>

</body>
<script type="module">
  import { io } from "https://cdn.socket.io/4.4.0/socket.io.esm.min.js";

  const socket = io('http://localhost:8181');
  const htmlPendding = document.getElementById('pendding');
  const htmlInProgress = document.getElementById('inProgress');
  const htmlConcluded = document.getElementById('concluded');

  socket.emit('sendMessage', {
    text: 'working'
  });
    // listing our socket to receive our data
  socket.on('receivedMessage', (data) => {
    htmlPendding.innerHTML = '';
    htmlInProgress.innerHTML = '';
    htmlConcluded.innerHTML = '';


        // putting our socket data in its specific group
    const { servicesPendding, servicesInProgress, servicesConcluded } = data;

    servicesPendding.map(service => {
      console.log('service', service);
      const item = document.createElement('li');
      item.textContent = service.name;
      htmlPendding.appendChild(item);
      window.scrollTo(0, document.body.scrollHeight);
    });

    servicesInProgress.map(service => {
      const item = document.createElement('li');
      item.textContent = service.name;
      htmlInProgress.appendChild(item);
      window.scrollTo(0, document.body.scrollHeight);
    });

    servicesConcluded.map(service => {
      console.log('service concluded', service);
      const item = document.createElement('li');
      item.textContent = service.name;
      htmlConcluded.appendChild(item);
      window.scrollTo(0, document.body.scrollHeight);
    });

  });
</script>
</html>

/package.json:

{
  "name": "realtime-pg",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "start": "forever -w --minUptime 2000 --spinSleepTime 2000 server/src/server.js",
    "start-node": "node server/src/server.js"
  },
  "dependencies": {
    "@supabase/realtime-js": "^1.3.3",
    "ejs": "^3.1.6",
    "express": "^4.17.1",
    "forever": "^4.0.1",
    "pg": "^8.7.1",
    "socket.io": "^4.4.0"
  }
}

How to Run the Project:

Ensure that Docker and Docker Compose are installed on your machine.
Navigate to the root directory of the project and run the following command: docker-compose up --build. This will build the Docker images and start the containers, including Supabase and PostgreSQL.
Install the dependencies and start the project by running: npm install && npm run start-node.
Modify the status_id column in the public.service table to see change logs with both the old and new values in the terminal from step 3. To view the web page with automatic HTML updates, visit: http://localhost:8181.

Github:

github - postgres-realtime

This project offers an intriguing approach to real-time application development, allowing you to trigger various events based on changes in your PostgreSQL database. For instance, you can set up push notifications to alert clients whenever specific changes occur in the database. By creating a dedicated project for real-time actions, you can keep your API or service focused, clean, and straightforward.

I hope this content has been helpful. If you know of other solutions or have experiences to share, please let us know! Let's exchange ideas and learn together. ;)

For any questions, feel free to reach out to me on LinkedIn or Instagram:

There, I share insights about the daily life of a Software Engineer/Entrepreneur.

Thank you for your time, and happy coding! 😊

Best regards,

Vitor Braggion

Realtime PostgreSQL - Escutando o seu banco de dados com Supabase

Vitor Braggion — Mon, 12 Aug 2024 12:53:36 +0000

Fala dev, tudo bem?

Talvez você já deve ter se perguntado como ficar 'escutando' o seu banco de dados para fazer alguma ação na sua aplicação. Seja listando dados em tempo real para o seu usuário, seja escutando alguma alteração em algum dado para disparar algum evento/ação de forma automática (ex: notificação, etc). E qual seria a melhor forma para conseguir isso? Ficar todo momento consultando o banco e vendo se foi realizado alguma alteração? Isso certamente é uma dor de cabeça grande e também com certeza irá gerar uma sobrecarga desnecessária na sua aplicação e no seu banco de dados (já vi na prática empresas fazendo isso e depois de um tempo tempo que refazer boa parte do sistema rsrs) Lembrando que quanto menos IO sua aplicação fizer é melhor, pois o custo de processamento é muito alto. Então é bem importante saber gerenciar bem operações IO.

Há soluções bem simples que não precisamos fazer muitas ações, pois já entregam praticamente pronto. Um exemplo disso é o banco de dados realtime do Firebase, ele consegue abstrair muitas coisas e ficar escutando as mudanças do banco e já entregar para o seu client de forma 'automática'. É muito recomendado o uso dele, muitas pessoas usam para mobiles. Porém pensando em um cenário em que você já tenha o seu banco de dados e realizar essa migração para o Firebase ou essa gestão de duplicação de dados para lá não compense o esforço, talvez simplesmente por algum outro motivo vocês queiram manter o seu banco atual ou queira utilizar o Postgres. E sim, há sim outras alternativas mantendo o seu banco.

Eu irei mostrar para vocês como escutar o seu banco de dados PostgreSQL usando uma biblioteca muito interessante chamada de Supabase, que segundo eles é uma alternativa open-source para o Firebase. Esse projeto já possui vários modulos interessantes, como: Fire Storage, Database Realtime, Authentication/Authorization, Functions, Auto-generated APIs, etc. Nele iremos usar o seu modulorealtime.

Mas antes de simplesmente colocar a mão no código, implementar a lib e fingir que tudo acontece como uma mágica, vamos primeiro entender um pouco melhor sobre esse projeto e como ele funciona e quais são os conceitos utilizados por trás dele. Esse projeto é um servidor construido com a linguagem Elixir usando o framework Phoenix, que permite você escutar e replicar mudanças no seu banco de dados PostgreSQL através de logical replication.

Mas afinal, o que é esse tal de logical replication?

Resumidamente logical replication é um método de replicar dados, seja o dado completo ou suas mudanças, para um outro lugar. Geralmente é utilizado um publish e subscribe node, onde o publisher é responsável por "coletar" um conjunto de mudanças de uma ou mais tabelas (publication) e o subscriber que é responsável por 'assinar' ou 'colecar' as publications.

E pensando no cenário de um banco de dados, vai se referir em replicar dados entre dois ou mais banco de dados. **Ele vai capturar as mudanças feitas no banco (ex: INSERTS, UPDATES, DELETES, etc) em uma camada do banco de dados e enviar essas mudanças para os banco de dados que ele queira (targets).

Geralmente isso é feito através de WAL, Write-ahead logging, que é basicamente para escrever logs antes de excutar uma tarefa. Essa técnica garante integridade, atomicidade, durabilidade, entre vários outros benefícios (Muito utilizado em sistemas baseados em eventos). Ou seja, em um cenário de banco dados, quaisquer mudança no arquivo do banco que se refere aos dados, primeiramente terá que ser feito o log, assim que logado, irá fazer a alteração no arquivo do banco de dados.

Mas voltando ao foco principal, vamos começar implementar um pequeno projeto para testarmos o Supabase e como 'escutar' nosso banco de dados. Com isso, vamos criar um projeto em que iremos listar todos os serviços de acordo com seu status (pendente, em andamento e concluído), e obviamente sem ficar consultando várias vezes o banco de dados para ver se houve alguma modificação, queremos que nossa aplicação seja realtime, qualquer alteração que houver, ele precisa ser atualizado imediatamente. *Em um projeto maior, isso pode tirar uma carga enorme do banco de dados.

Então basicamente, iremos utilizar o Supabase realtime para escutar todas as modificações do nosso banco de dados e enviá-las para a nossa aplicação NodeJS, em que essa aplicação irá gerenciar esses dados modificados e enviar para os clients via WebSocket.

Vou adicionar as principais partes do projeto e explicar elas. E no final disponibilizarei o link do repositório, em que poderá ver o código completo do projeto.

ESTRUTURA DO PROJETO

Essa será nossa estrutura do projeto, abaixo há detalhes das principais partes:

/docker-compose.yml: Esse arquivo é a configuração do Docker Compose em que teremos as configurações de dois containers. Um para utilizar o Supabase Realtime, ele que será responsável por ficar escutando qualquer alteração no banco de dados. E um outro container que será nosso banco de dados Postgres.

version: '3'

services:
  realtime:
    image: supabase/realtime:v1.0.0
    ports:
      - "4000:4000"
    environment:
      DB_HOST: postgres-realtime_db_1
      DB_NAME: postgres
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_PORT: 5432
      PORT: 4000
      # JWT_SECRET: SOMETHING_SUPER_SECRET
      SECURE_CHANNELS: 'false'
    networks:
      - realtime-network
    depends_on:
      - db

  db:
    build: database/.
    restart: always
    environment: 
      POSTGRES_PASSWORD: postgres
    ports:
      - "5432:5432"
    networks:
      - realtime-network

networks:
  realtime-network:
    driver: bridge

/database: Essa pasta terá as configurações do Docker para o nosso banco de dados e configurações do banco para conseguirmos escutá-lo em realtime.

Essa será nossa estrutura do banco de dados:

/database/Dockerfile: Esse arquivo do docker irá ser chamado pelo docker-compose.yml e irá utilizar uma imagem do Postgres e rodar um arquivo (/database/scripts/00-init.sql) com os scripts para criar nossas tabelas no banco de dados e realizar algumas configurações necessárias para que o Supabase consiga escutar as mudanças em nosso banco de dados.

/database/scripts/00-init.sql: Esse arquivo possui o código para criamos as tabelas do nosso banco de dados e as configurações necessárias para que o Supabase consiga escutar as mudanças em nosso banco de dados.

Script para criar as tabelas e inserir dados:


CREATE TABLE public.status (
  id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  name VARCHAR(255
);
INSERT INTO 
    public.status (name) 
VALUES 
    ('PENDDING'),
    ('IN_PROGRESS'),
    ('CONCLUDED')

CREATE TABLE public.service (
  id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  status_id bigint REFERENCES public.status NOT NULL
);

INSERT INTO 
    public.service (name, status_id)
VALUES 
    ('Reboque', 1),
    ('Bateria', 3),
    ('Pane Seca', 1),
    ('Troca de Luz', 2);

O Supabase utliza o WAL para capturar as modifições no nosso banco. Então antes precisamos configurar algumas coisas em nosso banco de dados, para que o Supabase Realtime consiga trabalhar.

-- adds information necessary to support logical decoding.
-- Each level includes the information logged at all lower levels.
ALTER SYSTEM SET wal_level='logical'; 

-- Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients
-- (i.e., the maximum number of simultaneously running WAL sender processes). 
-- 10 already is the default value
-- RECOMMENDATIONS: If you are replicating, you want to set this to the maximum number of standby servers you mighy possibly have
-- Performance impact when set above zero, but no additional penalty for setting it higher.s
ALTER SYSTEM SET max_wal_senders='10'; 

-- Specifies the maximum number of replication slots (see streaming-replication-slots) that the server can support
-- 10 already is the default value
ALTER SYSTEM SET max_replication_slots='10';

-- Create the Replication publication 
CREATE PUBLICATION supabase_realtime FOR ALL TABLES;

-- Send the previus values
ALTER TABLE public.service REPLICA IDENTITY FULL;
ALTER TABLE public.status REPLICA IDENTITY FULL;

*Todas essas configurações são necessárias, e todas elas estão feitas de acordo com o projeto que iremos criar. Por exemplo, mencionando as tabelas do nosso projeto. Em nosso projeto final, adicionei essas configurações e o script de criação das nossas tabelas para serem executadas de forma automática ao inciar nosso docker.

/server : Dentro dessa pasta terá os códigos do nosso projeto que será responsável por receber as modificações que o Supabase Realtime identificou e mandar para o nosso client via websocket.

Dentro desse 'projeto’ teremos tudo muito bem separado de acordo com suas responsabilidades.

/server/services/ : Terá todos os nosso serviços que iremos utilizar em nosso projeto.

Database: responsável por realizar queries em nosso banco. Iremos utilizá-lo somente quando iniciar o projeto. Pois iremos buscar todos os nossos dados no banco para assim depois só atualizar as mudanças que acontecerem.

const pg = require('pg');

class Database {
  pgPool;
  pgClient;

  constructor() {
    this.pgPool = new pg.Pool({
      host: '0.0.0.0',
      user: 'postgres',
      password: 'postgres',
      database: 'postgres',
      port: 5432,
    });
  }

  async connect() {
    try {
      this.pgClient = await this.pgPool.connect();
    } catch (error) {
      console.log('Connection error' , error)
    }
  }

  async query({ text, params }) {
    const res = await this.pgClient.query(text, params);

    return res;
  }

  disconnect() {
    this.pgClient.release();
  }

  async disconnectPool() {
    await this.pgPool.end();
  }
}

module.exports = Database;

DatabaseListener: responsável por escutar as mudanças que o Supabase identificar do nosso banco dados. Utilizaremos a lib @supabase/realtime-js para nos ajudar.

const { RealtimeClient } = require('@supabase/realtime-js'); // "@supabase/realtime-js": "^1.3.3",

class DatabaseListener {

    // creating the connection with our supabase realtime, it's running on docker at port 4000
  socket = new RealtimeClient(process.env.REALTIME_URL || 'ws://localhost:4000/socket');

  constructor() {
      // when start our DatabaseListner, we'll connect and listen our connection
    this.socket.connect();

    this.socket.onOpen(() => console.log('Socket opened.'));
    this.socket.onClose(() => console.log('Socket closed.'));
    this.socket.onError((e) => console.log('Socket error', e.message));
  }

    // generic method to listen our database by channel
  _on(eventName, callback, channel = '*') {
    const databaseChanges = this.socket.channel(`realtime:${channel}`);

    databaseChanges.on(eventName, (e) => {
      console.log('EVENT', e);
      callback(e);
    });
    databaseChanges.subscribe();
  }

    // method to listen all modifications from our database (update, insert, delete') by channel
  onAll(callback, channel = '*') {
    this._on('*', callback, channel);
  }

    // method to listen updates events in our database by channel
  onUpdate(callback, channel = '*') {
    this._on('UPDATE', callback, channel);
  }

    // method to listen inserts events in our database by channel
  onInsert(callback, channel = '*') {
    this._on('INSERT', callback, channel);
  }

    // method to listen deletes events in our database by channel
  onDelete(callback, channel = '*') {
    this._on('DELETE', callback, channel);
  }
}

module.exports = DatabaseListener;

Socket: responsável por gerenciar o socket que teremos com o nosso client (frontend em nosso caso) para enviar as modificões do banco de dados.

const socket = require('socket.io'); // "socket.io": "^4.4.0"

class Socket {

  io = null;

  constructor(server) {
      // starting socket server
    this.io = socket(server);
  }

  getIo() {
     // method to get the socket connection
   return this.io; 
  }

    // method listen the socket connection 
  onConnection(callback) {
    console.log(`Connected socket ${socket.id}`);

    this.io.on('connection', (socket) => {
      callback(socket);
    });
  }

    // emit an event with some data to our clients
  sendToAllSubscribers(eventName, data) {
    this.io.emit(eventName, data);
  }

}

module.exports = Socket;

/server/models/ : Terá todos os modelos para interagirmos com as nossas tabelas do nosso banco dedados. Será separado por tabela, como só iremos interagir com o 'Services’, então só teremos ela.

Service: Esse arquivo irá realizar uma conexão com o nosso banco de dados e buscar todos os serviços e seus status. Será chamado somente ao iniciar o código, pois iremos buscar todos os dados e depois ficar só escutando as mudanças, assim evitando de ir no banco de dados várias vezes.

const Database = require('../../services/Database');

class Service {

    // Don't allow instance this class, it'll be possible just use static methods
  constructor() {
    throw new Error('It is not instantiable')
  }

    // method to fetch all services in our database. We'll use this method when our server start
  static async findAll() {
    let servicesFound = [];

    try {
      const database = new Database();
      await database.connect();

      const result = await database.query({
        text: 'SELECT * FROM public.service',
        params: []
      });

      servicesFound = result?.rows || [];

    } catch (error) {
      console.log(error);
    }

    return servicesFound;
  }

}

module.exports = Service;

/server/controllers : Terá as regras de negócio para fazer o projeto acontecer. Irá utilizar os models e os services do projeto. No nosso caso só teremos um controller.

ServiceController: Nesse controller iremos buscar todos os ‘Services’ do nosso banco de dados e enviar para o nosso client via websocket e iremos ficar escutando quaisquer mudança no banco de dados, e caso haja alguma, enviaremos essa mudança para os clients via websocket.

const DatabaseListener = require('../../services/DatabaseListener');
const Service = require('../../models/Service');

// variable to help us to map our services by status
const helperToServiceMapStatus = {
  1: 'servicesPendding',
  2: 'servicesInProgress',
  3: 'servicesConcluded'
};

class ServiceController {

    // instance of ous Database Listener
  static databaseChanges = new DatabaseListener();
  // arrays that our services in database will be saved by status. It'll be saved in memory and it'll send for our clients by socket
  // warn: all services will be saved in memory, so you should be alert about the size of these list. Maybe in a production it's better you save it in a kind of database, like redis
  static servicesDto = {
    servicesPendding: [],
    servicesInProgress: [],
    servicesConcluded: []
  };

    // don't allow instance this class, it'll be just allowed use static methods
  constructor() {
    throw new Error('It is not instantiable')
  }

    // method to fetch all service from database, separe it by status and send to our clients by socket
  static async fetchServicesFromDatabaseAndSend(socket) {
    const servicesFound = await Service.findAll();

    servicesFound.map(service => {
      const serviceKey = helperToServiceMapStatus[service.status_id];
      ServiceController.servicesDto[serviceKey].push(service);
    });

    socket.onConnection((_socket) => {
      console.log(`Socket connection `, _socket.id);
      socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
    })
  }

    // listing all service status update in our database, then send it to our clients by socket
  static listenAndSendServicesStatus(socket) {

            // listing updates in our table 'service' in the public schema with status_id equals 1
      ServiceController.databaseChanges.onUpdate((e) => {
        ServiceController._managementState(e.old_record, e.record);
        socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
      }, 'public:service:status_id=eq.1');

            // listing updates in our table 'service' in the public schema with status_id equals 2
      ServiceController.databaseChanges.onUpdate((e) => {
        ServiceController._managementState(e.old_record, e.record);
        socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
      }, 'public:service:status_id=eq.2');

            // listing updates in our table 'service' in the public schema with status_id equals 3
      ServiceController.databaseChanges.onUpdate((e) => {
        ServiceController._managementState(e.old_record, e.record);
        socket.sendToAllSubscribers('receivedMessage', ServiceController.servicesDto);
      }, 'public:service:status_id=eq.3');
    }

    // method to help us to manage our data that we're sending our client 
  static _managementState(oldRecord, newRecord) {
      const oldService = helperToServiceMapStatus[oldRecord.status_id];
      const newService = helperToServiceMapStatus[newRecord.status_id];

      ServiceController.servicesDto[oldService] = ServiceController.servicesDto[oldService].filter(_service => (_service.id != oldRecord.id));
      ServiceController.servicesDto[newService].push(newRecord);
    }

}

module.exports = ServiceController;

/server/src/server.js : Será onde iremos configurar nosso servidor para rodar o nosso frontend utilizando express e além disso iniciar nosso projeto backend.


const express = require('express'); //"express": "^4.17.1",
const path = require('path');
const app = express();
const server = require('http').createServer(app);
const Socket = require('../services/Socket');
const ServiceController = require('../controllers/ServiceController');

app.use(express.static(path.join(__dirname, '../../public')));
app.set('views', path.join(__dirname, '../../public'));
app.engine('html', require('ejs').renderFile);
app.set('view engine', 'html');

app.use('/public', (req, res) => {
  res.render('index.html');
});

(async () => {
    // starting our socket
  const socket = new Socket(server);

    // fetching our all database data and sending to our clients by socket
  ServiceController.fetchServicesFromDatabaseAndSend(socket);
  // listing our database changes and sending it to our clients by socket
  ServiceController.listenAndSendServicesStatus(socket);
})();

server.listen(8181);

/public/index.html : Nosso projeto frontend, em que terá um simples layout em que irá listar nossos serviços no banco de dados de acordo com o seu status. Ele irá abrir uma conexão de socket com o nosso backend para que o backend consiga enviar as mudanças de status que teremos em nossos serviços.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Services</title>
</head>
<body>
  <h2>Pendding Services</h2>
  <ul id="pendding"></ul>
  <br><br>

  <h2>In Progress Services</h2>
  <ul id="inProgress"></ul>
  <br><br>

  <h2>Concluded Services</h2>
  <ul id="concluded"></ul>
  <br><br>

</body>
<script type="module">
  import { io } from "https://cdn.socket.io/4.4.0/socket.io.esm.min.js";

  const socket = io('http://localhost:8181');
  const htmlPendding = document.getElementById('pendding');
  const htmlInProgress = document.getElementById('inProgress');
  const htmlConcluded = document.getElementById('concluded');

  socket.emit('sendMessage', {
    text: 'working'
  });
    // listing our socket to receive our data
  socket.on('receivedMessage', (data) => {
    htmlPendding.innerHTML = '';
    htmlInProgress.innerHTML = '';
    htmlConcluded.innerHTML = '';


        // putting our socket data in its specific group
    const { servicesPendding, servicesInProgress, servicesConcluded } = data;

    servicesPendding.map(service => {
      console.log('service', service);
      const item = document.createElement('li');
      item.textContent = service.name;
      htmlPendding.appendChild(item);
      window.scrollTo(0, document.body.scrollHeight);
    });

    servicesInProgress.map(service => {
      const item = document.createElement('li');
      item.textContent = service.name;
      htmlInProgress.appendChild(item);
      window.scrollTo(0, document.body.scrollHeight);
    });

    servicesConcluded.map(service => {
      console.log('service concluded', service);
      const item = document.createElement('li');
      item.textContent = service.name;
      htmlConcluded.appendChild(item);
      window.scrollTo(0, document.body.scrollHeight);
    });

  });
</script>
</html>

/package.json:

{
  "name": "realtime-pg",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "start": "forever -w --minUptime 2000 --spinSleepTime 2000 server/src/server.js",
    "start-node": "node server/src/server.js"
  },
  "dependencies": {
    "@supabase/realtime-js": "^1.3.3",
    "ejs": "^3.1.6",
    "express": "^4.17.1",
    "forever": "^4.0.1",
    "pg": "^8.7.1",
    "socket.io": "^4.4.0"
  }
}

Como rodar o projeto:

Garantir que você possui o Docker e o Docker Compose instalados em sua máquina;
Depois rodar na raiz do projeto o seguinte comando docker-compose up —-build . Isso irá buildar o docker e iniciar os containers. Irá subir o container do Supabase e um dos nosso banco de dados Postgres.
instalar as dependencias e rodar o código para inciar o nosso projeto. Você pode rodar o seguinte comando npm install && npm run start-node .
Agora faça alterações na coluna status_id da tabela public.service e você conseguirá ver os logs de modificações com o valor antigo e novo valor alterado pelo terminal do item 3. Caso queira visualizar a nossa página web atualizando o html automaticamente, você pode acessar o link: http://localhost:8181.

Github:

https://github.com/VitorBrangioni/postgres-realtime

Esse projeto é algo bem interessante para pensarmos em nossa aplicação em realtime, podendo disparar vários eventos de acordo com qualquer mudança em nosso banco de dados Postgres. Como por exemplo, enviar um push notification para um client sempre que acontecer determinada mudança no banco. Então poderiamos criar um projeto isolado só para essas ações em realtime, deixando nossa api ou um determinado serviço com regras mais simples, limpas e focadas.

Espero que esse conteúdo tenham ajudado vocês de alguma forma, caso tenham alguma outra soluções que vocês conhecem que possa nos ajudar, por favor, compartilhe e vamos trocar experiência! ;) l

E qualquer dúvida, estou a disposição no meu Linkedin ou no meu Instagram: - - https://www.linkedin.com/in/vitorbrangioni/

https://www.instagram.com/vitorbrangioni.dev/

Lá irei contar mais sobre o dia a dia de um Engenheiro de Software/Empreendedor.

Obrigado pelo seu tempo e bons códigos! 😊

Leading and Retaining Developers

Vitor Braggion — Wed, 07 Aug 2024 15:28:26 +0000

It is clear how much companies strive to retain software engineers, developers, data scientists, and other technology professionals. They try to make the work environment as cool as possible by providing in-office amenities like popcorn machines, various snacks, fridges stocked with beer and soda, ping-pong tables, video games, bean bags, and even offering to pay for technology courses, English lessons, access to Netflix, Spotify, and many other attractive benefits.

But is all this effort rewarded? Do they really manage to retain their tech teams? There is data showing that despite these incredible benefits and offices that look more like playgrounds, tech companies struggle to retain their tech professionals. There are always developers leaving to start a new journey at another company, and new people come in.

You might not expect it, but even giant companies in the sector, like those on the Fortune 500 list, tend to suffer from high turnover rates. Google, for example, has an average employee tenure of 1.1 years, even though many developers dream of working there. At Amazon, this "tenure" is only one year. Apple has the best turnover rate among tech companies, with an average tenure of just two years. We can see details of this information in the employee turnover report from Payscale and the LinkedIn report, which reveals that the tech sector has the highest turnover rates. But why this high turnover?

I don't know the answer, but I believe factors such as the high demand for tech jobs with high salaries and the interest of young professionals in different technical challenges and new work environments explain part of this "traffic". The search for companies that align with their personal values and enjoy change may also justify this movement of young professionals within tech companies.

Every entrepreneur and manager knows how detrimental high turnover is for a company. They spend time and resources to find/hire, then for training, and it takes time for the new employee to truly deliver the expected value. It is difficult to control this turnover, but good leadership is crucial in helping retain talent. Here are some tips I've learned in practice, working in various places, starting my own startups, reading many books, and learning from great leaders:

"I believe that good leadership can help creative people stay on the path to excellence, no matter the business they are in." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

1. Give autonomy to your team members

****Many managers tend to centralize everything, wanting it done their way. Don't make this mistake. Believe in your team's potential, give them the autonomy to choose the best solution for something and solve problems.

"I believe managers must loosen the controls, not tighten them. They must have the ability to trust those they work with and to accept risks. They must pay attention to and engage anything that creates fear." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

2. Don't impose, make them question**

When you give your team members the freedom to think of the best solution to a problem or suggest something, if a solution or suggestion doesn't make sense in your view and you think it's better not to do it as suggested, don't just impose something, make them reflect on the decision, raise arguments for why you think it's not the best choice and make them interact and think about the solution. If your argument really makes sense, it's likely they'll start agreeing with you.

Many people say that Steve Jobs liked and listened more to those who defended their ideas because he believed that if someone defended something so strongly, it was because they had a strong foundation for it. So don't be upset if someone defends their idea. Listen and try to understand as well; it might be a much better solution.

3. Leaders create leaders**

Help employees improve themselves professionally and personally. Create a culture where the goal is for everyone to improve themselves and help each other. This attitude will build a network of leaders in your company, where each one will form new leaders. If this happens, your work environment will definitely improve.

4. Create self-managing Squads, without defining a leader**

Follow agile development principles. Create small teams with complementary profiles (instead of defining a leader) and set goals for this squad. Over time, this squad will organically form a leader who will guide everyone towards the same goal. A leader is created by examples, not titles. The one who has the best example and is best at serving will be followed by the team. We can observe that when we have to do group work, a leader always emerges, even when it comes to children. In the nature as animal's group, a leader also emerges organically. This is natural.

"Getting the right people and the right chemistry is more important than getting the right idea." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

5. People like recognition**

Show each team member that they are important and that they belong to the team because you believe in their potential. Sometimes there's no need to say it, just with small gestures, this belonging will be understood. Simple gestures, like listening to them and including them in important decisions, help with this challenge.

When you recognize a skill in someone, it makes them feel good about themselves. Consequently, this will make them like you and will improve the work environment, as people will work happily and motivated, transmitting this energy to other members of the company.

6. Developers like technical challenges**

So far, I've never met a professional in the tech field who doesn't like technical challenges. If you find someone who doesn't, they probably don't like the field (laughs). Everyone likes to surpass themselves and learn more. I like to say that a technical challenge is like solving a puzzle: if you solve an easy puzzle, you'll get bored. But if it's difficult, where you have to think a lot, then this challenge will captivate you, and you'll probably spend nights trying to solve it or sleep thinking about it.

Being in a technically challenging environment is very similar to the state of flow, which is that state where we are extremely focused and motivated, spending hours doing something without noticing the time passing.

7. Give your team freedom and remember that everyone has a personal life

Give your team the freedom to:

Work at the time they find best; everyone has times when they can perform better. Obviously without misaligning with the rest of the team. Work from wherever they feel best, be it a specific place or with someone they have more affinity with. Choose their vacation dates. Obviously, without disrupting the progress of a project.

I developed these tips based on what I've read and experienced in practice. I worked at many companies as a developer that gave me total work freedom, greater technical challenges, and recognition, and others that gave practically none of these points I mentioned. Personally, at those that gave me this freedom, I worked with much more pleasure, always producing more than asked, and felt completely happy. This happiness was like fuel to work more efficiently and effectively. I even turned down offers from companies that offered me a much higher salary.

When I started my tech company, I kept in mind that I would try to create a pleasant environment. With that, as new developers joined, I applied these learnings and, as a result of this stance, I saw developers resembling me at that time and as motivated as I was in that pleasant environment. Everyone involved in a greater cause always delivered more than we asked, gave many amazing suggestions that we started to use, and ended up creating an environment of total knowledge sharing, with one passing content to others. It was incredible to see this happening in practice.

I hope you enjoyed it!

Regards,
Vitor Braggion

Liderando e retendo desenvolvedores

Vitor Braggion — Tue, 06 Aug 2024 16:42:24 +0000

É nítido o quanto as empresas se esforçam para reter engenheiros de softwares, desenvolvedores, cientistas de dados e outros profissionais de tecnologia. Tentam deixar o ambiente de trabalho o mais legal possível, colocando, dentro do escritório, máquina de pipoca, vários salgadinhos, frigobar com cerveja e refrigerante, mesa de pingue-pongue, videogame, puffs e ainda oferecem pagar cursos de tecnologia, inglês, acesso à Netflix, Spotify e vários outros benefícios atraentes.

E será que todo esse esforço é recompensado? Conseguem realmente reter seu time de tecnologia? Há dados que comprovam que, apesar desses incríveis benefícios e escritórios que parecem mais playgrounds, as empresas de tecnologia não conseguem reter seus profissionais de tecnologia. Sempre há desenvolveres saindo para começar uma nova jornada em outra empresa e assim entram novas pessoas.

Você pode não esperar, mas as empresas gigantes do setor, como as que figuram na lista Fortune 500 também tendem a sofrer com altas taxas de rotatividade. O Google, por exemplo, possui um tempo médio de permanência de profissional no grupo de 1,1 ano e olha que muitos desenvolvedores sonham em trabalhar no Google. Na Amazon esse “tempo de casa” é de apenas um ano. A Apple tem o melhor indicador de rotatividade entre as empresas de tecnologia, com apenas dois anos de permanência. Podemos ver detalhes dessa informação com o relatório de rotatividade de funcionários da Payscale e o relatório do linkedin que revela que o setor de tecnologia é o que mais possuI rotatividade de profissionais. Mas por que essa alta rotatividade?

Não sei a resposta, mas acredito que fatores como a alta demanda por trabalhos de tecnologia com a oferta de salários altos e o interesse de jovens profissionais por desafios técnicos diferentes e por novos ambientes de trabalho justificam parte desse “trânsito”. A busca por empresas que tenham alinhamento com seus valores pessoais e que gostam de mudanças pode justificar, também, esta movimentação de jovens profissionais no quadro de pessoal das empresas de tecnologia.

Todo empreendedor e gestor sabe como é ruim a alta rotatividade de profissionais para a empresa. Gastam tempo e recursos para encontrar/contratar, depois para treinamentos, além de demorar para que o novo funcionário consiga realmente entregar o valor esperado pela empresa. É difícil controlar essa rotatividade, mas uma boa liderança é crucial para ajudar na retenção de talentos. Seguem algumas dicas que aprendi na prática, trabalhando em vários lugares, construindo a minha própria empresa, lendo muitos livros e aprendendo com grandes líderes:

"Acredito que uma boa liderança pode ajudar pessoas criativas a permanecerem no caminho para a excelência, não importando o negócio em que elas estão." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

Deem autonomia para os membros do seu time

Muitos gestores tendem a centralizar tudo neles, quererem que façam do seu jeito. Não cometa esse erro. Acredite no potencial do seu time, dê a eles autonomia para escolher a melhor solução para algo e resolver problemas.

"Acredito que os gerentes devam afrouxar os controles, e não apertá-los. Eles devem aceitar riscos; devem confiar nas pessoas com quem trabalham e lutar para abrir o caminho para elas; e devem sempre prestar atenção e enfrentar qualquer coisa que gere medo. Além disso, os líderes bem-sucedidos aceitam a realidade de que seus modelos podem estar errados ou incompletos. Só quando admitimos não saber algo é que podemos aprender." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

Não imponha, faça-os questionar

Quando você dá liberdade para os membros do seu time pensarem na melhor solução para um problema ou dar sugestões sobre algo. Se uma solução ou sugestão não fizer sentido na sua visão e acha melhor não fazer do jeito sugerido, então simplesmente não imponha algo, faça-o refletir sobre a decisão, levante argumentos do motivo pelo qual você acha que não é a melhor escolha e faça-o interagir e pensar sobre essa solução. Se o argumento que você der realmente fizer sentido, é provável que ele comece a concordar com você.

Muitos dizem que Steve Jobs gostava e dava mais ouvido para aqueles que defendiam sua ideia, pois ele acreditava que se alguém defendesse algo com tanta força é porque realmente tinha um embasamento forte sobre isso. Então não ache ruim se alguém defender sua ideia. Ouça e tente entender também, talvez seja uma solução muito melhor.

Líderes criam líderes

Ajude os colaboradores a crescerem profissionalmente e como pessoa. Crie uma cultura em que o objetivo é que todos cresçam e ajudem uns aos outros. Essa atitude formará uma rede de líderes em sua empresa, em que cada um formará novos líderes. Acontecendo isso, com certeza seu ambiente de trabalho irá melhorar.

Crie Squads autogerenciáveis, sem definir um líder

Siga princípios do desenvolvimento ágil. Crie pequenas equipes com perfis complementares (ao invés de definir um líder) e dê metas para esse squad. Com o tempo, esse squad formará um líder de forma orgânica e o mesmo guiará todos em busca do mesmo objetivo. Um líder é criado por exemplos e não por títulos. O que tiver o melhor exemplo e for melhor em servir, a equipe o seguirá. Podemos observar que, quando temos que fazer um trabalho em grupo, sempre surge um líder, mesmo quando se trata de crianças. Em grupo de animais também surgem um líder de forma orgânica. Isso é da natureza.

"É fácil dizer que você quer pessoas talentosas, mas a maneira pela qual elas interagem umas com as outras é o segredo. Até mesmo as pessoas mais inteligentes podem formar uma equipe ineficaz se forem incompatíveis. Isso significa que é melhor se concentrar em como uma equipe está se desempenhando, e não nos talentos dos seus membros. Uma boa equipe é feita de pessoas que se complementam umas às outras." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

Pessoas gostam de reconhecimento

Mostre para cada membro do seu time que ele é importante, e que pertence à equipe porque acredita em seu potencial. Ás vezes não há necessidade de falar, apenas, com pequenos gestos, esse pertencimento ficará subentendido. Gestos simples, como ouví-las e incluí-las em decisões importantes ajudam nesse desafio.

Quando você reconhece uma habilidade em uma pessoa, faz com que ela se sinta bem consigo mesma. Em consequência, isso fará com que ela goste de você e irá melhorar o ambiente de trabalho, pois as pessoas irão trabalhar felizes e motivadas, transmitindo esse energia para outros integrantes da empresa.

Desenvolvedores gostam de desafios técnicos

Até hoje não conheci nenhum profissional da área de tecnologia que não goste de desafios técnicos. Se encontrar algum que não goste, provavelmente essa pessoa não gosta da área (risos). Todos gostam de se superar e aprender mais. Gosto de falar que um desafio técnico é como montar um quebra cabeça: se você for montar um quebra cabeça fácil, ficará entediado. Mas se for difícil, em que terá que pensar muito, então, esse desafio te prenderá e, provavelmente, virará noites tentando resolvê-lo ou dormirá pensando nele.

Estar num clima de desafio técnico é muito parecido com o estado de flow, que é aquele estado em que estamos com extremo foco e motivação, passamos horas fazendo algo e não percebemos o tempo passar.

Dê liberdade a sua equipe e lembre-se que cada um tem uma vida pessoal

Dê liberdade para a sua equipe, como:

Trabalhar no horário que ela achar melhor, sempre há horários que cada um consegue performar melhor. Obviamente sem desalinhar com o resto da equipe.
Trabalhar de onde quiser, onde ela se sinta melhor, seja em algum lugar específico ou com alguém que ela tenha mais afinidade.
Liberdade para escolher a data de suas férias. Obviamente, sem atrapalhar o andamento de algum projeto.

Elaborei essas dicas a partir do que li muito e sobre o que vivenciei na prática. Trabalhei em algumas empresas como desenvolvedor, que me deram total liberdade de trabalho, desafios técnicos maiores e reconhecimento. E outras que não deram praticamente nada desses pontos que mencionei. Particularmente, nas que me deram essa liberdade, trabalhei com muito mais prazer, sempre produzindo além do que pediam e me sentia completamente feliz. Essa felicidade era como um combustível para trabalhar mais e com maior eficiência e eficácia. Cheguei até a recusar convites de empresas que me ofereceram um salário muito maior.

Quando montei a minha empresa de tecnologia, mantive na cabeça que iria tentar montar um ambiente agradável. Com isso, à medida em que entravam novos desenvolvedores, apliquei esses aprendizados e, em consequência dessa postura, estava vendo os desenvolvedores parecidos comigo na época e tão motivados quanto eu estava nessa empresa de ambiente agradável. Todos envolvidos por uma causa maior, entregavam sempre a mais do que pedíamos, davam várias sugestões incríveis que passamos a utilizar e acabou criando um ambiente de total compartilhamento de conhecimento, um passando conteúdos para os outros. Foi incrível ver isso acontecendo na prática.

Espero que tenham gostado!

Abraços,
Vitor Braggion

-
Linkedin: https://www.linkedin.com/in/vitorbrangioni/
GitHub: https://github.com/VitorBrangioni

Liderando e retendo desenvolvedores

Vitor Braggion — Tue, 06 Aug 2024 16:42:24 +0000

"Acredito que uma boa liderança pode ajudar pessoas criativas a permanecerem no caminho para a excelência, não importando o negócio em que elas estão." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

Deem autonomia para os membros do seu time

"Acredito que os gerentes devam afrouxar os controles, e não apertá-los. Eles devem aceitar riscos; devem confiar nas pessoas com quem trabalham e lutar para abrir o caminho para elas; e devem sempre prestar atenção e enfrentar qualquer coisa que gere medo. Além disso, os líderes bem-sucedidos aceitam a realidade de que seus modelos podem estar errados ou incompletos. Só quando admitimos não saber algo é que podemos aprender." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

Não imponha, faça-os questionar

Líderes criam líderes

Crie Squads autogerenciáveis, sem definir um líder

"É fácil dizer que você quer pessoas talentosas, mas a maneira pela qual elas interagem umas com as outras é o segredo. Até mesmo as pessoas mais inteligentes podem formar uma equipe ineficaz se forem incompatíveis. Isso significa que é melhor se concentrar em como uma equipe está se desempenhando, e não nos talentos dos seus membros. Uma boa equipe é feita de pessoas que se complementam umas às outras." - Ed Catmull, co-founder of Pixar and president of Walt Disney Animation Studios

Pessoas gostam de reconhecimento

Desenvolvedores gostam de desafios técnicos

Dê liberdade a sua equipe e lembre-se que cada um tem uma vida pessoal

Dê liberdade para a sua equipe, como:

Trabalhar no horário que ela achar melhor, sempre há horários que cada um consegue performar melhor. Obviamente sem desalinhar com o resto da equipe.
Trabalhar de onde quiser, onde ela se sinta melhor, seja em algum lugar específico ou com alguém que ela tenha mais afinidade.
Liberdade para escolher a data de suas férias. Obviamente, sem atrapalhar o andamento de algum projeto.

Espero que tenham gostado!

Abraços,
Vitor Braggion

-
Linkedin: https://www.linkedin.com/in/vitorbrangioni/
GitHub: https://github.com/VitorBrangioni

Prioritizing Concurrent Requests: Queuing system to handle distributed processes and messages with NodeJS and Bull

Vitor Braggion — Fri, 15 Mar 2024 19:01:23 +0000

Hey devs! How's it going?

My name is Vitor Braggion, I'm the Co-Founder and responsible for the technology at ufrilla.

A while ago, we had a little technical issue.

For those who don't know, ufrilla is a startup that connects people who want to work as freelancers in the events industry with event producers, in a very simple way. Besides helping these producers manage and operate everything, which is a real headache.

The problem was this: The client opens a specific number of positions on our platform, and freelancers show interest in working. Then the manager selects the people they want to work at their event, and the first ones to confirm will actually work. For example: If the company opens 5 Bartender positions, they can select from over 100 interested people, but only the first 5 to confirm will work.

As the number of users started growing significantly (+35k users at the time), there were often freelancers confirming for the position at the same time, resulting in simultaneous requests. To check if there are still available positions, we have to check the number of confirmed people in the database and verify if the positions have been filled. If there's still availability, we confirm their participation. Now imagine several of these requests being processed at the same time, or in a very short interval, it's like multiple requests checking for availability at the same time, and upon verification, all find availability. So after confirming availability, they all confirm participation in the position.

For example: We have 1 position available, and 5 people confirm participation simultaneously. So we have 5 different requests to confirm the position, but all these requests check in database that there is availability, all at the same time. Since they all verified availability, they will all confirm participation. In the end, all five freelancers will be confirmed for one position, instead of just one person.

This problem gave our team a headache and probably for the freelancers as well, as we had to cancel with the freelancers who were already planning their entire day (or should have been, haha) to work, and still manually.

The solution I found to solve this problem was to implement queues in the API endpoint to confirm participation in the position. While one request was being processed, the others would be in line waiting for the processing of the current request to be completed before being processed. Following the queue rule, which is priority over arrival order (First in, first out - FIFO).

To facilitate understanding of the problem, the solution, and to be able to apply it in various contexts, I will create a very simple example. Let's solve the following: we have to retrieve a value from the database and add +1 to this value and save it again. For example: If the number in the database starts with 0 (zero) and the API receives a thousand requests, then in the end, the number in the database will be a thousand. But what if these requests are simultaneous? Will the final value be correct?

Let's start implementing this solution without queues and see what happens. But before that, I'll provide the database modeling and script for us to send several simultaneous requests to the API.

Note: I created a NodeJS API to receive and process requests, with endpoints to 'add +1' with queue and without queue. I won't show the code about the API architecture here, as it's not the focus, but rather the key code about our solution. If you want to view the entire code, I'll provide the GitHub link.

DATABASE MODELING

CODE TO SEND SO MULTIPLE REQUESTS SIMULTANEOUSLY

const axios = require("axios"); // package to send our requests
const host = "http://localhost:3000/api/count";
const endpointWithQueue = `${host}/add-queue`; // endpoint with queue
const endpointWithoutQueue = `${host}/sum`; // endpoint without queue
const nReqs = 500; // number of the requests to send
const reqs = []; // arrau to put our requests
// Preparing the requests array
for (let i = 0; i < nReqs; i++) {
  reqs.push(axios.post(endpointWithQueue, { sum: 1 })); // altere qual endpoint você quer testar, com fila ou sem fila.
}
// Sending all requests simultaneosly
Promise.all(reqs).then(
  (_) => console.log("SUCESSO! Todas as requisições foram enviadas."),
  (err) => console.log(err)
);

SOLUTION WITHOUT QUEUE

API endpoint to call the method 'sum +!1’:

router.post('/sum', (req, res) => {
    controller.sum(req, res)
});

Method to sum +1 in the column 'sum’ from database:

const { Count } = require("./../../config/models");
exports.sum = async (req, res) => {
  let { sum } = req.body;
  this._sum(sum)
    .then((_) => res.sendStatus(200))
    .catch((err) => res.sendStatus(500));
};
exports._sum = async (sum) => {
  const myCount = await Count.findOne({ where: { id: 1 } });
  sum = myCount.sum + sum;
  return Count.update({ sum }, { where: { id: 1 } }).then(
    (rows) => {
      console.log(`${myCount.sum} + 1 = ${sum}`);
      return rows;
    },
    (err) => {
      console.log(err);
      throw err;
    }
  );
};

When sending multiple simultaneous requests to this endpoint without a queue, you will notice that the value in the database will be completely different from what we expected. Since we sent 500 simultaneous requests, we expected the value "500" in the database, but the value remained only "1".

SOLUTION WITH QUEUE

To implement the solution with a queue, I used a package called 'Bull' (https://github.com/OptimalBits/bull). It's a library that helps with distributed job control, providing some very useful solutions for this type of work, such as background job processing, queues with priorities (FIFO, LIFO, and others), among other features. 'Bull' uses Redis for queue storage, so if your application crashes for any reason, once it's back online, it will continue executing the processes that are in the queue. In our case, we'll use the FIFO (First in, first out) queue solution, meaning priority based on arrival order.

Here's the code for the endpoints and the queue processor:

const { Router } = require("express");
const controller = require("./controller");
const router = new Router();
const Bull = require("bull");
const Queue = new Bull("Queue", { redis: { port: 6379, host: "redis" } });
router.post("/add-queue", (req, res) => {
  Queue.add({ ...req.body });
  return res.sendStatus(200);
});
router.post("/sum", (req, res) => {
  controller.sum(req, res);
});
Queue.process(async (job) => {
  const { sum } = job.data;
  return controller._sum(sum);
});
exports.router = router;

When we send the 500 simultaneous requests again, we'll notice that now the value in the database will be correct. Because our application has organized the requests into a queue, now only one request will be executed at a time. Upon checking our API log, we'll notice that the process is happening in the background:

GitHub: https://github.com/VitorBrangioni/http-requests-queue

This is the solution I found to solve this problem, I hope this content can help you. Then you just need to adapt this solution to the problem you are facing.

Give me feedback on what you think of this solution, whether it helped or not. But regardless, I did it from the heart!! 🙂

And of course... What can we improve on this? Do you know of a better solution? If so, share it with us and together we will get better. Because nothing is better than sharing knowledge 😉

Best regards and let's code,
Vitor Braggion.

Sistema de filas para manipular processos e mensagens distribuídas (microsserviços) com NodeJS e Bull

Vitor Braggion — Tue, 26 May 2020 15:53:53 +0000

Fala devs! Tudo bem?

Meu nome é Vitor Brangioni, sou Co-Founder e responsável pela tecnologia da ufrilla.

Há um tempo atrás tivemos um probleminha técnico.

A ufrilla para quem não conhece é uma startup que conecta pessoas que querem trabalhar de freelancer ná área de eventos aos produtores de eventos, de forma muito simples. Além de ajudar esses produtores a fazerem toda essa gestão e operação, que é uma 'baita dor de cabeça'.

O problema foi o seguinte: O contratante abre x vagas em nossa plataforma e os freelancers demonstram interesse em trabalhar, em seguida o contratante seleciona as pessoas que ele quer que trabalhe em seu evento e assim os primeiros que confirmarem de fato irão trabalhar. Exemplo: Se o contratante abrir 5 vagas de Bartender, ele poderá selecionar mais de 100 pessoas das que demonstraram interesse, mas somente as 5 primeiras que confirmarem irão trabalhar.

Como o número de usuários começou a crescer bem (+35mil usuários na época) com uma certa frequência havia freelancers confirmando na vaga ao mesmo tempo, acontecendo requisições simultâneas. E para ver se ainda há disponibilidade de vagas, temos que buscar o número de pessoas confirmadas no banco de dados e verificar se as vagas já foram preenchidas, se ainda houver disponibilidade, então confirmamos sua participação. Agora imagine várias dessas requisições sendo processadas ao mesmo tempo, ou em um intervalo muito curto, é como se houvessem várias requisições verificando se há disponibilidade na vaga ao mesmo tempo e ao verificar, de fato há disponibilidade na vaga. Então depois de verificarem que há disponibilidade, todas confirmam participação na vaga.

Exemplo: Temos 1 vaga de trabalho, 5 pessoas confirmaram participação ao mesmo tempo. Então temos 5 requisições diferentes para realizar a confirmação na vaga, porém todas essas requisições leem no banco de dados que há disponibilidade, todas ao mesmo tempo. Como todas verificaram que há disponibilidade, com isso todas vão confirmar participação. No final, todos os cinco freelancers estarão como confirmados em uma vaga, em vez de somente uma pessoa.

Esse problema deu uma 'dor de cabeça' para nossa equipe e provavelmente para os freelancers, pois tinhamos que cancelar com os freelancers que já estavam planejando todo seu dia (ou deveriam. rs) para trabalhar e ainda tudo de forma manual.

A solução que encontrei para resolver esse problema foi aplicar filas no endpoint da API para confirmar participação na vaga. Enquanto houvesse uma requisição sendo processada, as outras estariam na fila esperando o processamento da requisição atual para depois serem processadas. Seguindo a regra de fila, que é a prioridade sobre ordem de chegada (First in, first out - FIFO).

Para facilitar o entendimento do problema, da solução e conseguirmos aplicar em vários contextos, criarei um exemplo bem simples. Vamos resolver o seguinte, temos que buscar um valor no banco de dados e somar +1 nesse valor e salvar novamente. Exemplo: Se o número do banco começar com 0 (zero) e a API receber mil requisições, então no final o número do banco será mil. Mas e se essas requisições forem simultâneas? O valor final ficará com o valor correto??

Vamos começar a implementar essa solução sem fila e veremos o que acontece. Mas antes disponibilizarei a modelagem do banco de dados e script para enviarmos várias requisições simultâneas na API.

Observação: Criei uma API em NodeJS para receber e processar as requisições, com os endpoints de 'somar +1' com fila e sem fila. Não vou mostrar aqui o código sobre a arquitetura da API, pois não é o foco, e sim o código chave sobre nossa solução. Caso queira visualizar o código todo, disponibilizarei o link do github.

MODELAGEM DO BANCO

CÓDIGO PARA ENVIAR VÁRIAS REQUISIÇÕES SIMULTÂNEAS

const axios = require("axios"); // package para enviar as requisições
const host = "http://localhost:3000/api/count";
const endpointWithQueue = `${host}/add-queue`; // endpoint com fila
const endpointWithoutQueue = `${host}/sum`; // endpoint sem fila
const nReqs = 500; // número de requisições para enviar
const reqs = []; // array para inserir as requisições
// Preparando array de requisições
for (let i = 0; i < nReqs; i++) {
  reqs.push(axios.post(endpointWithQueue, { sum: 1 })); // altere qual endpoint você quer testar, com fila ou sem fila.
}
// Enviando requisções para a api de forma simultânea.
Promise.all(reqs).then(
  (_) => console.log("SUCESSO! Todas as requisições foram enviadas."),
  (err) => console.log(err)
);

SOLUÇÃO SEM FILA

Endpoint da API para chamar o método de 'somar +1':

router.post('/sum', (req, res) => {
    controller.sum(req, res)
});

Método para adicionar +1 na coluna 'sum' do banco de dados:


const { Count } = require("./../../config/models");
exports.sum = async (req, res) => {
  let { sum } = req.body;
  this._sum(sum)
    .then((_) => res.sendStatus(200))
    .catch((err) => res.sendStatus(500));
};
exports._sum = async (sum) => {
  const myCount = await Count.findOne({ where: { id: 1 } });
  sum = myCount.sum + sum;
  return Count.update({ sum }, { where: { id: 1 } }).then(
    (rows) => {
      console.log(`${myCount.sum} + 1 = ${sum}`);
      return rows;
    },
    (err) => {
      console.log(err);
      throw err;
    }
  );
};

Ao realizar o envio de várias requisições simultâneas para esse end-point sem fila, irá notar que o valor no banco de dado estará totalmente errado do que esperavamos. Como enviamos 500 requisições simultâneas, esperavamos o valor "500" no banco de dados, mas o valor ficou somente "1".

SOLUÇÃO COM FILA

Para implementar a solução com fila, usei um package chamado de 'Bull' (https://github.com/OptimalBits/bull). É uma biblioteca que te ajuda com o controle de trabalhos distribuídos, ela fornece algumas soluções muito útil para esse tipo de trabalho, em que conseguimos realizar trabalhos em background, como filas com prioridades ( FIFO, LIFO e outras) e outras soluções. O 'Bull' utiliza o redis para armazenamento da fila, então caso sua aplicação 'caia' por algum motivo, após ela voltar ao ar, continuará executando os processos que encontram-se na fila. Em nosso caso, usaremos a solução de fila FIFO (First in, first out), ou seja, prioridade por ordem de chegada.

Código para end-points e processador da fila:


const { Router } = require("express");
const controller = require("./controller");
const router = new Router();
const Bull = require("bull");
const Queue = new Bull("Queue", { redis: { port: 6379, host: "redis" } });
router.post("/add-queue", (req, res) => {
  Queue.add({ ...req.body });
  return res.sendStatus(200);
});
router.post("/sum", (req, res) => {
  controller.sum(req, res);
});
Queue.process(async (job) => {
  const { sum } = job.data;
  return controller._sum(sum);
});
exports.router = router;

Ao enviarmos novamente as 500 requisições simultâneas, notaremos que agora o valor do banco ficará correto. Pois nossa aplicação agora organizou as requisições em uma fila, agora será executada uma requisição por vez. Ao entrar em nosso log da API, notaremos que o processo estará acontecendo em background:

Github: https://github.com/VitorBrangioni/http-requests-queue

Essa é a solução que encontrei para resolver esse problema, espero que esse conteúdo consiga ajudar vocês. Depois é só adequarem essa solução no problema que estão enfrentando.

Me deem um feedback do que acharam dessa soluçao, se ajudou ou não. Mas independente, fiz de coração!! 🙂

E claro... O que podemos melhorar nisso? Conhece alguma solução melhor? Se sim, compartilhe com a gente e juntos ficaremos melhor. Pois nada é melhor do que compartilhar conhecimentos 😉

Abraços e bora codar,
Vitor Brangioni.