Patch: -frontend, -backend, -full stack +aplicativo, +script, +daemon
Existe um vocabulário velho ruim para descrever software. “Frontend”, “backend”, “full stack”. Falam da posição de uma peça no diagrama, mas se quiser pensar em software de forma um pouco mais séria vale trocar a pergunta. Como esse programa existe no computador? Na CPU, na memória, nos barramentos.
O aplicativo
O aplicativo é o software que espera um operador. Ele roda em loop reagindo à interação com alguém. tradicionalmente um humano. cada vez mais a máquina agindo como um. Clicando, digitando, escolhendo, navegando, confirmando, hesitando. O aplicativo pressupõe interface do usuário.
Pode ser textual como nos velhos programas de terminal. Pode ser cliente nativo de sistema operacional. Pode ser uma aplicação web. Pode ser uma aberração empacotada para parecer nativa em qualquer dispositivo. Pode ser (cada vez mais) uma interface conversacional. Não imporatan, no aplicativo, UX é rei. Tudo gira em torno de fluxo, percepção e conforto cognitivo. Um aplicativo ruim quase nunca é ruim porque falha tecnicamente. é o que obriga o usuário a pensar como a máquina.
O script
O script já conhece seus insumos antes de começar. Recebe parâmetros, uma lista de coisas a fazer. E vai correr quase lienar de ponta à ponta. e só voltar com os resultados. Nasce para resolver uma utilidade específica com o mínimo de atrito possível. uma combinação bizarra de awk e sed mantidas por um mago de 63 anos que sustenta o deploy da operação inteira. A forma muda. A essência não.
No script o que reina é flexibilidade e velocidade de iteração. É por isso que script é tão poderoso: É a utilidade antes de qualquer outra coisa. Metade da infraestrutura do mundo começou como “só um scriptzinho”. Claro e por isso o script carrega seu lado trágico. Nada envelhece tão mal quanto uma solução temporária que funcionava bem demais.
O daemon
O daemon também roda em loop, mas de um jeito totalmente diferente do aplicativo. Ele não espera um operador. Ele reage ao mundo. Uma mensagem. Um sinal. Um pacote. Um evento. Um horário. Idealmente fica vivo por todo o tempo em que o sistema permanecer de pé. O daemon não interage com o usuário, mas com o mundo.
Por isso, aqui, o rei é outro: tratamento de erro. Não apenas “dar catch na exceção”, mas saber cair sem colapsar, reiniciar sem corromper, registrar o que aconteceu, degradar com dignidade e se recuperar. O daemon vive tempo suficiente para conhecer a maldade do mundo. Ele não pode se dar ao luxo do otimismo juvenil.
Tudo junto
Três categorias distintas de programas.
- O aplicativo precisa ser agradável.
- O script precisa ser rápido de fazer.
- O daemon precisa ficar de pé.
O ponto mais importante, porém é que essas categorias raramente existem sozinhas. Quase todo sistema real é uma composição das três.
O usuário interage com um aplicativo. Esse aplicativo dispara scripts. Scripts e aplicativos dependem de daemons. E, de repente, aquilo que parecia um “produto de software” começa a se revelar pelo que realmente é. Um ecossistema de programas com naturezas diferentes. E isso importa muito para projetar bem. Porque um aplicativo tratado como daemon tende a virar uma experiência hostil e daemon tratado como script vai morrer no primeiro soco na cara que levar.
Engenharia de software no fim começa aí: em perceber que não existe “software” no singular. Existem organismos distintos, com necessidades distintas, critérios de qualidade distintos e formas distintas de envelhecer. Anatomia básica. E aprender a combiná-las bem é mais importante do que se dividir em rótulos herdados de uma arquitetura de quinze anos atrás. Menos frontend versus backend. Mais programa que interage, programa que executa, programa que oferece.