Pitch: Subi meu primeiro OpenSource: escreveaqui.com.br
Há alguns meses eu publiquei aqui um pitch do Escreve Aqui, um bloco de notas online anônimo, sem cadastro e open source, inspirado no Dontpad. Na época era código que rodava no meu localhost e um pedido de ajuda com o deploy.
Agora está no ar de verdade: https://escreveaqui.com.br
É o meu primeiro projeto open source que sai do "funciona na minha máquina" e vira uma coisa pública, com domínio, com gente estranha, com a conta chegando no meu nome. E a lição que eu tiro disso não é sobre Java nem sobre React. É que a parte difícil de um projeto pessoal não é escrever, é sustentar.
Escrevi o relato técnico completo no Medium, e recomendo pra quem quer o passo a passo das decisões: Escreve Aqui: editor de texto anônimo, sem login e de código aberto. Aqui embaixo eu conto a versão curta, porque metade do que tornou esse artigo bom veio dos comentários do meu post anterior, aqui no TabNews.
O que os comentários daqui me deram
Duas coisas que eu não tinha e que mudaram tudo.
O usuário marcbarbosa largou um link. Era a thread de maio de 2011 na lista Startup Brasil, arquivada no Google Groups, onde o Dontpad foi apresentado publicamente pela primeira vez. Ler aquilo foi arqueologia digital (se o termo existir). O produto saiu de um dojo de um dia no Mar de Agilidade, antes se chamava Notepaedia, e na época fazia cerca de 40 arquivos editados por dia.
O melhor é o que acontece na thread. Praticamente todo mundo pede login, senha, versionamento, barra de formatação e lista de anotações. E o Rodrigo recusa quase tudo, defendendo o conceito de loginless e a tese de que a URL é a senha. Uma única sugestão foi aceita e implementada em dias: mover a lista de arquivos para a lateral.
E aí o próprio Rodrigo de Toledo comentou no meu post. Contou que são quatro fundadores, que hoje são cerca de 250 mil pessoas usando por mês, que ninguém ficou rico e que durante quase toda a história eles pagaram hospedagem do próprio bolso. Os anúncios são recentes e existem só para quem usa com mais frequência.
Isso reposicionou o projeto na minha cabeça. Eu tinha usado "tem anúncio" como uma das justificativas para começar. Os anúncios são, na prática, a conta de quinze anos de hospedagem chegando.
O que tem de técnico
Normalização de slug com NFD, e a consequência de segurança: se a URL é a senha, normalizar a URL reduz o espaço de chaves.
Saí de JPA para JdbcTemplate por performance. Trocar SELECT seguido de INSERT ou UPDATE por INSERT ... ON CONFLICT (slug) DO UPDATE corta o salvamento de duas idas ao banco para uma. Junto veio um ganho que eu não tinha buscado: como o upsert é atômico, sumiu a janela de corrida entre ler e escrever, e o tratamento de conflito de edição deixou de fazer sentido no fluxo.
RETURNING (xmax = 0) AS inserted para saber se a operação criou ou atualizou sem consulta adicional.
Cache Caffeine com TTL de 30s e @CacheEvict no PUT. O TTL não é o mecanismo de atualização. E o porquê de não ser Redis: não é performance, é eu não saber usar Redis.
Polling de 2s com ETag e If-None-Match respondendo 304, mais Page Visibility API pausando abas em segundo plano. Mais uma coisa: não foi escolha entre WebSocket e polling. Eu não sei WebSocket. Foi o conhecimento que eu tinha guiando a arquitetura, e a pergunta que sobrou foi como fazer polling sem desperdício, que me ensinou requisição condicional.
Eu falei isso no artigo, mas repito aqui: "E, neste caso, preferi uma solução que consigo entender, implementar, testar e manter com segurança, em vez de introduzir tecnologias que eu ainda não domino apenas porque, no papel, poderiam ser escolhas mais sofisticadas."
E o deploy, que era o pedido original
Foi a etapa mais difícil do projeto inteiro, o que é bem irônico considerando que eu passei a trabalhar como Analista de DevOps Trainee pouco tempo depois.
Java em contêiner não cabe confortavelmente em camada gratuita, e Postgres gerenciado grátis suspende por inatividade. Uma ferramenta cujo valor inteiro é ser instantânea não pode levar oito segundos para acordar, então cold start estava fora de discussão.
A saída foi VPS própria com Docker Compose orquestrando tudo, sempre acordada, custo fixo e conhecido. E isso validou três decisões que antes eram só argumento no papel. Caffeine em vez de Redis passou a fazer sentido de fato.
O que não está resolvido: as defesas contra abuso ainda são só estruturais. Limite de tamanho por nota, validação estrita de slug, PUT idempotente e expiração em 30 dias. Não há rate limiting por IP e não há desafio invisível. Isso segura acidente, não segura script. É a primeira coisa da fila, e é onde eu mais aceito ajuda.
Sobre o Dontpad
Fica registrado de novo: eu gosto muito do Dontpad. O Escreve Aqui é projeto de estudos e homenagem, não concorrente. Se você precisa colar um texto agora, usa o que estiver mais à mão.
Se você já subiu um primeiro projeto e lembra dessa sensação de ver gente que você não conhece usando uma coisa sua, vai gostar do relato completo. E se ainda não subiu, talvez ele te convença de que a parte chata do deploy vale a pena.
No ar: https://escreveaqui.com.br
Repositório: https://github.com/Navelogic/escreveaqui
Continuo aceitando porrada no código. O que eu mais preciso hoje é ideia de anti-abuso sem atrito e ajuda com testes automatizados, que é a issue que mais me incomoda.
E obrigado a quem comentou no post anterior. E obrigado por ler esse aqui!