Se você trabalha na internet, provavelmente já precisou converter um arquivo, validar um CNPJ ou calcular uma rescisão trabalhista e acabou caindo em um site poluído de anúncios, lento ou que exigia cadastro pago após três usos. Muitas dessas plataformas (como o TinyWow ou o Smallpdf) dominam o mercado global. Porém, para nós, desenvolvedores e criadores de produtos no Brasil, existem dois grandes problemas nesse modelo tradicional: o custo absurdo de infraestrutura em nuvem para processar arquivos de terceiros e o risco de privacidade sob a LGPD ao exigir que o usuário faça upload de dados sensíveis para um servidor desconhecido.
Para resolver isso no meu projeto, o CentralTools, decidi seguir uma abordagem arquitetônica diferente: o processamento 100% no lado do cliente (Client-Side).
O Gargalo Financeiro e o Risco da Nuvem
No modelo tradicional, o fluxo é simples:
- O usuário faz o upload de um arquivo ou digita dados na tela.
- O servidor (backend) recebe esses dados, processa (usando bibliotecas pesadas) e gera o output.
- O servidor envia o arquivo de volta e o armazena temporariamente.
Se você tem milhares de acessos simultâneos gerando PDFs, comprimindo imagens ou rodando scripts, a sua conta da AWS, Azure ou DigitalOcean vai para a estratosfera. Além disso, se um usuário digita dados de clientes, informações contratuais ou logs de sistemas empresariais, você se torna o operador daqueles dados sob a LGPD. Qualquer vazamento é sua responsabilidade.
A Solução: Arquitetura Baseada no Navegador
Para contornar isso, centralizei as ferramentas do portal utilizando o poder de processamento do próprio navegador do usuário através de bibliotecas JavaScript executadas localmente.
Um exemplo prático disso é o nosso Gerador de PDF. Em vez de enviar o texto, o código HTML ou as imagens para uma API em nuvem compilar o documento, a renderização e a montagem do arquivo final acontecem inteiramente na máquina de quem está acessando.
As implicações práticas dessa escolha técnica são três:
- Privacidade Absoluta: O conteúdo digitado ou enviado nunca sai do computador do usuário. Se você abrir o painel de desenvolvedor do navegador (F12) e inspecionar a aba de rede (Network), verá que nenhuma requisição trafega dados sensíveis de volta para o servidor quando o PDF é gerado.
- Custo de Infraestrutura Próximo a Zero: Como o processamento pesado foi delegado para o hardware do cliente, o servidor do site atua predominantemente servindo arquivos estáticos e scripts otimizados. Isso me permite manter mais de 270 ferramentas no ar sem precisar de uma infraestrutura multimilionária.
- Sem Fila de Espera: Não existe latência de rede para upload ou download de arquivos gigantes, nem filas de processamento quando o site está com pico de tráfego. É instantâneo.
Desafio do Modelo Local
Nem tudo são flores na arquitetura client-side. O principal trade-off é que documentos ou mídias extremamente extensas consomem a memória RAM do próprio navegador. Se o usuário tentar compilar um PDF com milhares de páginas ou imagens pesadíssimas localmente, a aba do navegador pode travar devido aos limites de alocação de memória do motor V8.
Para resolver isso, o sistema trabalha com um modelo híbrido controlado por limites de tamanho de arquivo, onde o plano gratuito cobre com folga a necessidade de 99% dos usuários cotidianos, e processamentos massivos são gerenciados de forma escalonada.
Conclusão e Próximos Passos
Desenvolver ferramentas utilitárias não precisa ser sinônimo de infraestruturas caras e captura de dados. Respeitar a privacidade do usuário final criando arquiteturas que rodam localmente é um caminho sustentável para desenvolvedores independentes (indie hackers) criarem produtos competitivos e escaláveis.
Se você quiser inspecionar a rede, testar o gerador local ou precisar de alguma ferramenta para a sua rotina de desenvolvimento ou burocracia diária, dê uma olhada no projeto em centraltools.com.br.
O que você achou dessa abordagem de arquitetura para projetos solo? Deixe seu feedback nos comentários!