Arthur Albefaro

Contexto

Na Overload, o GoHighLevel concentra leads e contatos, enquanto os times de operação trabalham no Notion. Os dados nasciam no CRM e eram levados ao Notion manualmente — processo lento, sujeito a erro e sempre defasado.

Problema

Não havia integração entre as duas plataformas e os dados do CRM chegam de forma não padronizada (campos customizados, formatos inconsistentes e ausentes), o que impede o consumo direto e exige uma etapa de normalização.

Solução

Desenvolvi uma rotina de integração que consome a API do GoHighLevel, normaliza os registros e os escreve no Notion via API — evitando duplicar dados já sincronizados e tratando falhas registro a registro para não interromper a integração.

Resultado

• Eliminou a cópia manual de dados entre CRM e Notion.
• Base mais consistente no Notion para alimentar automações e dashboards internos.
• Lógica de normalização e sincronização reaproveitável para novas integrações.

Arquitetura

1. 01Extração: leitura dos registros através da API do GoHighLevel.
2. 02Normalização: padronização dos campos não estruturados do CRM (datas, telefones e campos customizados ausentes ou inconsistentes) para um formato consistente.
3. 03Sincronização: escrita no Notion via API com controle de duplicidade — verifica se o registro já existe antes de criar ou atualizar.
4. 04Resiliência: respeito aos limites de requisição das APIs, com retentativas, e isolamento de erros por registro.

Desafios técnicos

• Controle de duplicidade. Como a rotina roda repetidamente, não podia recriar no Notion registros já sincronizados — a escrita verifica a existência antes de criar ou atualizar.
• Limites de requisição das APIs. GoHighLevel e Notion impõem limites de chamadas. A integração controla o ritmo das requisições e refaz tentativas quando necessário.
• Dados não padronizados. Campos customizados ausentes ou com formatos inconsistentes dificultavam o consumo. Adicionei uma etapa de normalização tolerante a esses casos.
• Falhas parciais. Um registro inválido não podia derrubar o lote inteiro. O processamento isola o erro por registro e segue com os demais.

Tecnologias

Contexto

Projeto público para praticar design de API, modelagem de domínio bancário e organização de um backend em camadas, com usuários, contas e transações.

Problema

Implementar operações financeiras corretas (depósito, saque, transferência e extrato) com autenticação e persistência, garantindo que operações que tocam mais de uma conta não fiquem pela metade.

Solução

API REST em Express + TypeScript organizada em camadas (controller → service → repository), com autenticação JWT, senhas com hash (bcrypt), validação de entrada com Zod e PostgreSQL via Prisma. Depósito, saque e transferência são executados dentro de transações de banco.

Resultado

• API funcional com cadastro/login, contas, depósito, saque, transferência e extrato.
• Código público no GitHub, com Docker, variáveis de ambiente de exemplo e coleção Postman.

Arquitetura

1. 01Camada HTTP: rotas e controllers (auth, user, account, transaction) com validação de entrada via Zod.
2. 02Camada de serviço: regras de negócio (saldo, transferência entre contas, extrato).
3. 03Camada de repositório: acesso ao PostgreSQL via Prisma, isolando o domínio da persistência.
4. 04Autenticação JWT com middleware de proteção de rotas; senhas com hash bcrypt.
5. 05Transferência/depósito/saque dentro de transações Prisma ($transaction) e valores monetários em Decimal.
6. 06Tratamento de erros centralizado, headers de segurança (helmet) e CORS; Docker e coleção Postman para execução.

Desafios técnicos

• Consistência em transferências. A transferência altera duas contas — débito e crédito não podem ficar pela metade. Resolvido com transações do Prisma (`$transaction`), tudo-ou-nada.
• Valores monetários. Para evitar erros de ponto flutuante com dinheiro, os saldos usam Decimal em vez de número de ponto flutuante.
• Validação e erros. Entradas são validadas com Zod e casos como saldo insuficiente ou conta inexistente retornam respostas previsíveis, tratadas de forma centralizada.

Tecnologias

Contexto

Projeto acadêmico/prático para exercitar a integração entre uma interface em React e um backend em C#, com autenticação.

Problema

Disponibilizar um painel com login e exibição de dados, separando frontend e backend e definindo a comunicação entre eles.

Solução

Interface em React (TypeScript) consumindo uma API em C#, com autenticação protegendo o acesso ao painel.

Resultado

• Painel funcional com login e visualização de dados.
• Projeto secundário que mostra a integração entre frontend e backend.

Arquitetura

1. 01Frontend em React (TypeScript) para a interface e o consumo da API.
2. 02Backend em C# expondo a API consumida pelo painel.
3. 03Fluxo de login protegendo o acesso às telas.

Desafios técnicos

• Autenticação e acesso ao painel. Garantir que apenas usuários autenticados acessem o painel, no frontend e na API.
• Integração frontend ↔ backend. Definir os contratos de API e tratar estados de carregamento e erro no React.

Tecnologias