Neste artigo, vamos entender:

• O que é Docker e como funciona

• Diferença entre containers e máquinas virtuais

• Vantagens de usar Docker no dia a dia

• Como começar a usar Docker

🔹 O que é Docker?

O Docker é uma plataforma open source que permite criar, gerenciar e executar containers.
Um container é como uma “caixa” que contém o código, as bibliotecas e as dependências necessárias para executar uma aplicação.

Isso garante que o ambiente de desenvolvimento, testes e produção seja idêntico, evitando o famoso “funciona na minha máquina, mas não no servidor”.

🔹 Containers vs Máquinas Virtuais

Embora containers e máquinas virtuais (VMs) pareçam semelhantes, eles funcionam de formas diferentes:

🔹 Vantagens de usar Docker

✅ Portabilidade — Rode sua aplicação no Windows, Linux, Mac, servidor físico ou na nuvem, sem ajustes.
✅ Escalabilidade — Facilita criar múltiplas instâncias da aplicação para lidar com alta demanda.
✅ Velocidade — Containers iniciam em segundos, acelerando o desenvolvimento e o deploy.
✅ Padronização — O ambiente é sempre o mesmo, evitando conflitos de dependências.

🔹 Como instalar o Docker

Para começar, baixe e instale o Docker Desktop no seu sistema operacional:

• Windows e Mac: Download aqui

• Linux: Use o gerenciador de pacotes da sua distribuição (apt, yum, dnf, etc.)

Após a instalação, confirme que o Docker está funcionando:

docker --version

🔹 Criando seu primeiro container

Vamos criar um container simples usando o NGINX:

docker run -d -p 8080:80 nginx

Acesse http://localhost:8080 no navegador e pronto — você está rodando um servidor web em um container!

Docker Compose: Gerenciando múltiplos containers

Quando seu projeto precisa de mais de um serviço (ex.: backend, banco de dados, cache), o Docker Compose simplifica tudo.

Exemplo docker-compose.yml:

yamlCopiarEditarversion: '3'
services:
  web:
    image: nginx
    ports:
      - "8080:80"
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: senha123

Com apenas um comando:

bashCopiarEditardocker-compose up -d

Você sobe os dois serviços de uma vez.

📌 Dicas para usar Docker no dia a dia

1. Use Docker Compose para gerenciar múltiplos containers.

2. Otimize a imagem usando imagens base menores, como alpine.

3. Mantenha imagens atualizadas para evitar vulnerabilidades.

4. Use volumes para persistir dados fora do container.

🎯 Conclusão

O Docker é uma ferramenta essencial para qualquer desenvolvedor moderno. Ele não apenas facilita a criação de ambientes consistentes, mas também otimiza o fluxo de desenvolvimento e implantação de aplicações.

Se você quer levar seu desenvolvimento para o próximo nível, comece a usar Docker hoje mesmo.

💡 Gostou deste conteúdo? Continue acompanhando o blog DevPratico para mais dicas e tutoriais de desenvolvimento de software.

🔍 O que são sistemas de mensageria?

Sistemas de mensageria, também chamados de message brokers, são componentes que facilitam a comunicação entre serviços em arquiteturas distribuídas. Eles permitem que partes de um sistema se comuniquem de forma assíncrona, escalável e desacoplada.

Esses sistemas funcionam como intermediários, recebendo mensagens de um ponto e encaminhando para outro — geralmente utilizando filas.

💡 Por que usar mensageria?

• Desacoplamento: serviços não precisam estar ativos ao mesmo tempo para trocarem informações.

• Escalabilidade: melhora o desempenho em sistemas com alto volume de requisições.

• Resiliência: evita perda de dados, mesmo que algum serviço esteja temporariamente fora do ar.

• Organização de processos: permite que tarefas pesadas sejam processadas em segundo plano.

🛠️ RabbitMQ: um dos mensageiros mais usados

RabbitMQ é um message broker baseado no protocolo AMQP (Advanced Message Queuing Protocol). Ele trabalha com filas (queues), trocas (exchanges) e mensagens, permitindo controle total do fluxo de dados.

🔁 Como o RabbitMQ funciona?

O fluxo básico envolve:

1. Producer: envia uma mensagem.

2. Exchange: recebe a mensagem e decide para qual fila ela deve ir.

3. Queue: armazena a mensagem até que ela seja consumida.

4. Consumer: consome a mensagem da fila e processa.

🧾 Exemplo prático: processamento de pagamentos

Imagine um sistema onde o usuário faz um pagamento e o sistema precisa:

• Registrar o pagamento.

• Enviar e-mail de confirmação.

• Notificar terceiros (ex: gateway de pagamento).

• Atualizar o saldo do cliente.

Com RabbitMQ, isso pode ser feito assim:

[API Pagamento]
   |
   | ---> Envia mensagem para a Exchange "pagamentos"
                      |
                Exchange "pagamentos"
                      |
      +---------------+---------------+
      |               |               |
[Queue Email]   [Queue Gateway]   [Queue Saldo]

Cada consumidor atua de forma independente e paralela, evitando lentidão na resposta da API principal.

🧰 Exemplo de uso básico com Node.js e amqplib

publisher.js

const amqp = require('amqplib');

async function sendMessage() {
  const conn = await amqp.connect('amqp://localhost');
  const channel = await conn.createChannel();
  const queue = 'pagamentos';

  await channel.assertQueue(queue);
  channel.sendToQueue(queue, Buffer.from('Pagamento recebido'));

  console.log('Mensagem enviada!');
  setTimeout(() => { conn.close(); process.exit(0); }, 500);
}

sendMessage();

consumer.js

const amqp = require('amqplib');

async function receiveMessage() {
  const conn = await amqp.connect('amqp://localhost');
  const channel = await conn.createChannel();
  const queue = 'pagamentos';

  await channel.assertQueue(queue);
  console.log('Aguardando mensagens...');

  channel.consume(queue, msg => {
    if (msg) {
      console.log('Mensagem recebida:', msg.content.toString());
      channel.ack(msg);
    }
  });
}

receiveMessage();

📊 RabbitMQ vs outros sistemas

✅ Conclusão

Sistemas de mensageria como o RabbitMQ são peças-chave em arquiteturas modernas. Eles permitem construir sistemas escaláveis, resilientes e desacoplados, otimizando desde simples tarefas assíncronas até fluxos de negócios complexos.

🔗 Próximos passos

• Instale o RabbitMQ localmente ou via Docker.

• Crie um pequeno sistema com Node.js ou Java que utilize filas.

• Explore padrões como RPC com RabbitMQ, dead-letter queues e retry policies.

🚀 O que é Agile e por que ele importa?

Agile é um conjunto de valores e princípios que promove entregas rápidas, feedback contínuo e colaboração constante. Ele surgiu como resposta a modelos pesados e burocráticos de desenvolvimento, como o famoso waterfall.

Para o desenvolvedor, isso significa:

• Menos retrabalho e mais foco no que realmente importa;

• Entrega contínua, que permite ver o impacto do seu código mais rápido;

• Colaboração real com o time e com o cliente;

• Maior visibilidade sobre o que está sendo feito, e por quê.

💼 Agile no dia a dia do Dev

1. Daily Meetings (reuniões diárias)

• Curta, direta e objetiva. A daily te ajuda a entender o que cada membro do time está fazendo e identificar rapidamente bloqueios.

• Exemplo: se você está esperando uma API para seguir seu trabalho, a daily evita dias perdidos sem comunicação.

2. Sprints e Planejamentos

• O Sprint planning define o que será entregue nas próximas semanas, o que dá previsibilidade e foco.

• Ajuda a priorizar o que tem mais valor de negócio e técnico.

3. Retrospectivas

• Espaço seguro para discutir o que deu certo, o que deu errado e o que pode melhorar.

• Como dev, isso te dá voz e promove melhoria contínua.

🧩 Agile + Soft Skills = Dev mais completo

Trabalhar com Agile desenvolve soft skills essenciais:

• Comunicação clara: você aprende a expressar melhor seus pontos e dificuldades.

• Colaboração: ninguém programa sozinho em ambientes ágeis.

• Resiliência e adaptação: mudanças são esperadas, não temidas.

🧪 Agile com Scrum, Kanban ou XP?

Você pode aplicar Agile de várias formas:

• Scrum: mais estruturado, ótimo para equipes com entregas recorrentes.

• Kanban: mais fluido, ideal para times que lidam com demandas contínuas.

• Extreme Programming (XP): foco em qualidade de código e boas práticas de engenharia.

Escolha depende da maturidade do time e do tipo de projeto.

📈 Benefícios para sua carreira

Adotar Agile no seu modo de trabalhar traz várias vantagens profissionais:

• Você se torna um dev mais produtivo e organizado;

• Melhora sua capacidade de comunicar progresso e problemas;

• Ganha visibilidade no time e abre portas para liderança técnica;

• Está preparado para trabalhar em empresas modernas que usam Agile como padrão.

✅ Conclusão: não é só sobre processos, é sobre evolução

Agile não é só sobre post-its, sprints ou reuniões — é sobre entregar valor real com consistência, com foco, alinhamento e melhoria constante.

Se você quer crescer como desenvolvedor, entender e aplicar Agile no seu dia a dia é um diferencial que te coloca à frente.

Monorepos: O que são e por que usá-los?

Monorepo (ou "monolithic repository") é uma estratégia onde todo o código-fonte de vários projetos relacionados é armazenado em um único repositório.

Vantagens:

• Reutilização de código entre apps e libs

• Melhoria no versionamento e controle de dependências

• Consistência e padronização entre times

• Facilidade de refatorações em larga escala

Introdução ao Nx

Nx é uma ferramenta poderosa de build e gestão de monorepos para projetos modernos em JavaScript/TypeScript, com suporte a frameworks como React, Angular, Node.js e mais.

Ele oferece:

• Estrutura opinativa para escalar com qualidade

• Gerador de código, linting, testes, builds otimizados

• Caching inteligente e análises de dependências

Cenário prático: Aplicação de pagamentos

Imagine um sistema composto por:

• app-pagamentos: aplicação React para clientes

• api-transacoes: API Node.js para processar pagamentos

• libs/shared: biblioteca com validações, modelos e lógica compartilhada

npx create-nx-workspace@latest pagamentos-nx
cd pagamentos-nx

Crie os apps:

nx generate @nx/react:application app-pagamentos
nx generate @nx/node:application api-transacoes

E uma lib compartilhada:

nx generate @nx/js:lib shared

Agora, tanto a API quanto o front-end podem importar:

import { validarCartao } from '@pagamentos-nx/shared';

Recursos do Nx que fazem diferença

• Graph de dependências: visualize como apps e libs se conectam.

• Affected: só builda/testa o que foi alterado.

• Executores customizados: automatize tarefas comuns.

• Project.json: controle granular por projeto.

Boas práticas com Monorepos e Nx

• Separe apps e libs por domínio ou funcionalidade.

• Use tags e restrições para limitar acoplamentos entre libs.

• Mantenha dependências enxutas em cada projeto.

Quando NÃO usar um monorepo?

• Se os projetos forem completamente independentes e com times distintos.

• Se o repositório crescer demais e o tooling não estiver bem otimizado.

Conclusão

Usar monorepos com Nx pode elevar seu nível de produtividade, facilitar a padronização entre projetos e times, e trazer escalabilidade de verdade.

Explore o site oficial do Nx para mais tutoriais e exemplos avançados!

Quer mais conteúdos práticos sobre arquitetura, ferramentas modernas e produtividade no desenvolvimento? Siga o Dev Prático 🚀

React Hooks revolucionaram a forma como escrevemos componentes funcionais em React. Se você está começando com React ou já programa com ele há um tempo, entender como e quando usar os hooks pode transformar sua produtividade e qualidade de código.

O que são React Hooks?

React Hooks são funções que permitem usar o estado e outros recursos do React em componentes funcionais. Antes deles, apenas componentes de classe tinham acesso a recursos como estado (this.state) e ciclo de vida (componentDidMount, etc).

Por que usar Hooks?

• Código mais limpo e conciso

• Maior reutilização de lógica

• Melhor organização do projeto

• Adequação à abordagem funcional moderna

Principais Hooks do React

1. useState – Para Gerenciar Estado Local

import { useState } from 'react';

function Pagamento() {
  const [valor, setValor] = useState(0);

  return (
    <div>
      <p>Valor do pagamento: R${valor}</p>
      <button onClick={() => setValor(valor + 10)}>Adicionar R$10</button>
    </div>
  );
}

2. useEffect – Para Efeitos Colaterais

import { useEffect, useState } from 'react';

function Transacao() {
  const [transacoes, setTransacoes] = useState([]);

  useEffect(() => {
    fetch('/api/pagamentos')
      .then(res => res.json())
      .then(data => setTransacoes(data));
  }, []); // Executa apenas uma vez

  return (
    <ul>
      {transacoes.map((t) => (
        <li key={t.id}>{t.descricao} - R${t.valor}</li>
      ))}
    </ul>
  );
}

3. useContext – Para Compartilhar Estado Global

Ideal para autenticação ou dados de sessão de pagamento:

const PagamentoContext = React.createContext();

function PagamentoProvider({ children }) {
  const [usuario, setUsuario] = useState(null);

  return (
    <PagamentoContext.Provider value={{ usuario, setUsuario }}>
      {children}
    </PagamentoContext.Provider>
  );
}

function Dashboard() {
  const { usuario } = useContext(PagamentoContext);
  return <h1>Bem-vindo, {usuario?.nome}</h1>;
}

4. useRef – Para Referências Mutáveis

Útil para capturar input de valor de pagamento, sem renderizar novamente:

function InputValor() {
  const inputRef = useRef();

  function handleEnviar() {
    alert("Valor enviado: " + inputRef.current.value);
  }

  return (
    <div>
      <input type="number" ref={inputRef} />
      <button onClick={handleEnviar}>Enviar</button>
    </div>
  );
}

Hooks Customizados

Você pode criar seus próprios hooks para reutilizar lógica. Exemplo: hook para formatação de valores:

function useFormatoReal(valor) {
  return new Intl.NumberFormat('pt-BR', {
    style: 'currency',
    currency: 'BRL',
  }).format(valor);
}

Conclusão

Hooks são essenciais no desenvolvimento moderno com React. Dominar useState, useEffect, useContext e useRef é o primeiro passo para escrever aplicações robustas, especialmente em cenários reais como gestão de pagamentos.

Gostou do conteúdo? Compartilhe e siga o blog Dev Prático para mais dicas práticas de desenvolvimento! 🚀

Se você já criou mais de uma tela em uma aplicação React, provavelmente percebeu a repetição de componentes visuais — botões, inputs, cards, modais... E se em cada nova tela esses componentes forem reinventados ou ajustados individualmente, o caos se instala rapidamente.

É aqui que entra o Design System. Ele não é apenas uma biblioteca de componentes. É uma linguagem visual padronizada, com guias de estilo, tokens, regras de uso e componentes reutilizáveis, com foco em consistência e escalabilidade.

Este artigo é um ponto de partida para desenvolvedores que desejam entender, criar ou manter um Design System utilizando React.

O que é um Design System?

Um Design System é um conjunto de padrões reutilizáveis de design e componentes, documentados e aplicáveis a múltiplas aplicações.

Ele normalmente inclui:

• Guia de cores (tokens)

• Tipografia

• Espaçamentos e grid

• Estilo de ícones

• Componentes reutilizáveis (UI Kit)

• Documentação

Por que criar um Design System?

Benefícios práticos:

• Consistência visual e de UX

• Aumento da produtividade da equipe

• Redução de bugs visuais

• Facilidade de manutenção

• Comunicação mais fluida entre designers e desenvolvedores

Como estruturar um Design System com React

1. Tokens de Design

Os design tokens são as unidades fundamentais do seu sistema. Em React, normalmente são criados em arquivos de constantes ou usando ferramentas como Style Dictionary.

// tokens/colors.js
export const colors = {
  primary: "#0070f3",
  secondary: "#1c1c1e",
  background: "#ffffff",
};

2. Componentes Base

Construa componentes desacoplados, reusáveis e com boas práticas de acessibilidade. Exemplo de botão:

// components/Button.jsx
export function Button({ children, variant = "primary", ...props }) {
  return (
    <button
      className={`btn ${variant}`}
      {...props}
    >
      {children}
    </button>
  );
}

3. Estilização

Você pode utilizar CSS Modules, Tailwind, Styled-components, Stitches ou Vanilla Extract. Exemplo com Tailwind:

<button className="bg-blue-600 text-white px-4 py-2 rounded">
  Comprar
</button>

4. Documentação

Utilize ferramentas como Storybook, Ladle, Docsify ou até uma Wiki com exemplos e guidelines. Um Design System sem documentação não escala.

Boas Práticas

• Componentização clara: evite criar componentes acoplados a lógica de negócio.

• Consistência: mantenha nomenclatura e estilo padronizados.

• Acessibilidade: todos os componentes devem seguir normas como WCAG.

• Versão e pacotes: publique seu design system como um pacote npm privado ou público.

Ferramentas úteis

• Storybook: documentação interativa

• Figma: design com tokens e bibliotecas compartilhadas

• Style Dictionary: tokens centralizados

• Ladle: alternativa leve ao Storybook

Conclusão

Criar um Design System com React não é apenas um luxo para grandes empresas. É um investimento estratégico para qualquer equipe que deseja ganhar velocidade, consistência e confiança no produto.

Comece simples: defina tokens, crie componentes básicos e documente tudo com clareza. A evolução será natural e incremental.

SEO Tags

• design system react

• como criar design system react

• design system com storybook

• componentização react

• tokens de design em react

Neste post, você vai entender:

• O que é um Staff Engineer

• Qual a diferença para um Tech Lead ou Engenheiro Sênior

• Quais habilidades são necessárias

• Como se preparar para assumir esse papel

O que é um Staff Engineer?

O Staff Engineer é um profissional técnico de altíssimo nível que atua com influência técnica profunda, visão estratégica e liderança transversal, sem necessariamente gerenciar pessoas.

Ele é responsável por resolver os maiores desafios técnicos da empresa, liderar decisões arquiteturais críticas e servir como referência técnica para vários times.

Staff Engineer vs Tech Lead

O que faz um Staff Engineer na prática?

✔️ Define diretrizes técnicas e padrões de arquitetura
✔️ Avalia riscos técnicos em escala de produto
✔️ Atua como ponte entre áreas de produto, engenharia e infraestrutura
✔️ Faz mentoria de engenheiros de todos os níveis
✔️ Participa de decisões de longo prazo e evolução técnica da empresa

Exemplo:

Imagine que a empresa está com problemas de escalabilidade no sistema de pagamentos. O Staff Engineer:

• Mapeia os gargalos técnicos com observabilidade e benchmark

• Projeta uma nova arquitetura assíncrona baseada em filas

• Coordena a evolução técnica com os times afetados

• Documenta e defende a proposta para diretoria técnica

Habilidades-chave de um Staff Engineer

Como se tornar um Staff Engineer?

1. Domine profundamente o funcionamento da sua stack e sistemas

2. Atue além do seu time atual: proponha melhorias que impactem a engenharia como um todo

3. Escreva propostas técnicas com clareza e estrutura

4. Mentore devs de outros squads e compartilhe conhecimento

5. Trabalhe sua comunicação para influenciar decisões estratégicas

Dica prática: comece a pensar como Staff hoje

🔍 Enxergue problemas sistêmicos além da sua sprint
🧠 Proponha soluções técnicas com impacto duradouro
✍️ Documente decisões e compartilhe com a engenharia
📣 Torne-se referência técnica no seu domínio
🎯 Esteja por dentro das metas de produto e negócio

Conclusão

O Staff Engineer não é só um “dev sênior ++”. É um papel de altíssimo impacto técnico e estratégico, essencial em empresas que escalam. Se você quer crescer sem sair da trilha técnica, esse é um caminho de liderança e realização profissional.

Curtiu o conteúdo?

Se quiser ver uma comparação com Principal Engineer, dicas para entrevistas ou como preparar um tech doc de impacto, comenta aqui no post!

Publicado por Dev Prático — onde código, carreira e café se encontram.

Neste post, vamos explorar de forma prática e objetiva:

• O que é a função de Tech Lead

• Qual o papel no time e na empresa

• Como se tornar um

• Habilidades técnicas e comportamentais essenciais

O que é um Tech Lead?

O Tech Lead (ou Líder Técnico) é o profissional responsável por guiar tecnicamente o time de desenvolvimento. Ele atua como ponte entre a equipe e outras áreas do projeto, garantindo que as decisões técnicas estejam alinhadas aos objetivos do produto e da empresa.

Responsabilidades de um Tech Lead

✔️ Tomada de decisão técnica
✔️ Mentoria e suporte técnico ao time
✔️ Code reviews, arquitetura e padrões de projeto
✔️ Planejamento técnico de sprints e entregas
✔️ Comunicação com PMs, POs e stakeholders
✔️ Atenção à qualidade e performance do sistema

Exemplo prático:

Imagine um time trabalhando em uma plataforma de pagamentos. O Tech Lead deve:

• Escolher entre REST ou GraphQL para a API

• Avaliar a escalabilidade da arquitetura

• Orientar um dev júnior sobre validação de cartões

• Garantir testes automatizados nas integrações

Tech Lead é gerente?

Não. O Tech Lead é um líder técnico, não um gestor de pessoas (embora em algumas empresas acumule funções). Seu foco principal é decidir e orientar tecnicamente. O acompanhamento de performance, salários e carreira geralmente fica com o Engineering Manager.

Como se tornar um Tech Lead?

1. Domine bem a stack da sua equipe

2. Comunique-se com clareza, principalmente com não técnicos

3. Aprenda a delegar e confiar no time

4. Tenha visão de produto e negócios

5. Comece assumindo pequenas lideranças e responsabilidades técnicas

Habilidades essenciais para um Tech Lead

Dica prática: como se preparar

👨‍💻 Participe de decisões técnicas
🧠 Estude arquitetura e padrões como SOLID, DDD, Clean Architecture
📚 Leia livros como The Manager’s Path e Staff Engineer
🎙️ Pratique explicar soluções para não técnicos

Conclusão

Ser Tech Lead é muito mais do que saber codar bem. É sobre influenciar tecnicamente, colaborar com outras áreas e desbloquear o potencial do time. Se você tem perfil de liderança e paixão por tecnologia, esse pode ser o seu próximo passo.

Curtiu o conteúdo?

Se quiser ver uma série sobre liderança técnica, transição de carreira para Tech Lead ou dicas para entrevistas, comenta aqui que posso produzir os próximos posts!

Publicado por Dev Prático — onde código, carreira e café se encontram.

Neste post, você vai entender o que é blockchain, como ela funciona na prática, e onde desenvolvedores como você podem aplicar esse conhecimento com segurança e criatividade.

O que é Blockchain?

Blockchain é uma estrutura de dados que funciona como um livro-razão digital, onde as informações são registradas em blocos interligados de forma segura e imutável.

Cada bloco contém:

• Um conjunto de transações

• Um timestamp

• Um hash do bloco anterior

Isso garante integridade e rastreabilidade sem precisar de uma autoridade central (como um banco ou governo).

Por que blockchain é revolucionária?

Porque ela permite: ✅ Transparência total — todas as transações são públicas (em blockchains abertas)
✅ Segurança — os dados não podem ser alterados sem consenso da rede
✅ Descentralização — ninguém tem controle absoluto
✅ Rastreabilidade — cada operação pode ser auditada

Como blockchain funciona na prática?

Vamos a um exemplo usando pagamentos entre usuários.

Passo a passo de uma transação:

1. João envia 1 token para Maria.

2. Essa transação é transmitida à rede.

3. Mineradores (ou validadores) confirmam a transação.

4. A transação é adicionada a um novo bloco.

5. O bloco é vinculado ao anterior, formando uma cadeia.

Exemplo visual simplificado:

{
  "bloco": 2456,
  "transacoes": [
    {
      "de": "João",
      "para": "Maria",
      "valor": 1
    }
  ],
  "hashAnterior": "0000xabc123...",
  "hashAtual": "0000xdef456..."
}

Exemplo prático com smart contracts

Um smart contract é um programa que executa regras automaticamente, sem intermediários.

Cenário: pagamento de freelancer

contract PagamentoFreelancer {
    address public contratante;
    address public freelancer;

    constructor(address _freelancer) {
        contratante = msg.sender;
        freelancer = _freelancer;
    }

    function pagar() public payable {
        require(msg.sender == contratante, "Apenas o contratante pode pagar");
        payable(freelancer).transfer(msg.value);
    }
}

O pagamento é feito com segurança, sem precisar de intermediários como plataformas ou bancos.

Onde blockchain está sendo usada além de cripto?

• Pagamentos internacionais (Ripple, Stellar)

• Logística e rastreamento de alimentos (IBM Food Trust)

• Jogos com ativos digitais (NFTs)

• Sistemas de identidade digital

• Votação eletrônica segura

Blockchain vs Banco Tradicional

Conclusão

Blockchain não é só sobre cripto. É sobre confiança sem intermediários, segurança distribuída e inovação real. Se você é dev e quer se preparar para o futuro, entender como blockchain funciona pode abrir portas para projetos incríveis.

Curtiu o conteúdo?

Se quiser ver tutoriais com Solidity, criar tokens ou integrar blockchain com sistemas existentes, comenta aqui no post!

Publicado por Dev Prático — onde código, carreira e café se encontram.

Neste post, vou te mostrar como funciona o GraphQL com um exemplo real de sistema de pagamentos, explicando vantagens, estrutura e como aplicar no dia a dia. Vamos juntos?

O que é GraphQL?

GraphQL é uma linguagem de consulta para APIs criada pelo Facebook. Com ela, você pode buscar exatamente os dados que precisa, evitando requisições longas ou sobrecarregadas.

Diferente do REST, onde cada recurso geralmente tem um endpoint separado (/pagamentos, /usuarios, /pedidos), no GraphQL tudo é acessado por um único endpoint com uma linguagem de consulta altamente flexível.

Por que usar GraphQL em um sistema de pagamentos?

Sistemas de pagamento lidam com múltiplos dados relacionados:

• Usuário que fez a compra

• Produto comprado

• Status do pagamento

• Data da transação

• Método de pagamento

Com GraphQL, é possível obter todos esses dados em uma única requisição, com controle total sobre o que você quer receber.

Exemplo prático: Consulta de pagamentos

Cenário

Queremos exibir uma lista de pagamentos com:

• Nome do usuário

• Valor pago

• Status

• Método utilizado

Requisição GraphQL:

query {
  pagamentos {
    id
    valor
    status
    metodo
    usuario {
      nome
      email
    }
  }
}

Resposta da API:

{
  "data": {
    "pagamentos": [
      {
        "id": "001",
        "valor": 250.0,
        "status": "Aprovado",
        "metodo": "Cartão de Crédito",
        "usuario": {
          "nome": "João Silva",
          "email": "joao@email.com"
        }
      }
    ]
  }
}

Vantagens do GraphQL nesse cenário

✅ Consulta personalizada: você define os campos que quer.
✅ Menos requisições: busca dados relacionados em uma só chamada.
✅ Documentação automática: o schema define tudo que está disponível.
✅ Evolução sem quebra: você pode adicionar novos campos sem impactar quem usa a API.

Como criar um schema de pagamentos

Exemplo de schema GraphQL:

type Usuario {
  id: ID!
  nome: String!
  email: String!
}

type Pagamento {
  id: ID!
  valor: Float!
  status: String!
  metodo: String!
  usuario: Usuario!
}

type Query {
  pagamentos: [Pagamento!]!
}

Com esse schema, já conseguimos fazer consultas como a anterior. Em projetos maiores, é possível integrar com bancos de dados, aplicar autenticação, paginação e filtros com facilidade.

GraphQL vs REST: qual usar?

Se seu projeto cresce rápido e exige flexibilidade nas respostas da API, o GraphQL tende a ser uma escolha mais robusta.

Conclusão

O GraphQL pode ser um divisor de águas para projetos que demandam performance e flexibilidade, como sistemas de pagamento. Ele reduz a complexidade do frontend e melhora a experiência de desenvolvimento como um todo.

Se você trabalha com integrações entre múltiplos serviços ou precisa entregar dados precisos em apps móveis/web, vale muito a pena considerar o uso de GraphQL.

Curtiu o conteúdo?

Quer ver uma implementação prática com Apollo Server ou integração com backend Java? Deixa aqui nos comentários!

Publicado por Dev Prático — onde código, carreira e café se encontram.

Essa situação é mais comum do que parece. E, muitas vezes, ela acontece porque estamos quebrando — sem perceber — os princípios do SOLID, um conjunto de boas práticas que ajudam a manter seu código limpo, flexível e escalável.

Neste post, vou te mostrar:

• O que significa cada letra do SOLID

• Explicações práticas com exemplos simples

• Como aplicar esses conceitos no seu dia a dia como dev

O que é SOLID?

SOLID é um acrônimo criado por Robert C. Martin (Uncle Bob) que representa cinco princípios fundamentais do design de software orientado a objetos. Eles ajudam a criar sistemas mais organizados, coesos e fáceis de manter.

S — Single Responsibility Principle (SRP)

Princípio da Responsabilidade Única

Uma classe deve ter apenas um motivo para mudar.

Isso significa que cada classe, módulo ou função deve ter uma única responsabilidade bem definida. Quando uma classe tem várias responsabilidades, qualquer alteração em uma delas pode impactar negativamente outras partes da aplicação.

Problema comum:

Classes que fazem muitas coisas ao mesmo tempo, como lógica de negócio, persistência e envio de notificações.

Exemplo ruim:

class UsuarioService {
  void registrar(Usuario user) {
    validar(user);
    salvarNoBanco(user);
    enviarEmailBoasVindas(user);
  }
}

Solução:

Crie classes especializadas para cada ação:

class ValidadorUsuario { void validar(Usuario u) { ... } }
class UsuarioRepository { void salvar(Usuario u) { ... } }
class EmailService { void enviarBoasVindas(Usuario u) { ... } }

O — Open/Closed Principle (OCP)

Aberto para extensão, fechado para modificação

Você deve ser capaz de adicionar novos comportamentos ao sistema sem alterar o código existente.

Esse princípio incentiva o uso de abstrações (interfaces ou classes base) para que você possa estender funcionalidades sem tocar no que já funciona.

Exemplo:

Ao invés de usar if ou switch para tratar múltiplas regras, use polimorfismo com subclasses.

interface Desconto {
  double calcular(double valor);
}

class DescontoBlackFriday implements Desconto {
  public double calcular(double valor) {
    return valor * 0.9;
  }
}

Você pode adicionar novos descontos sem alterar a lógica principal.

L — Liskov Substitution Principle (LSP)

Subtipos devem ser substituíveis por seus tipos base

Se S é um subtipo de T, objetos do tipo T devem poder ser substituídos por objetos do tipo S sem afetar a funcionalidade.

Se uma subclasse quebra o comportamento esperado da superclasse, você está violando o LSP.

Exemplo ruim:

class Pato {
  void voar() { ... }
}

class PatoDeBorracha extends Pato {
  void voar() {
    // não faz sentido: pato de borracha não voa!
  }
}

Solução:

Evite herança quando não há relação de comportamento real. Use composição ou interfaces específicas.

I — Interface Segregation Principle (ISP)

Muitos contratos específicos são melhores que um único contrato genérico

Os clientes não devem ser forçados a depender de interfaces que não usam.

Interfaces grandes demais causam implementações infladas. Divida-as em interfaces menores e mais focadas.

Exemplo ruim:

interface OperacoesConta {
  void sacar();
  void depositar();
  void pedirEmprestimo(); // nem toda conta permite isso!
}

Exemplo bom:

interface SaqueDeposito {
  void sacar();
  void depositar();
}

interface ContaComEmprestimo {
  void pedirEmprestimo();
}

D — Dependency Inversion Principle (DIP)

Dependa de abstrações, não de implementações concretas

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.

Ao invés de criar dependências diretas em uma classe, use interfaces para injetar comportamentos. Isso facilita testes, mudanças e reutilização.

Exemplo:

class PedidoService {
  private EmailService email;

  PedidoService(EmailService email) {
    this.email = email;
  }
}

Você pode facilmente trocar EmailService por um mock ou outro tipo de serviço.

Conclusão

Aplicar o SOLID na prática evita que seu projeto vire um monstro difícil de entender e manter. Comece aos poucos, especialmente com os princípios SRP e DIP, e você verá a diferença no dia a dia.

Curtiu o conteúdo?

Deixe um comentário se quiser ver mais exemplos aplicados em outras linguagens como PL/SQL, Java ou Python!

Publicado por Dev Prático — onde código, carreira e café se encontram.

Neste post, vou mostrar um modelo direto de como documentar endpoints REST — com base em exemplos reais e cobrindo os principais métodos: GET, POST, PUT, PATCH e DELETE.

🧭 Visão geral dos métodos HTTP

🧪 Exemplo: API de Consulta de Processos

Vamos usar uma API fictícia chamada /api/processos para ilustrar cada um dos métodos.

1. 🔍 GET /api/processos/{id}

Buscar detalhes de um processo específico

📍 URL

GET /api/processos/0001234-56.2023.8.26.0001

🔼 Resposta

{
  "numeroProcesso": "0001234-56.2023.8.26.0001",
  "classe": "Ação Cível",
  "assunto": "Cobrança",
  "dataDistribuicao": "2023-08-15",
  "partes": [
    { "nome": "Maria da Silva", "tipo": "AUTOR" },
    { "nome": "João de Souza", "tipo": "RÉU" }
  ]
}

2. 📝 POST /api/processos

Criar um novo processo

📤 Requisição

{
  "numeroProcesso": "0001234-56.2023.8.26.0001",
  "classe": "Ação Cível",
  "assunto": "Cobrança"
}

🔼 Resposta

• 201 Created com o corpo criado ou o ID do recurso

3. 🔄 PUT /api/processos/{id}

Atualizar totalmente um processo existente

📤 Requisição

{
  "classe": "Ação Penal",
  "assunto": "Furto qualificado"
}

🔼 Resposta

• 200 OK com os dados atualizados

4. 🩹 PATCH /api/processos/{id}

Atualizar parcialmente um processo

📤 Requisição

{
  "assunto": "Atualização cadastral"
}

🔼 Resposta

• 200 OK com os dados atualizados

5. 🗑️ DELETE /api/processos/{id}

Remover um processo

📍 URL

DELETE /api/processos/0001234-56.2023.8.26.0001

🔼 Resposta

• 204 No Content

🧠 Boas práticas ao documentar endpoints

1. Seja específico: mostre exemplos reais de entrada e saída.

2. Liste os códigos de status possíveis: isso evita dúvidas sobre como tratar a resposta.

3. Explique os métodos: muitos devs confundem PUT e PATCH.

4. Padronize tudo: headers, estrutura dos campos, nomes das rotas.

Conclusão

Uma documentação clara é um presente que você dá para o seu "eu do futuro" — e para toda a equipe que vai consumir sua API. Com um modelo bem definido, tudo flui melhor.

Curtiu o exemplo? Tem alguma dúvida ou sugestão? Comenta aqui ou me chama no LinkedIn — vou trazer mais conteúdos sobre APIs e práticas reais de backend!

🧠 O que são TYPES em PL/SQL?

TYPE é uma forma de definir um tipo de dado personalizado. Pode ser usado para:

• Criar tipos escalares (como alias para tipos simples)

• Definir registros (records) com múltiplos campos

• Criar coleções (arrays), como tabelas ou listas

Eles ajudam a organizar dados, deixar o código mais legível e facilitar a manipulação de conjuntos de informações.

📦 Tipos mais comuns

✅ Exemplo 1: TYPE escalar

DECLARE
  TYPE t_codigo IS NUMBER(5);
  v_cod t_codigo;
BEGIN
  v_cod := 101;
END;

🔹 Útil quando você quer reaproveitar um tipo com mais clareza e consistência.

✅ Exemplo 2: TYPE RECORD (tipo registro)

DECLARE
  TYPE t_usuario IS RECORD (
    id_usuario   NUMBER,
    nome         VARCHAR2(100),
    email        VARCHAR2(100)
  );

  v_user t_usuario;
BEGIN
  v_user.id_usuario := 1;
  v_user.nome := 'João';
  v_user.email := 'joao@email.com';
END;

🔹 Ótimo para representar uma linha de tabela ou dados compostos.

✅ Exemplo 3: TYPE TABLE (coleção de registros)

DECLARE
  TYPE t_lista_nomes IS TABLE OF VARCHAR2(50);
  v_nomes t_lista_nomes := t_lista_nomes('Ana', 'Bruno', 'Carlos');
BEGIN
  FOR i IN 1 .. v_nomes.COUNT LOOP
    DBMS_OUTPUT.PUT_LINE(v_nomes(i));
  END LOOP;
END;

🔹 Muito útil para passar listas como parâmetro para procedures ou para processar coleções em loops.

⚙️ Onde usar TYPES?

• Dentro de procedures, functions ou packages

• Para representar linhas de cursor

• Para devolver coleções de dados

• Para organizar parâmetros de entrada e saída

🧩 Dica real de uso

Se você tem procedures que recebem muitos parâmetros, considere usar um RECORD TYPE para agrupá-los. Fica mais limpo, legível e fácil de manter.

🚫 Cuidados ao usar TYPES

• TYPES locais (dentro de procedures) não podem ser usados fora delas

• Se quiser reutilização global, declare no PACKAGE SPEC

• Evite tipos complexos desnecessários se um simples VARCHAR2 resolver

Conclusão

Usar TYPE em PL/SQL é uma forma poderosa de escrever código mais organizado, seguro e reutilizável. Eles facilitam a leitura, reduzem erros e são ideais para trabalhar com dados estruturados e coleções.

Se você curtiu esse conteúdo e quer mais dicas práticas de PL/SQL, me segue aqui ou no LinkedIn. E compartilha com aquele colega que vive fazendo SELECT * sem TYPE 😅

Neste post, vou te mostrar as diferenças práticas com exemplos reais — sem enrolação.

🔍 Diferença principal

✅ Quando usar procedure?

Use procedures quando você quiser executar uma ação que pode envolver várias operações, como:

• Inserções em múltiplas tabelas

• Atualizações em massa

• Envio de logs ou notificações

• Execuções agendadas (jobs)

📌 Exemplo:

CREATE OR REPLACE PROCEDURE registrar_log(p_mensagem IN VARCHAR2) AS
BEGIN
  INSERT INTO logs (mensagem, data_registro)
  VALUES (p_mensagem, SYSDATE);
END;

✅ Quando usar function?

Use functions quando precisar calcular e retornar um valor, especialmente se for usar dentro de queries.

• Calcular diferença de datas

• Transformar ou formatar dados

• Verificar regras (validações simples)

📌 Exemplo:

CREATE OR REPLACE FUNCTION idade_em_anos(p_data_nascimento IN DATE) RETURN NUMBER AS 
BEGIN 
    RETURN TRUNC(MONTHS_BETWEEN(SYSDATE, p_data_nascimento) / 12); 
END;

⚠️ Cuidados ao usar functions

• Evite funções com inserções, updates ou deletes (efeitos colaterais)

• Não use funções pesadas em grandes SELECTs — pode impactar a performance

• Functions usadas em WHERE ou JOIN precisam ser otimizadas

🧠 Dica prática

Se a rotina modifica dados ou só executa comandos, vá de procedure.

Se a rotina precisa ser usada dentro de uma query ou retornar um valor, vá de function.

Conclusão

Entender quando usar procedure ou function melhora a performance, a organização do código e a legibilidade do seu PL/SQL. Use cada uma no seu contexto ideal — e seu sistema agradece!

Se curtiu esse conteúdo, me segue aqui ou no LinkedIn! Em breve trago mais dicas práticas de PL/SQL e desenvolvimento backend real-oficial.

Erro 1: Não isolar a lógica de negócio

É comum ver procedures que fazem "de tudo um pouco": validam dados, executam inserts, chamam outras procedures, retornam resultados... tudo junto.

Problema: Isso dificulta testes, manutenção e reaproveitamento.

Solução: Quebre a lógica em blocos reutilizáveis. Extraia validações para funções específicas, isole acessos ao banco quando possível.

-- Em vez de:
PROCEDURE processa_pedido(p_id IN NUMBER) IS
BEGIN
  IF p_id IS NULL THEN
    RAISE_APPLICATION_ERROR(-20001, 'ID inválido');
  END IF;
  -- lógica de negócio + insert + notificações etc...
END;

-- Faça:
FUNCTION valida_pedido(p_id IN NUMBER) RETURN BOOLEAN IS
BEGIN
  RETURN p_id IS NOT NULL;
END;

PROCEDURE processa_pedido(p_id IN NUMBER) IS
BEGIN
  IF NOT valida_pedido(p_id) THEN
    RAISE_APPLICATION_ERROR(-20001, 'ID inválido');
  END IF;
  -- lógica mais limpa aqui
END;

Erro 2: Não tratar exceções de forma adequada

Muita gente usa WHEN OTHERS THEN NULL sem pensar nas consequências.

Problema: Isso engole erros críticos e torna o debug impossível.

Solução: Sempre registre o erro ou, ao menos, retorne um código de erro claro.

-- Evite:
EXCEPTION
  WHEN OTHERS THEN
    NULL;

-- Melhor:
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('Erro: ' || SQLERRM);
    RAISE;

Erro 3: Não padronizar nomes e estrutura

Procedures com nomes confusos, parâmetros inconsistentes ou organização despadronizada viram um pesadelo a longo prazo.

Solução: Defina um padrão (mesmo que simples). Exemplo:

• proc_nomeDaFuncionalidade_acao (ex: proc_cliente_atualiza)

• Sempre declare parâmetros com modo (IN, OUT) e tipo explícito

• Comente blocos maiores

Conclusão

Escrever PL/SQL limpo é uma habilidade que se desenvolve com prática e atenção aos detalhes. Evitar esses três erros já melhora bastante a qualidade das suas procedures. Se você curte esse tipo de conteúdo mais prático, me segue aqui no Hashnode — vou postar mais dicas de PL/SQL, APIs e testes em breve!

Ficou com dúvida ou tem outro erro comum pra compartilhar? Comenta aqui ou me chama no LinkedIn!