DEV Community: Marcos Filipe

Eu achava que Node.js era o “Django do JavaScript”… até entender isso

Marcos Filipe — Fri, 03 Apr 2026 23:25:52 +0000

Se você está começando no desenvolvimento web, deixa eu tentar adivinhar:

Em algum momento você pensou algo como:

“Se Django é o principal framework do Python… então Node.js deve ser tipo isso pro JavaScript, né?”

Eu também pensei assim.

E foi aí que começou a confusão.

🤯 O momento em que tudo não fez sentido

Eu comecei a pesquisar sobre backend e vi coisas como:

Node.js
Express
NestJS
Django
Flask

E aí veio a dúvida:

“Por que Python tem um nome forte (Django)… mas JavaScript tem vários?”

Parecia que eu estava comparando coisas… que não eram comparáveis.

💡 A virada de chave

Depois de um tempo, caiu a ficha:

Eu estava comparando um ambiente com um framework.

E isso muda tudo.

🧱 A base vs a construção

Vamos simplificar ao máximo:

🔹 Node.js

Não é um framework.

É um ambiente que permite rodar JavaScript fora do navegador.

👉 Ele é o terreno onde você vai construir.

🔹 Django

É um framework completo para aplicações web em Python.

👉 Ele já é praticamente a casa pronta.

⚖️ A comparação correta (agora sim faz sentido)

Quando você ajusta a lente, fica claro:

Python + Django ≈ Node.js + (Express | NestJS | AdonisJS)

Ou seja:

Node.js sozinho não compete com Django
Você precisa de um framework junto

🏗️ Duas filosofias totalmente diferentes

Aqui é onde a escolha realmente importa 👇

🟦 Django — “já vem com tudo”

Django segue a ideia de:

“Não perca tempo decidindo, só construa.”

Você já ganha:

Sistema de autenticação
ORM
Painel admin
Segurança pronta

👉 Sensação: produtividade imediata

🟨 Node.js — “monte do seu jeito”

No mundo Node:

Você escolhe tudo:

Framework (Express, NestJS…)
Banco (Mongo, PostgreSQL…)
ORM (Prisma, Sequelize…)
Auth (JWT, OAuth…)

👉 Sensação: liberdade total (e um pouco de caos no começo)

🧠 O erro mais comum de iniciantes

Achar que:

“Node.js é um framework igual ao Django”

Quando na verdade:

Node.js é só o começo da stack

🚀 Então… qual é melhor?

Resposta honesta:

Depende do tipo de dor que você quer ter 😂

Vá de Django se você quer:

Começar rápido
Menos decisões técnicas
Estrutura pronta

Vá de Node.js se você quer:

Flexibilidade
Trabalhar com JavaScript em tudo
Entender melhor como as peças se conectam

🔥 Conclusão (a versão que eu gostaria de ter ouvido antes)

Django é um pacote completo. Node.js é uma caixa de ferramentas.

Um te dá tudo pronto.
O outro te dá liberdade pra montar.

Nenhum é melhor universalmente — só são diferentes.

💬 Agora me conta

Você também já confundiu isso no começo?

Ou ainda tá tentando decidir qual caminho seguir?

Comenta aí — sempre tem alguém passando pela mesma dúvida que você 👇

Construindo minha primeira CLI com Node.js (consumindo a API do GitHub)

Marcos Filipe — Mon, 30 Mar 2026 17:57:19 +0000

Recentemente, desenvolvi uma CLI simples em Node.js para visualizar a atividade recente de usuários do GitHub direto pelo terminal.

O objetivo foi praticar fundamentos de backend na prática, sem depender de bibliotecas externas, focando em entender cada etapa do processo.

💡 O que a aplicação faz

A ferramenta permite executar:

github-activity <username>

E retorna algo como:

Pushed commits to user/repo
Opened a new issue in user/repo
Starred user/repo

Os dados são obtidos através da API pública do GitHub:

GET /users/:username/events

⚠️ Desafio encontrado: dados incompletos da API

Inicialmente, a ideia era exibir a quantidade exata de commits em cada push:

Pushed 3 commits to user/repo

Porém, durante os testes, observei que a API de eventos do GitHub nem sempre retorna os dados completos.

Em vários PushEvent, o payload vinha assim:

{
  "ref": "refs/heads/main",
  "head": "commit_hash",
  "before": "commit_hash"
}

Sem os campos:

"commits": []
"size": number

Ou seja:

Não há lista de commits
Não há quantidade (size)
Apenas o intervalo (before → head)

🧠 Análise técnica

Isso mostra que a API de eventos:

Funciona como um feed resumido de atividades
Não garante consistência nos dados
Pode omitir informações dependendo do contexto

Uma alternativa mais precisa seria usar:

GET /repos/:owner/:repo/compare/:before...:head

Que retorna o número real de commits. Porém, isso exigiria:

múltiplas requisições por evento
controle de rate limit
maior complexidade

Para este projeto, optei por manter a simplicidade.

✅ Solução adotada

Implementei um fallback:

Pushed commits to user/repo

Quando a quantidade de commits não está disponível.

Isso evita exibir dados incorretos e mantém a saída consistente.

🧠 Aprendizados principais

🔹 Entrada via CLI

Uso de process.argv para capturar argumentos do terminal.

🔹 Consumo de API

Utilização do fetch nativo do Node.js para requisições HTTP.

🔹 Manipulação de JSON

Filtragem e transformação de dados complexos em uma saída legível.

🔹 Tratamento de erros

usuário não encontrado
falhas de requisição
propriedades indefinidas

🔹 Limitações de sistemas externos

Nem sempre o problema está no código — às vezes está na fonte de dados.

⚙️ Decisões de implementação

Sem bibliotecas externas
Código simples e direto
Foco em aprendizado ao invés de abstrações

🚀 Próximos passos

Adicionar flags (--limit, --type)
Melhorar a formatação da saída
Adicionar cores no terminal
Publicar como pacote global (npm)

📌 Conclusão

Esse projeto mostrou, na prática, que:

APIs nem sempre entregam dados completos ou consistentes.

E mais importante:

Um bom software não depende de dados perfeitos — ele se adapta a eles.

🔗 Repositório

https://github.com/mffdeo/github-activity-cli

Memória Sob Demanda: Como o Engram Está Mudando a Forma como LLMs Pensam

Marcos Filipe — Thu, 26 Mar 2026 15:31:29 +0000

Você já parou para pensar que os Transformers, a arquitetura por trás de modelos como ChatGPT, Claude e DeepSeek, são ótimos em raciocínio, mas... péssimos em memória?

É isso que um novo paper da Peking University e DeepSeek-AI propõe resolver. Tentei trazer aqui os principais insights, que acredito serem um grande passo para a próxima geração de modelos de linguagem.

🔍 O Problema: Transformers Não Sabem "Lembrar"

Um Transformer não tem um mecanismo nativo para recuperar conhecimento. Toda vez que ele precisa de uma informação como "Diana, Princesa de Gales", ele gasta várias camadas computacionais para reconstruir essa informação a partir do contexto.

É como se, em vez de consultar uma enciclopédia, ele tentasse redescobrir a história inteira a cada pergunta.

No paper, os autores mostram que, em um modelo tradicional, são necessárias cerca de 6 camadas para formar uma representação completa dessa entidade. Isso é ineficiente: o modelo está usando raciocínio profundo para fazer algo que poderia ser resolvido com uma simples consulta a uma tabela de memória.

💡 A Solução: Engram (Memória Condicional)

O Engram introduz um novo tipo de "órgão" no modelo: um módulo de memória estática que funciona como um banco de dados de padrões linguísticos.

Como funciona na prática:

O modelo identifica um padrão local (ex: "Princesa de Gales")

Ele usa esse padrão como chave para buscar um vetor de memória pré-armazenado (via hashing)

Esse vetor é injetado diretamente nas camadas profundas do modelo

O resultado? O modelo não precisa mais gastar camadas iniciais reconstruindo informação. Ele já começa com um "atalho" para o conhecimento.

📊 O Resultado na Prática

Os pesquisadores treinaram um modelo chamado Engram-27B e compararam com um modelo tradicional de mesmo tamanho e mesmo custo computacional (MoE-27B). Os resultados:

Benchmark	Domínio	Ganho
MMLU	Conhecimento geral	+3,4%
BBH	Raciocínio complexo	+5,0%
HumanEval	Geração de código	+3,0%
MATH	Matemática	+2,4%

O mais interessante? O Engram melhorou até tarefas de raciocínio, não só de memorização.

Isso acontece porque, ao liberar as primeiras camadas do trabalho de reconstrução, o modelo pode usá-las para "pensar" mais profundamente. Os autores chamam isso de "aumento da profundidade efetiva" da rede.

🧠 Por Que Isso É uma "Nova Dimensão de Esparsidade"?

Até agora, a principal forma de escalar modelos sem aumentar custo computacional era o MoE (Mixture of Experts), que ativa apenas alguns "especialistas" por vez.

O Engram introduz uma segunda dimensão:

Abordagem	Função	Como funciona
MoE	Processa lógica dinâmica	Ativa especialistas (cálculo)
Engram	Recupera conhecimento	Ativa memórias (busca O(1))

Juntos, formam uma dupla poderosa. E o melhor: o Engram é tão eficiente que pode armazenar 100 bilhões de parâmetros na memória RAM do computador sem prejudicar a velocidade — algo impossível com MoE puro.

🔧 Detalhes Técnicos

Se você quer entender melhor a arquitetura:

Compressão do tokenizer: Redução de 23% no vocabulário via normalização (NFKC, lowercasing)
Multi-head hashing: 8 cabeças de hash para cada ordem de N-gram (2 e 3)
Gating contextual: O estado oculto atual decide quanto da memória recuperada deve ser integrada
Posicionamento estratégico: Inserido nas camadas 2 e 15 para equilibrar intervenção precoce com riqueza contextual

O código está disponível no GitHub:

👉 https://github.com/deepseek-ai/Engram

🧭 Conclusão

O Engram mostra que, assim como o cérebro humano, os modelos de IA podem se beneficiar de mecanismos especializados. Ter um sistema separado para memória de longo prazo e outro para raciocínio dinâmico não só torna os modelos mais eficientes, como libera capacidade computacional para o que realmente importa: pensar com profundidade.

Essa pode ser uma das direções mais importantes para os LLMs do futuro: modelos que sabem quando pensar e quando lembrar.

📚 Fonte e Créditos

Paper original: "Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models"
Autores: Xin Cheng, Wangding Zeng, Damai Dai, et al. (Peking University & DeepSeek-AI)

Usei ferramentas de IA para me auxiliar na consolidação e organização das ideias.