Subi meu primeiro opensource e descobri que a parte difícil não é programar, é manter no ar!

Faz um tempo que eu estudo o Dontpad por curiosidade. Ferramenta brasileira, de 2011, faz uma coisa só e faz muito bem: você inventa uma URL, ela existe, você escreve, ela salva. Sem cadastro, sem onboarding, sem nada.

Resolvi reconstruir isso do zero como projeto de estudos, pra entender quantas decisões de engenharia estão escondidas dentro de uma ferramenta. Chamei de Escreve Aqui, é MIT, e agora está no ar de verdade: https://escreveaqui.com.br

É o meu primeiro open source que sai do "funciona na minha máquina" e vira coisa pública, com domínio e gente usando. E a lição não foi sobre Java nem React. Foi que a parte difícil de um projeto pessoal é sustentar, não escrever.

Antes de tudo: eu gosto muito do Dontpad. O Escreve Aqui não é concorrente, não é "alternativa melhor". É laboratório e homenagem.

Ele foi constuido em Java 21 com Spring Boot 4 e PostgreSQL no backend, React 19 com TypeScript e Vite no frontend. A API tem dois endpoints. A tabela tem cinco colunas. É nisso que está a graça.

Umas decisões que renderam:

• Comecei com JPA por reflexo, produto do ensino de Java com Spring no Brasil, e migrei pra JdbcTemplate por performance: INSERT ... ON CONFLICT (slug) DO UPDATE corta o salvamento de duas idas ao banco pra uma. De brinde veio a atomicidade, que eu não tinha ido buscar. Como não tem mais leitura prévia, sumiu a janela de corrida entre ler e escrever, e o tratamento de conflito de edição deixou de fazer sentido no fluxo. Se isso for óbvio pra quem vem de MySQL, aceito o skill issue.
• RETURNING (xmax = 0) AS inserted pra saber se criou ou atualizou sem query extra. Em linha recém inserida o xmax é zero, em linha atualizada por ON CONFLICT ele carrega a transação.
• Cache Caffeine com TTL de 30s e CacheEvict no PUT. Não usei Redis não por performance, mas porque é mais um servidor pra manter, e porque eu ainda não domino Redis como domino Caffeine. Pra um projeto desse porte, não valia introduzir uma tecnologia que eu não sei manter em produção só porque no papel soa mais sofisticada.
• Polling de 2s com ETag e If-None-Match respondendo 304 em nota parada, e Page Visibility API pausando o ciclo quando a aba vai pro segundo plano. Não foi WebSocket porque eu não sei WebSocket. Foi o que eu sabia construir, e a pergunta virou como fazer polling sem desperdiçar banda, que me ensinou requisição condicional.
• Normalização de slug com NFD pra Minha Nota e minha-nota não virarem documentos diferentes. Detalhe que ninguém comenta: se a URL é a senha, normalizar reduz o espaço de chaves.
• O cursor pisca ciclando nas cores da bandeira via caret-color. É bobo mas eu queria essa identidade.

Sobre o Redis e o WebSocket, já adianto a resposta pro comentário que sempre vem: eu conheço os princípios dos dois. Sei o que resolvem e quando usar. O que eu ainda não tenho é fluência pra produzir com eles no mesmo nível de confiança que tenho com o que escolhi. Existe diferença entre conhecer uma tecnologia e ter domínio pra levar ela pra produção, e eu preferi entregar algo que consigo entender, testar e manter.

A parte difícil: Não é tecnicamente complicado... docker compose com Spring Boot e Postgres é trabalho conhecido. É que Java em contêiner não cabe bem em free tier, Postgres gerenciado gratuito suspende por inatividade, e uma ferramenta cujo valor inteiro é ser instantânea não pode demorar oito segundos pra acordar.

Terminou em VPS própria com tudo em contêiner. Máquina sempre acordada, custo fixo e previsível.

O que ainda não resolvi: sem login, nada impede robô de criar nota infinita. Hoje só tenho defesa estrutural, ou seja, limite de tamanho, validação de slug, PUT idempotente e expiração em 30 dias. Não tem rate limit por IP nem desafio invisível. Alguém comentou no TabNews uma frase que resume o dilema melhor que qualquer whitepaper: existe uma sobreposição entre os usuários mais distraídos e os robôs mais espertos.

A parte que me pegou de verdade: quando publiquei o projeto aqui, alguém colou o link de uma thread de maio de 2011 na lista Startup Brasil, arquivada no Google Groups, onde o Dontpad foi apresentado publicamente pela primeira vez. Na thread, praticamente todo mundo pede login, senha, versionamento e barra de formatação. O criador recusa quase tudo e defende que a URL é a senha.

Aí o próprio criador apareceu nos comentários do meu post, quinze anos depois, contando que são quatro fundadores, cerca de 250 mil usuários mensais, e que durante quase toda a história eles pagaram hospedagem do próprio bolso. Os anúncios que eu usei como justificativa pra começar o projeto são, na prática, a conta de quinze anos chegando.

Repositório: https://github.com/Navelogic/escreveaqui

Aceito porrada no código. O que eu mais preciso hoje é ideia de anti-abuso sem atrito e ajuda com testes automatizados.

E se quiser ver o meu relato completo. Fica aqui o link.