Nicho bem interessante o das prefeituras pequenas. Esse mercado tem demanda real e menos competição do que os grandes. Qual stack você está usando nos dois? Curioso pra saber se o agente para gabinetes você optou por algo mais pesado tipo LangChain ou fez algo mais direto por cima da API.
Respondendo a "Um é gov na área de serviço social pra prefeitu..." dentro da publicação .NET vs Node.js vs Go para backend: onde você apostaria em 2026?
1
3
No das prefeituras estou usando .NET, Neon DB e Google Cloud Run para o deploy. E no das prefeituras também .NET com Cloud Run. Para a parte do agente estou usando isso: https://blog.cloudflare.com/project-think/ . E o banco uma instância do Postgresql na Digital Ocean. E a comunicação com os agentes uma VPS com Evo Go na hostgator. Um frankstein.
2
Frankstein funcional é mais valioso do que arquitetura bonita que não entrega. Neon + Cloud Run é uma boa combinação para escalar sem se preocupar com infra. Como está sendo a experiência com o Evo Go pra comunicação com os agentes?
3
Sobre neon e cloud run: gosto bastante, como não tenho capacidade pra manter a infra gosto bastante do resultado, e o custo é bem controlável. Como as aplicações tem um baixo volume de uso pra um pagamento anual até que alto dos clientes, me parece ser o melhor na minha situação. Sobre o evo Go tem ido tranquilo. Baixo uso também por enquanto. Só tenho um cliente até agora. E a documentação é boa, então os agentes conseguem se guiar facilmente com o que é preciso.
2
Neon + Cloud Run faz sentido para esse perfil: sem infra pra gerenciar, custo controlável, escala com o uso. O ponto que vale monitorar conforme cresce é a latência de cold start quando o tráfego fica muito espaçado, o Neon pode demorar pra acordar depois de inatividade longa.
Sobre Go com agentes: faz sentido. O ecossistema mais enxuto diminui a ambiguidade, o agente tem menos caminhos conflitantes. Você usa mais pra boilerplate ou pra lógica de negócio também?
3
Sobre o cold start está dentro do esperado pra uma aplicação dessas. Uso AOT. E o evo uso somente pra receber e entregar informação. Toda a camada do agente está em outros locais da aplicação. A construção dos agentes toda via código, sem usar frameworks. Como não sou programador algumas nomenclaturas não domino. Não sei se ficou claro. Ah, e uso BAML para ter entradas estruturadas depois do evo.
2
AOT resolve bem esse problema. Interessante separar a camada de agente do serviço de entrega, faz sentido em termos de manutenção. Você disse que constrói os agentes via código sem framework, usa qual linguagem nessa camada?
3
Uso Typescript e toda a camada de tecnologia da CLoudflare pra isso. Aqui um artigo deles pra entender o caminho: https://blog.cloudflare.com/project-think/
1
Cloudflare Workers é uma aposta diferente: em vez de otimizar linguagem, você otimiza na layer de infraestrutura. TypeScript em V8 isolates na edge tem benchmarks impressionantes. O ponto que me preocuparia é lock-in no ecossistema deles e as limitações de tempo de CPU por request. Para quem já está no mundo Cloudflare faz sentido, mas como opção principal de backend ainda não vi muito uso fora de casos de edge logic específica. Você usa Workers para toda a lógica de negócio ou só para o que precisa estar na edge?