Forrester no WebAssembly para desenvolvedores: front-end para back-end

Há muitas coisas para amar no WebAssembly – mas como os desenvolvedores decidem quando usá-lo? Faz diferença em qual idioma você escreve no WebAssembly? E quanto à segurança? Para saber mais sobre o que os desenvolvedores front-end precisam saber, conversei com Andrew Cornwall, analista sênior da Forrester especializado na área de desenvolvimento de aplicativos.

A boa notícia é que a funcionalidade não muda dependendo da linguagem de codificação em que você escreve. Escreva em C++, AssemblyScript, Rust – a escolha é do desenvolvedor, disse Cornwall. Normalmente, é mais fácil compilar linguagens que não possuem coletores de lixo, portanto, linguagens como Java, Python e linguagens interpretadas tendem a ser mais difíceis de executar no WebAssembly do que linguagens como C ou Rust . Mas o resultado final será o WebAssembly, que ele observou ser mais bem pensado como um processador do que como uma linguagem.

“Algo como JavaScript, Java ou Python, onde existe todo um ecossistema que precisa estar instalado antes de poder ser executado”, disse Cornwall.

Normalmente, os desenvolvedores pegam a implementação C do Python e a compilam usando um compilador que gera WebAssembly, disse ele. Agora eles têm um interpretador Python escrito em WebAssembly, que pode alimentar com código Python normal.

“Isso é mais fácil de fazer do que converter Python para WebAssembly”, acrescentou ele.”Uma vez que está no WebAssembly, não importa.” Ele simplesmente roda – é essencialmente muito semelhante ao código de máquina.”

Para outras linguagens suportadas, em vez de compilar para x86 ou Arm em um compilador, os desenvolvedores optam pelo WebAssembly ao compilar, explicou ele. O compilador gera o código de bytes que será executado – WebAssembly, ou Wasm, é um código de bytes de baixo nível que pode ser traduzido em assembly. Um bytecode é um código-objeto de computador que um intérprete converte em código de máquina binário para que possa ser lido pelo processador de hardware de um computador. Essencialmente, o WebAssembly converte código para este formato de código binário portátil. Como tal, tem mais em comum com a linguagem de máquina do que qualquer outra coisa e é por isso que é tão rápido.

Casos de uso do Wasm para o front-end

Quando o WebAssembly foi lançado, ele era visto principalmente como uma solução para necessidades de front-end, disse Cornwall. Os casos de uso típicos para o front-end incluem operações com muita matemática matricial e vídeo. Se você precisa que algo comece a ser executado imediatamente e não tem tempo para esperar o download e análise do JavaScript no navegador, o WebAssembly é uma ótima solução, disse ele. Por exemplo, a BBC criou um reprodutor de vídeo para seu site em Wasm e o Figma é escrito em C++ e compilado para WebAssembly, onde reduz em três vezes o tempo de carregamento.

“O WebAssembly pode ser transmitido para que você possa baixá-lo e começar a executá-lo imediatamente”, disse Cornwall. “Fora isso, o outro caso de uso interessante do WebAssembly em front-ends da web não será tanto para desenvolvedores de JavaScript, mas para desenvolvedores de outras coisas.”

Isso ocorre em parte porque o JavaScript executado no compilador just-in-time (JIT) é na verdade muito rápido, disse ele, acrescentando que os desenvolvedores podem chegar à metade da velocidade nativa com o JavaScript “se você deixá-lo rodar por tempo suficiente”. Para outros desenvolvedores, Wasm significa que eles podem escrever em seu código favorito e compatível e depois compilar no Wasm para o frontend.

“As partes interessantes em que o WebAssembly é usado são essencialmente coisas em que você passaria para o código de máquina se estivesse escrevendo um programa em outra linguagem”, disse ele. “Se há algo que precisa ser realmente rápido imediatamente, e você não pode se dar ao luxo de esperar que o JIT o acelere otimizando-o, ou se há algo que você precisa que seja iniciado imediatamente e você não “Não quero esperar o tempo para que o JavaScript seja analisado, por exemplo, para que você o tenha no WebAssembly.”

Wasm para o back-end

Então, uma coisa engraçada aconteceu no caminho para a montagem (ahem): Wasm começou a se tornar menos uma coisa de front-end e mais uma coisa de back-end à medida que começou a ser aproveitado para computação sem servidor, disse ele.

“As VMs (máquinas virtuais) WebAssembly iniciam muito rápido em comparação com VMs ou contêineres JavaScript”, disse ele. “Uma VM JavaScript inicia em milissegundos, ou seja, 50, 100 milissegundos; As VMs WebAssembly podem iniciar em microssegundos. … Se você estiver executando funções sem servidor, isso é ótimo porque você liga para o servidor e diz: me dê o resultado. Ele pode então inicializar e fornecer os resultados muito rapidamente, enquanto outras coisas como Javascript VM, Java VMs e contêineres têm esse tempo de inicialização como o custo necessário para começarem a funcionar antes de poderem fazer algo com os valores. que você está passando por eles e lhe dá o resultado.’

Isso inclui contêineres Kubernetes, acrescentou. E há lugares – funções sem servidor ou onde o navegador deseja fazer uma solicitação de uma função de pesquisa – onde os desenvolvedores gostariam de usar VMs WebAssembly em vez de um contêiner Kubernetes, acrescentou.

“Se você enviar essa solicitação de pesquisa, estará esperando até que o contêiner apareça, execute o código, o próprio código de pesquisa e, em seguida, envie o resultado de volta. Freqüentemente, os contêineres permitem múltiplas conexões porque é caro trazê-los até lá”, disse ele. “Então, Kubernetes, tem um custo para trazer o contêiner para cima. Com o WebAssembly você não tem tanto custo. São microssegundos em vez de milissegundos; ou mesmo se for um contêiner, pode levar centenas de milissegundos ou chegar perto de meio segundo.”

Multiplique isso por 1000 e esses milissegundos começarão a somar.

Como Wasm melhora a segurança

Também existe um risco de segurança nos contêineres porque as pessoas tendem a reutilizá-los em vez de desligá-los e recomeçar. Isso não é um problema com Wasm.

“Então você precisa se preocupar em como o que alguém que veio antes de mim afetou o que a pessoa atual está solicitando ou o que a solicitação atual está acontecendo?” Cornualha disse. “Com o WebAssembly é tão barato que você simplesmente joga fora. Você pode simplesmente escrever uma função sem servidor, iniciar a VM, executar a função sem servidor e, em seguida, lançá-la até o fim e aguardar a próxima solicitação.”

Não que o Wasm substitua os contêineres o tempo todo, alertou ele. Os contêineres ainda são necessários e fazem sentido ao executar grandes consultas em grandes bancos de dados, onde adicionar mais 300 milissegundos à consulta realmente não faz muita diferença.

“Coisas como essa provavelmente permanecerão em contêineres porque é um pouco mais fácil gerenciar um contêiner, pelo menos agora, do que gerenciar funções sem servidor do WebAssembly que simplesmente flutuam no espaço”, disse ele. “O WebAssembly será uma adição quando você precisar fazer chamadas rápidas para funções sem servidor, em vez de assumir o controle de todos os contêineres.”

Outra maneira pela qual o Wasm é mais seguro do que outras opções é que ele só será executado dentro de sua sandbox – nada sai dela. É por isso que até agora a maior ameaça à segurança vista com o WebAssembly veio de sites onde os mineradores de bitcoin estavam escondidos no Web Assembly, fazendo com que o usuário do site emprestasse involuntariamente CPUs para mineração de bitcoin. Não é possível que o código compilado no Wasm alcance e envie senhas, por exemplo, porque o código permanece dentro da sandbox do Wasm, explicou Cornwall.

A postagem Forrester no WebAssembly para desenvolvedores: Frontend para Backend apareceu pela primeira vez em The New Stack.