Confira !!
Se você ainda não ouviu falar do WebAssembly , em breve. É um dos segredos mais bem guardados da indústria, mas está em toda parte. É suportado por todos os principais navegadores e também está chegando ao lado do servidor. É rápido. Está sendo usado para jogos. É um padrão aberto do World Wide Web Consortium (W3C), a principal organização internacional de padrões para a web.
"Uau", você pode estar dizendo, "isso parece algo que eu deveria aprender a codificar!" Você estaria certo, mas também estaria errado; você não codifica no WebAssembly. Vamos reservar um tempo para aprender sobre a tecnologia que é frequentemente abreviada com o nome "Wasm".
De onde veio?
Retrocedendo cerca de dez anos, havia um reconhecimento crescente de que o JavaScript amplamente usado não era rápido o suficiente para muitos propósitos. Sem dúvida, o JavaScript foi bem-sucedido e conveniente. Ele rodava em qualquer navegador e habilitava o tipo de páginas dinâmicas da web que hoje é um dado adquirido. Mas era uma linguagem de alto nível e não foi projetada com cargas de trabalho intensivas em computação.
No entanto, embora os engenheiros responsáveis pelos principais navegadores da web geralmente concordassem com o problema de desempenho, eles não estavam alinhados com o que fazer. Dois campos emergiram. O Google iniciou seu projeto Native Client e, posteriormente, sua variação Portable Native Client, para permitir que jogos e outros softwares escritos em C / C ++ fossem executados em um compartimento seguro no Chrome. Enquanto isso, a Mozilla ganhou o apoio da Microsoft para o asm.js., uma abordagem que atualizou o navegador para executar rapidamente um subconjunto de instruções JavaScript de baixo nível (outro projeto permitiu a conversão do código C / C ++ nessas instruções).
Com nenhum dos campos conquistando ampla adoção, as várias partes concordaram em unir forças em 2015 em torno de um novo padrão chamado WebAssembly, baseado na abordagem básica adotada pelo asm.js. Como Stephen Shankland, da CNET, escreveu na época : "Na Web de hoje, o JavaScript do navegador traduz essas instruções em código de máquina. Mas, com o WebAssembly, o programador faz grande parte do trabalho no início do processo, produzindo um programa entre os dois estados. Isso libera o navegador de grande parte do trabalho árduo de criar o código da máquina, mas também cumpre a promessa da Web - que o software será executado em qualquer dispositivo com um navegador, independentemente dos detalhes subjacentes do hardware ".
Em 2017, a Mozilla declarou que era um produto mínimo viável e o retirou da visualização. Todos os principais navegadores o adotaram até o final daquele ano. Em dezembro de 2019 , o Grupo de Trabalho do WebAssembly publicou as três especificações do WebAssembly como recomendações do W3C.
O WebAssembly define um formato de código binário portátil para programas executáveis, uma linguagem de montagem textual correspondente e interfaces para facilitar as interações entre esses programas e seu ambiente host. O código do WebAssembly é executado em uma máquina virtual de baixo nível que imita a funcionalidade de muitos microprocessadores nos quais ele pode ser executado. Através da compilação ou interpretação Just-In-Time (JIT), o mecanismo WebAssembly pode executar quase a velocidade do código compilado para uma plataforma nativa.
Por que o interesse agora?
Certamente, parte do interesse recente no WebAssembly decorre desse desejo inicial de executar códigos com mais uso intensivo de computação nos navegadores. Os usuários de laptops, em particular, estão gastando cada vez mais tempo em um navegador (ou, no caso dos Chromebooks, praticamente todo o tempo). Essa tendência criou uma urgência em remover barreiras à execução de uma ampla gama de aplicativos em um navegador. E uma dessas barreiras costuma ser algum aspecto do desempenho, que é o que o WebAssembly e seus antecessores foram originalmente concebidos para resolver.
No entanto, o WebAssembly não é apenas para navegadores. Em 2019, a Mozilla anunciou um projeto chamado WASI (WebAssembly System Interface) para padronizar como o código do WebAssembly interage com os sistemas operacionais fora do contexto do navegador. Com a combinação do suporte ao navegador para WebAssembly e WASI, os binários compilados poderão executar dentro e sem navegadores, em diferentes dispositivos e sistemas operacionais, em velocidades quase nativas.
A baixa sobrecarga do WebAssembly imediatamente o torna prático para uso além dos navegadores, mas é indiscutivelmente o que está em jogo; obviamente existem outras maneiras de executar aplicativos que não apresentam gargalos de desempenho. Por que usar o WebAssembly, especificamente?
Uma razão importante é a sua portabilidade. Linguagens compiladas amplamente usadas como C ++ e Rust são provavelmente as mais associadas ao WebAssembly atualmente. No entanto, uma grande variedade de outros idiomas é compilada ou possui suas máquinas virtuais no WebAssembly. Além disso, embora o WebAssembly assuma certos pré-requisitos para seus ambientes de execução, ele foi projetado para ser executado com eficiência em uma variedade de sistemas operacionais e arquiteturas de conjunto de instruções. O código do WebAssembly pode, portanto, ser escrito usando uma ampla variedade de idiomas e executado em uma ampla variedade de sistemas operacionais e tipos de processadores.
Outra vantagem do WebAssembly decorre do fato de o código ser executado em uma máquina virtual. Como resultado, cada módulo WebAssembly é executado em um ambiente em área restrita, separado do tempo de execução do host usando técnicas de isolamento de falhas. Isso implica, entre outras coisas, que os aplicativos sejam executados isoladamente do restante do ambiente host e não possam escapar da área restrita sem passar pelas APIs apropriadas.
WebAssembly em ação
O que tudo isso significa na prática?
Um exemplo de WebAssembly em ação é o Enarx .
O Enarx é um projeto que fornece independência de hardware para proteger aplicativos usando o Trusted Execution Environments (TEE). A Enarx permite entregar com segurança um aplicativo compilado no WebAssembly em um provedor de nuvem e executá-lo remotamente. Como coloca o engenheiro de segurança da Red Hat Nathaniel McCallum, "Da maneira que fazemos isso, tomamos seu aplicativo como entradas e executamos um processo de atestado com o hardware remoto. Validamos que o hardware remoto é, de fato, o hardware que ele afirma ser, usando técnicas criptográficas O resultado final não é apenas um aumento do nível de confiança no hardware com o qual estamos falando, é também uma chave de sessão, que podemos usar para fornecer código e dados criptografados nesse ambiente que acabamos de solicitar. atestado criptográfico ativado ".
Outro exemplo é o OPA, o Open Policy Agent, que anunciou em novembro de 2019 que você poderia compilar a sua linguagem de definição de política, Rego, no WebAssembly. O Rego permite escrever lógica para pesquisar e combinar dados JSON / YAML de diferentes fontes para fazer perguntas como "Esta API é permitida?"
O OPA tem sido usado para habilitar políticas de software, incluindo, entre outros, o Kubernetes. A simplificação de políticas usando ferramentas como OPA é considerada uma etapa importante para proteger adequadamente as implantações do Kubernetes em uma variedade de ambientes diferentes. A portabilidade do WebAssembly e os recursos de segurança integrados são uma boa combinação para essas ferramentas.
Nosso último exemplo é a unidade . Lembre-se, mencionamos no início do artigo que o WebAssembly é usado para jogos? Bem, o Unity, o mecanismo de jogos de plataforma cruzada, foi um dos primeiros a adotar o WebAssembly, fornecendo a primeira demonstração do Wasm em execução nos navegadores e, desde agosto de 2018, usa o WebAssembly como o destino de saída para o destino de construção do Unity WebGL.
Essas são apenas algumas das maneiras pelas quais o WebAssembly já começou a causar impacto. Saiba mais e mantenha-se atualizado sobre tudo o que o Wasm está em https://webassembly.org/
Fonte
Até a próxima !
Nenhum comentário:
Postar um comentário