Olá, sou Felipe Gusmão 👋

No dashboard do Ponto Glass, duas abas carregavam bibliotecas pesadas: exportação de PDF (~300 KB com jspdf) e exportação de Excel (~200 KB com xlsx). Ambas eram importadas no topo do arquivo — mesmo que o usuário nunca abrisse essas abas.

A solução foi substituir por next/dynamic com { ssr: false }:

const RelatoriosTab = dynamic(() => import("./RelatoriosTab"), { ssr: false });
const RegistrosTab = dynamic(() => import("./RegistrosTab"), { ssr: false });

Resultado: aproximadamente 500 KB a menos no bundle inicial. O único custo é um estado de loading na primeira abertura de cada aba — aceitável para funcionalidades de uso eventual.

O critério para aplicar lazy loading: o componente precisa satisfazer duas condições simultaneamente — (1) conter bibliotecas ou lógica pesada e (2) não estar visível no carregamento inicial. Lazy loading em componentes leves ou acima da dobra piora a experiência sem nenhum ganho de performance mensurável.

A abordagem mais comum para isolar dados de múltiplos tenants é validar o perfil do usuário na camada de aplicação antes de cada query. O problema: qualquer falha nessa lógica pode expor dados de outras empresas.

Row Level Security (RLS) move esse controle para dentro do PostgreSQL. Com RLS ativado, toda query é automaticamente filtrada pelas políticas definidas no banco — independentemente de como foi construída na aplicação.

-- retorna apenas registros da empresa do usuário autenticado
CREATE POLICY "users see own company"
ON registros_ponto
FOR SELECT
USING (empresa_id = (auth.jwt() ->> 'empresa_id')::uuid);

O Supabase expõe o JWT do usuário autenticado diretamente nas políticas via auth.jwt(), tornando o padrão direto de implementar. O benefício central: o isolamento funciona por padrão — via aplicação, Supabase Studio ou qualquer cliente SQL.

No Ponto Glass, RLS foi o mecanismo de separação entre empresas: cada empresa enxerga apenas seus próprios trabalhadores, registros e relatórios, sem nenhuma lógica adicional na camada de aplicação para garantir isso.

Regra prática: se uma tabela contém dados de múltiplos tenants, RLS é mais seguro e mais confiável do que isolamento implementado no servidor.

Window functions resolvem uma limitação central do GROUP BY: a perda do detalhe das linhas originais após a agregação.

Com RANK(), ROW_NUMBER(), LAG() e LEAD(), os cálculos analíticos são executados sobre o conjunto de linhas original — sem colapsá-lo. É possível manter o nível de detalhe e acessar o valor calculado na mesma linha.

Um exemplo concreto: calcular o crescimento mês a mês de receita. Com LAG(), é uma expressão na cláusula SELECT:

receita - LAG(receita) OVER (ORDER BY mes) AS variacao_mom

Sem window functions, o mesmo resultado exigiria uma CTE para materializar o mês anterior e um join posterior — mais código e mais pontos de falha.

Casos de uso mais comuns:

• Ranking de clientes ou produtos por métrica — RANK, DENSE_RANK
• Numeração sequencial de registros por grupo — ROW_NUMBER
• Comparação com período anterior ou seguinte — LAG, LEAD
• Totais acumulados — SUM ... OVER (ORDER BY ...)

A questão “SQL ou Python?” é recorrente, mas a resposta depende menos de preferência e mais do contexto do problema.

Prefira SQL quando:

• Os dados estão no banco e a transformação pode ser executada na própria fonte — joins, agregações e filtros em grande volume são otimizados pelo banco por padrão
• O resultado precisa ser compartilhado com outras ferramentas que consomem diretamente do banco

Prefira Python quando:

• A lógica exige expressividade que SQL não oferece nativamente — machine learning, manipulação de texto complexa, integração com APIs externas
• O pipeline combina múltiplas fontes heterogêneas
• A etapa final é uma visualização, relatório automatizado ou modelo preditivo

Na prática, o fluxo mais eficiente é composto: SQL para extração e agregação na fonte, Python para análise, modelagem e visualização. Tentar fazer tudo em uma única ferramenta normalmente gera atrito desnecessário.

O critério decisivo: qual das duas resolve esse problema específico com menor overhead?

A sintaxe de filtragem booleana padrão do pandas funciona, mas se torna verbosa rapidamente com múltiplas condições. O método .query() oferece uma alternativa mais expressiva:

# filtragem booleana padrão
df[(df["status"] == "completed") & (df["total"] > 100)]

# com .query()
df.query("status == 'completed' and total > 100")

Para referenciar variáveis do escopo externo, use o prefixo @:

threshold = 100
df.query("total > @threshold")

.query() é especialmente vantajoso em notebooks, onde a legibilidade do código tem peso tão grande quanto o resultado em si. Para filtragens que envolvem índices, operações vetorizadas ou chamadas de método, a sintaxe booleana padrão ainda é a escolha mais adequada.