A criança nunca sabe o que é um martelo, até confundir o dedo com um prego.
Stephen King
Ah, aplicações web: se você está começando a programar agora é grande a probabilidade de até este momento só ter desenvolvido aplicações web, certo? Talvez ela tenha um front-end feito com algum framework de mercado (Vue? Angular? React?), talvez seja apenas um conjunto de endpoints (aka “API” (alguém ainda usa SOAP?)). No entanto, já se questionou quais seriam os limites da web?
Como deveria ser a interação com uma aplicação web?
Do ponto de vista de interação com usuários (sejam estes humanos ou não) em teoria deveríamos ter todas as interações baseadas no princípio de requisições ao servidor que nos retornem rapidamente um resultado ou que, pelo menos, não nos bloqueiem após termos realizado a requisição ao servidor.
Mesmo que a aplicação web não tenha um servidor e seja executada inteiramente no browser, o ideal é que seja responsiva. Aliás, não é por acaso que ainda hoje o JavaScript adota um modelo não bloqueante de desenvolvimento quando o assunto é I/O, né?
E é aqui que aparece problema.
O problema está em achar que programar se limita a escrever aplicações web
Não me entenda mal: gosto de escrever aplicações web e a maior parte do que faço são sistemas que usam a web como meio. Mas mais do que programar, a maior parte do meu trabalho é evoluir sistemas que não foram projetados ou programados por mim (link), e na minha experiência o que observo como um dos principais problemas arquiteturais é justamente o que chamo de “web em excesso”.
Explico: chamo de “web em excesso” quando todo processamento no sistema é inteiramente executado em requisições web. Com certeza você que programa já topou com situações assim: aquela requisição que realiza longos cálculos que demoooooram a fornecer uma resposta ao usuário final, aquela importação de dados a partir de um endpoint que recebe milhares de registros a serem processados que poderia ser feita de forma assíncrona ou mesmo aquelas tarefas agendadas que são executadas no seu monolito, lembra delas? Resumindo: requisições que duram demais.
E é muito fácil cometer este erro: estamos tão habituados em escrever aplicações web (e apenas aplicações web…) que fica difícil muitas vezes (especialmente em dias apertados) projetar um processamento que não seja iniciado, desenvolvido e finalizado em uma única requisição. E quando usamos frameworks full stack como Rails ou Grails, devido à própria facilidade no desenvolvimento, mesmo que estejamos incluindo toda a lógica de negócio em serviços acabamos por esquecer algo importante: requisições web devem ter vida curta.
Repare: não estou dizendo que os processamentos devam ser rápidos, mas que as requisições que os iniciam tenham vida curta. Resolver este problema no desenvolvimento de aplicações é relativamente simples e possui longa bibliografia: você pode começar a pensar e programar assincronamente, mover o esforço pesado para processos externos, modularizar melhor sua aplicação, enfim: há diversas soluções pra isto. A questão da requisição longa é apenas um sintoma de um problema maior.
(arquiteturalmente falando o ideal é que a web seja um componente do seu sistema, e não TODO o sistema se for uma aplicação grande)
Quando a web te limita profissionalmente
Estou nesta vida desde 1996: dado que hoje estou com 43 anos, mais da metade do meu tempo na Terra foi desenvolvendo software. Comecei quando o desenvolvimento era centrado no desktop e vivi o trauma da transição para a web: foi horrível e muitos colegas da época não conseguiram fazer a transição que, no meu caso, se consolidou MESMO só lá pros idos de 2004, 2005.
E neste tempo todo passei por vários ambientes de desenvolvimento e, graças à itexto, por uma gama de mercados que pouquíssimas pessoas tiveram o privilégio de conhecer, o que me permitiu escrever, projetar ou participar direta e indiretamente de softwares de uma infinidade de tipos: integrações, aplicações desktop, linha de comando, ferramentas de baixo nível, sistemas comerciais, corporativos, segurança, protocolos de comunicação, drivers, sistemas de arquivo, plataformas de e-commerce, jogos, sistemas operacionais (indiretamente), comunicações, embarcados, gráficos (tipo CAD), automação industrial, aplicações científicas, engenharia, matemáticas, financeiros, linguagens de programação (desculpe!), inteligência artificial, áudio, aeroespacial (!)…
Após ter passado por tanta coisa sabe o que me choca? Gente jovem que pensa em desenvolvimento de software estritamente como… desenvolvimento web “apenas”. Nada de errado em ser excelente em desenvolvimento web, mas a pergunta que me faço é: será que estas pessoas não poderiam ser ainda melhores se explorassem também outras áreas do desenvolvimento? E os sistemas que projetam, não poderiam ser ainda mais fantásticos?
Tenho visto muitas discussões sobre a dificuldade de pessoas iniciantes em entrarem no mercado. É realmente muito difícil, mas será que não fica ainda mais difícil por se focar o aprendizado de desenvolvimento e engenharia de software apenas no mundo web quando a esmagadora maioria das pessoas olha apenas para este mercado?
E todos estes outros nichos que não aparecem tanto na “mídia especializada” (que convenhamos, hoje é dominada por um monte de “influencers” que ao menos pra mim parecem todos iguais), será que não mereciam um pouco mais de atenção nas publicações/vídeos/podcasts/lives? Pouco tempo atrás o Adriano me mostrou uma realidade que não acreditei num prieiro momento: uma IMENSA quantidade de vagas para desenvolvedores… C++! Realmente: o mercado de engenharia precisa deste pessoal, mas pouco se fala a respeito.
(aliás, já notou como a mídia escrita para desenvolvimento praticamente morreu? (algo a se pensar))
Meses atrás implementei uma automação industrial de baixo nível com equipamentos usando Rust e comunicação por sockets apenas. Poderia ter sido feito em Java/C#/C++/VB/JavaScript ou qualquer outra linguagem que permita comunicação neste formato. E sabe que me chamou a atenção? Um iniciante poderia facilmente aprender o suficiente para se tornar produtivo em pouco tempo. Você não seria um expert, claro, mas conseguiria se virar sozinho. (e há menos pra se aprender ALI do que no desenvolvimento web pra ser eficiente, acredita?)
Resumindo: na minha opinião se você quando pensa em um sistema já começa decidindo que este deveria ser web sem sequer vislumbrar outras possibilidades talvez seja o sintoma de uma percepção bem limitada do mercado.
Concluindo
Amo projetar e programar sistemas: talvez este “excesso de web” seja uma percepção equivocada minha, resultado do meio em que vivo, mas talvez haja alguma coisa por trás desta fumaça.
Semanas atrás dei uma relida no Kant que levanta a possibilidade do nosso conhecimento ser muito limitado pelo modo como percebemos o mundo (e a estrutura interna da nossa mente). Talvez este excesso de web quando programamos nos cegue para todo um Universo que pudéssemos explorar por aí.
Quem sabe? Bom: anos atrás escrevi algumas coisas sobre “determinismo linguístico”, que você pode conferir nestes links. Faz muitos anos que escrevi isto, mas minha opinião não mudou muito. Você encontra estes textos neste link do “Essencial de /dev/Kico”.
Depois de muitos anos batendo cabeça aprendi que um erro que cometemos é buscar conhecimento “no mercado”: pra ser dar bem no mercado você tem que saber isso, fazer aquilo, etc.
Depois que fui para o ambiente acadêmico a visão se ampliou; é *lá* que o conhecimento é gerado, então é lá que podemos procurar. Não digo necessariamente “fazer faculdade” (mas é bom!) e sim tomar contato com a produção científica da área. O mercado deveria ser onde aplicamos nosso conhecimento, onde vamos buscar vagas e trabalhar, mas pouca gente ali é referência do que aprender. Ele carrega um viés que não é errado, faz parte da sua natureza, e que cabe a nós sermos críticos. O mercado passa a demandar “web” e os espertos de plantão já saem papagaiando que essa é a tendência, agora é assim e nós, mais interessados em uma colocação do que em aprender, vamos na onda.
Resumiu muito bem a coisa!