Pitch: Estava cansado de restartar containers com OOM, debugar logs de chrome que não diziam nada e ter que adivinhar qual seria o problema do dia, então criei o primeiro Browser-as-a-Service focado em scraping do Brasil

Acordar logo cedo com emails da LocaWeb falando que restartou sua VPS por que a CPU ou a RAM antigiram niveis absurdamente altos faz parte rotina de quem gerencia web scraping em escala. O Linux aciona o OOM Killer sem nem te oferecer um jantar antes. Você abre os logs do Docker e no maior estilo mestre dos magos, ele não te diz nada com nada. O Selenium menos ainda. E o Puppeteer? Apenas desiste.

Manter a automação de navegadores em produção é lidar diariamente com vazamento de memória, problemas de rede e race conditions em bootstrappers que você nem seuqer sabia que existiam. A infraestrutura rouba o tempo que você deveria gastar extraindo e estruturando dados ou melhorando sua automação.

Foi por falta de ter o que fazer para resolver essa dor arquitetural que eu criei o pain.headless. O objetivo é entregar o primeiro Browser-as-a-Service focado no mercado brasileiro. A proposta de valor é simples e direta. Nós abstraímos toda a infraestrutura suja de gerenciamento de containers, rotação de rede e mitigação de bloqueios. Garantimos a privacidade operacional mantendo logs apenas para auditoria de conexões. Nunca lemos ou armazenamos o HTML que você raspa.

A infra por trás

Um dos principais problemas que encontrei criando pain.headless: a latência para iniciar o browser. Sabia que não ia rolar deixar nosso user esperando 2 minutos para um chrome iniciar, então fui atrás de uma implementação que resolvesse isso sem nos custar os olhos da cara.

A solução mais eficiente que encontrei para minha arquitetura foi criar um pool dinâmico de navegadores em nuvem que estariam prontos para pegar sua sessão. Criei algumas locks e um gerenciador de lifecycle dos Chromes para garantir que os navegadores fossem unicos e que sempre iniciassem do mesmo ponto. Porém, todavia, entretanto, nossa proposta é que qualquer pessoa possa rodar mil scrapings ao mesmo tempo, e o budget simplesmente não permitia ter um taco pra aguentar tudo isso. O caminho escolhido aqui foi containerizar todo o nosso pool, e utilizar maquinas elasticas no fly.io para sempre que um dos nossos pools de navegadores atingir 90% da capacidade, ele subir um novo. Caso o pool original (always-on) volte a ficar abaixo dos 90%, o sistema espera ate que todas as sessões do pool do fly sejam encerradas e mata a instancia. Precisamos de quase um dia e muito Mango Loco para configurar tudo isso com um HAProxy decente e fazer funcionar, mas o fly faz um warm boot maravilhoso e tem um modelo de pay-as-you-go mais do que justo para nosso use-case.

Para o stealth (que seria a metade direita do nosso coração) dos scrapings, cada sessão instanciada pelos nossos SDKs já nasce com injeções no protocolo CDP (Chrome DevTools Protocol). Nós mascaramos o fingerprinting da máquina, alteramos os buffers e providers de WebGL e removemos os rastros de automação do JavaScript (que vão muito além do objeto navigator.webdriver). Também vale destacar algumas camadas mais profundas que nossa ferramenta (as vozes da minha cabeça me obrigaram a falar sobre): mascarar o TLS fingerprint (algo que em navegadores controlados se encontra incrivelmente dificil de ser feito), ocultar assinaturas de funções modificadas/injetadas e simular comportamento humano real (não esse seu sleep com random que não engana ninguém).

Você não precisa mais lidar com um container hell, configurar variáveis de ambiente complexas ou instalar plugins de stealth. O container que atende a sua requisição já possui a rede pronta pra ser roteada para nossos pools de proxies residenciais e os scripts de injeção carregados na memória.

Você é um humano?

Uma das maiores fontes de quebras de automação é a injeção aleatória de captchas na tela. Tratar isso no código exige blocos complexos de try/catch e integrações pesadas com APIs de terceiros (quem já teve que usar CapSolver ou 2Captcha sabe do que estamos falando). Nós embutimos a resolução de captchas direto no motor do navegador.

Nossa infraestrutura identifica e resolve nativamente os seguintes desafios:

• Cloudflare Challenge e Turnstile
• RecaptchaV3 e V2
• Desafios genéricos de Image-To-Text
• O WAF da AWS

O diferencial da nossa arquitetura é a cobrança condicional. Você pode literalmente chamar o resolvedor a todo momento para prevenção em targets mais complexos que nós apenas debitamos os créditos de resolução se o captcha realmente aparecer no DOM da página atual e for resolvido com sucesso. Isso elimina o desperdício financeiro de acionar solvers em páginas que carregaram perfeitamente.

import { StealthBrowser } from 'pain-headless';

async function extractData() {
  const browser = new StealthBrowser({ apiKey: 'sua-api-key' });
  
  await browser.goTo('https://site-protegido.com');

  // Se um captcha da lista for encontrado, sera resolvido automaticamente, caso contrario, vida que segue
  await browser.solveSimpleCaptcha({ throwOnNoCaptcha: false })
  
  // ...
}

PROXIES. ELES. SÃO. MUITO. CHATOS.

Rotacionar IPs/DSNs e lidar com desconexão e retries na mão acaba com sua sanidade. O pain.headless resolve o roteamento de tráfego integrando dois sistema de proxies residenciais embutidos prontos pra usar.

O primeiro sistema que disponibilizamos é o de proxies residenciais ISP, que nada mais são do que IPs de data-center assinados por provedores de internet residencial (Claro, Vivo, etc.). A vantagem deles com certeza é a velocidade, considerando que são bem mais rápidos que os proxies residenciais tradicionais. Chamamos esses proxies de simple proxies dentro do nosso ecossistema, e disponibilizamos 1 proxy para cada sessão simultânea do seu plano (apenas em planos Prod ou superior), podendo escolher a localização entre 170 países.

O outro tipo de proxies embutidos que o pain.headless te permite usar são nossos proxies premium residenciais. Aqui, caso você não esteja familiarizado, se trata de uma conexão diretamente com o dispositivo residencial de uma pessoa comum, que cede sua rede ao usar apps gratuitos. A beleza de usa-los, como disse no início desse tópico, é que gerenciamos desconexões, rotação e caso o IP atual caia durante a navegação, atribuimos um novo na mesma localização sem derrubar sua sessão e sem precisar de ação manual.

Todos os planos possuem acesso aos proxies residenciais premium, e você pode operá-los tanto em modo sticky (mantendo o IP fixo durante a sessão) ou rotativo. No modo rotativo, a mudança de IP na rede ocorre exatamente quando você chama o método goTo. O IP alterado se mantém estável para carregar todos os assets daquela página e só rotaciona novamente na próxima navegação explícita.

O custo de rede também é transparente, previsível e diferente dos players comuns do mercado, é justo. Nos simple proxies, não existe nenhum gasto extra de créditos por tráfego, já nos proxies premium, descontamos 75 créditos a cada 50MB de dados baixados/enviados pela rede.

Ta, mas quanto custa essa facilidade?

Nós optamos por um modelo baseado em créditos computacionais para garantir previsibilidade financeira pra nossos clientes, ao mesmo tempo que mantemos um modelo estável e sáudavel de faturamento.

Os valores e pacotes listados abaixo são válidos para a data atual de publicação deste artigo. Para mais detalhes, cotações personalizadas ou modelo pay-as-you-go, acesse nosso site clicando aqui.

• Script (R$130/mês): 10.000 créditos, 1 sessão concorrente. Ideal para jobs em background. Você ganha 2 minutos grátis de execução por sessão.
• Prod (R$399/mês): 50.000 créditos, 3 sessões concorrentes. Acesso às 3 localizações de proxies. Inclui 5 minutos grátis por sessão.
• Cluster (R$1.000/mês): 200.000 créditos, 8 sessões concorrentes. Inclui 15 minutos grátis por sessão para fluxos longos de raspagem.
• Uso excedente: Cobramos apenas 15 créditos por minuto adicional de tempo de máquina. Para evitar desperdícios por scripts travados, encerramos conexões automaticamente após 5 minutos de inatividade explicita.

Para ver exemplos reais e funcionais de automações no pain.headless e verificar nossos SDKs em Node.js/TypeScript e Python, visite nosso perfil no GitHub.

Estamos procurando voluntários

Antes de ir embora, tenho um pequeno pedido pra vocês leitores. Nosso produto está pronto, rodando, mas não tem graça vender um colete a prova de balas em que só eu atiro. Estou rodando um programa de BETA test aberto para a comunidade.

Para os desenvolvedores dispostos a testar os limites do nosso SDK em cenários locais de automação, estamos liberando 3.000 créditos temporários sem custo nenhum. Precisa apenas entrar em contato pelo formulário do site. E para os engenheiros interessados em migrar sua infraestrutura e contratar o serviço desde já, estamos fornecendo um bônus de 10.000 créditos no setup inicial durante seus primeiros 2 meses. Além do volume extra de requisições, esses early adopters terão suporte premium vitalício para implementação e debug.

Espero poder falar diretamente com alguns de vocês muito em breve. Que a força esteja com vocês.