Antigamente, as empresas podiam contar com o uso de proxies estrategicamente implantados para melhorar o desempenho dos aplicativos. Isso ocorre porque os aplicativos tradicionais — monólitos e arquiteturas de três camadas — geralmente empregam um único caminho de dados entre o cliente e o servidor.
Em termos simples, havia apenas uma rota tomada para todo o conteúdo — fosse estático ou dinâmico, baseado em texto ou imagens. Isso significava que um controlador de entrega de aplicativos (proxy) poderia ficar entre eles e, com o correto, otimizar o desempenho. Isso era — e ainda é, aliás — frequentemente obtido por meio do ajuste de vários botões e controles de IP, TCP e até HTTP. Podemos ver o uso desses tipos de técnicas por meio da implantação de serviços de aplicativos, como cache, compactação e técnicas de aceleração específicas de conteúdo.
Mas os aplicativos modernos não são mais autossuficientes. Eles são agora, de acordo com a Sonatype , compostos principalmente (80-90%) por componentes de terceiros (e cada vez mais de código aberto). Você vê isso no número de scripts e outros códigos injetáveis encontrados em aplicativos da web. Às vezes, esse script é executado remotamente e retorna uma imagem, um anúncio ou outro conteúdo, como fontes da web e sprites. Outras vezes, o próprio script é carregado em tempo de execução e executado dentro dos limites do navegador, como o jQuery.
Isso é o que conhecemos como componentização - ou atomização, se preferir. É a divisão de aplicativos em muitas partes menores. Nós os chamamos de componentes no lado do cliente, porque eles geralmente são executados no mesmo espaço. No lado do servidor, cada vez mais os chamamos de microsserviços e os implantamos em contêineres. Em ambos os casos, o impacto é semelhante: acabamos com um número imprevisível de caminhos de dados que afetam diretamente o desempenho.
Basicamente, você tem controle sobre um caminho de dados, que compreende talvez 20% do seu aplicativo. Isso significa que você tem muito pouco controle sobre a experiência do usuário porque tem muito pouco controle sobre o desempenho.
Isso também é verdade para a segurança. Obrigado por notar. O problema é que estamos aprendendo rapidamente a aproveitar as técnicas de código do lado do cliente para melhorar a segurança. Isso não funciona tão bem com desempenho porque a maioria dos aplicativos são móveis ou web, e nenhum deles oferece a oportunidade ou a capacidade de mexer na pilha de rede.
Uma das maneiras de combater esse problema é retomar o controle. O legal de retomar o controle é que você também pode se beneficiar dos efeitos colaterais da segurança.
Se seus aplicativos têm o hábito de carregar dinamicamente componentes de sites externos, pare com isso. Pare com isso agora. Isso é tanto uma questão de segurança quanto de desempenho. Você está implicitamente dando carta branca para um script de origem externa ser executado dentro do contexto do seu aplicativo. Acredite em mim, um usuário não conseguirá distinguir entre seus componentes e aqueles carregados externamente no caso de uma violação de segurança. Como aprendemos com o recente colapso sobre a vulnerabilidade do contêiner runc , a injeção de código malicioso em recursos carregados de registros ou sites de terceiros traz consigo um risco de segurança.
Se for um script, é melhor cloná-lo e servi-lo a partir da sua própria infraestrutura. Você se beneficiará da redução de riscos ao manter o controle e poder ajustar botões e controles que melhoram o desempenho para seus usuários. Isso inclui o DNS, que tem consistentemente demonstrado ter o maior impacto (geralmente negativo) no desempenho do aplicativo. Ao extrair componentes de sites externos, você está confiando que a infraestrutura de DNS deles terá o desempenho esperado. Extrair componentes dos seus próprios sites pode reduzir drasticamente o impacto, simplesmente porque o cache DNS local do usuário funciona para você.
Hospedar scripts do seu próprio site também permite que você empregue otimizações de TCP ou técnicas gerais de aceleração de aplicativos ou descarregamento de SSL/TLS para melhorar o desempenho geral. Ele também oferece a oportunidade de executar verificações de segurança nesses scripts para garantir que não haja surpresas escondidas.
A componentização é ótima para o desenvolvimento e certamente ajuda a acelerar o tempo de valorização. Mas isso pode ter um impacto negativo no desempenho e na segurança. Esteja ciente dos riscos de segurança e satisfação do usuário e o que você pode fazer para combatê-los.