Quem desenvolve ou administra ambientes Protheus conhece bem esse dilema: como rodar cálculos pesados, relatórios analíticos volumosos e integrações contínuas sem drenar a memória e travar as threads do AppServer?
Muitas vezes a resposta do mercado é criar microsserviços em outras linguagens. Mas isso traz uma barreira: exige outra stack, outra curva de aprendizado e distancia o time do ecossistema onde a regra de negócio vive.
Pensando em dar mais fôlego sistêmico, alternativas reais e independência à comunidade, estou desenvolvendo o hb.bridge 🚀
A ideia central do projeto:
Criar uma ponte de alta performance entre o Protheus (TLPP/AdvPL) e o ecossistema Harbour/xHarbour, com um núcleo veloz em C e Zig.
Por que essa abordagem faz sentido na prática?
🔹 Fôlego Sistêmico Real: rotinas que exigem computação pesada rodam em um processo nativo, independente e leve, preservando o AppServer para a operação transacional do ERP.
🔹 Zero Fricção de Aprendizado: desenvolvedores AdvPL e TLPP já dominam a sintaxe e a lógica xBase do Harbour desde o primeiro minuto.
🔹 100% Opcional e Desacoplado: você não mexe no core do ERP. Pluga a solução pontualmente onde há gargalo de performance.
🔹 Integração Nativa com a UI: no exemplo prático do repositório (hbbridge.browse.data.test.tlpp), mostro como os dados processados no Harbour alimentam diretamente uma tela de FWMBrowse com navegação fluida.
O projeto ainda está em desenvolvimento ativo, mas com uma arquitetura sólida e planos de evoluir bastante.
Arraste o carrossel abaixo para conferir a visão técnica detalhada! 👇
Repositório no GitHub:
👉 https://github.com/naldodj/hb.bridge
Exemplo em TLPP (Browse de Dados):
👉 https://raw.githubusercontent.com/naldodj/hb.bridge/refs/heads/main/src/tlpp/tests/protheus/hbbridge.browse.data.test.tlpp
Feedbacks, sugestões de casos de uso e contribuições são muito bem-vindos. O que você achou dessa abordagem?
#TOTVS #Protheus #AdvPL #TLPP #Harbour #OpenSource #SoftwareArchitecture #ERP #DevCommunity
Comentários
Postar um comentário