Quem faz
e como faz

O produto é um editor de código dentro do navegador, e o editor do VS Code (Monaco) é escrito em TypeScript: usar outra linguagem na frente significaria manter uma ponte para o componente mais importante da tela. No celular, uma base em Flutter entrega Android e iOS de uma vez, e a alternativa era manter dois aplicativos para o mesmo conteúdo. O controle de acesso ficou no banco, com regras por linha, em vez de numa camada de API: assim nenhuma rota nova pode esquecer de verificar permissão.

Reconhecimento de fala é uma área onde praticamente todo o ecossistema vive em Python: o modelo, a versão otimizada dele e as bibliotecas de áudio. Escrever a interface em outra linguagem só criaria uma ponte para chamar Python assim mesmo. A decisão mais forte aqui nem foi a linguagem, foi o destino: o programa roda na máquina da pessoa e não num servidor, porque áudio de reunião é dado sensível e a promessa do produto é que ele não sai do computador. Isso obriga a empacotar como executável para os três sistemas.

Duas exigências que costumam brigar entre si: a parte pública precisa ser encontrada por busca, e a parte interna precisa de login. Renderizar no servidor resolve a primeira; ter as duas no mesmo projeto evita manter dois sistemas que compartilham o mesmo conteúdo. Vai para servidor próprio, e não para plataforma gerenciada, porque o cliente já tinha outros serviços na mesma máquina e separar aumentaria a conta sem resolver nada.

O jogo roda num evento presencial, e a pessoa joga por alguns minutos entre uma conversa e outra. Ninguém instala um aplicativo para isso: qualquer passo antes de jogar derruba metade do público. Isso descarta o nativo e leva ao navegador. Pela mesma razão, a biblioteca de jogo escolhida foi uma bem pequena, e não um motor completo: um motor grande resolveria problemas que este jogo não tem e custaria vários megabytes no telefone de quem está no 4G do evento.

É o projeto onde duas linguagens se justificam, e a fronteira entre elas não é gosto: as bibliotecas maduras de identificação e mascaramento de dado pessoal são Python, e o que existe em JavaScript para isso é sensivelmente mais fraco. Como essa etapa é a promessa central do produto, ela decide a linguagem do serviço, e não o contrário. A interface é web e fica em TypeScript. A fronteira entre as duas é uma só, explícita, e tudo que é dado sensível fica de um lado dela.

A loja e o painel de administração mexem no mesmo catálogo, então o modelo de dados tem de ser um só e as regras de negócio precisam morar num lugar onde as duas telas cheguem. Daí um serviço próprio em vez de deixar tudo dentro do site. Manter as duas partes no mesmo repositório foi para o tipo do banco chegar até a tela sem ninguém redigitar a forma dos dados: quando a coluna muda, o que quebra é a compilação, e não a página em produção.

A primeira versão usava WebGL com shaders para um campo de partículas. Ficava bonito, custava trezentos kilobytes de biblioteca e não dizia nada: partícula solta é o fundo padrão de todo portfólio de desenvolvedor desde 2019. A versão atual desenha em canvas 2D puro, que já vem no navegador, e o fundo passou a significar alguma coisa. Menos dependência, menos bateria no telefone, e a decisão foi tomada pelo que o fundo precisava comunicar, não pelo que era mais impressionante de implementar.