O WebAssembly é viável fora do navegador?
Resumindo, sim.
O WebAssembly (Wasm) surgiu como uma tecnologia dominante que revolucionou o desenvolvimento web. Desde as primeiras demonstrações técnicas, como o popular jogo Doom, executado completamente no navegador , até grandes aplicativos legados como o Photoshop, que oferecem uma experiência completa semelhante à de um desktop em uma página da web comum, o WebAssembly oferece experiências completamente novas em um programa familiar já instalado em todos os computadores pessoais do mundo.
O Wasm foi projetado para permitir que quase qualquer linguagem de programação o suporte, independentemente do tipo de processador do computador do usuário, e possui várias propriedades de segurança favoráveis que o navegador usa para impedir acesso não autorizado aos dados ou recursos do sistema de um usuário. Acontece que essas propriedades são incrivelmente úteis fora do navegador, principalmente quando se deseja executar código de forma isolada ou ultraportátil.
A história do POSIX no Unix
O WebAssembly, por padrão, não tem acesso a nenhum recurso do sistema em que está sendo executado. É tudo pura manipulação de zeros e uns, e é por isso que vimos o Wasm sendo usado principalmente para tarefas computacionais pesadas, como decodificação de vídeo ou manipulação de imagens, em vez de desenvolvimento de aplicativos em grande escala. É relativamente fácil dar ao seu sandbox do WebAssembly acesso a funcionalidades externas, como informações sobre a hora atual ou dados armazenados em um arquivo, mas exatamente quais APIs são usadas tende a variar de aplicativo para aplicativo.
Os sistemas Unix experimentaram algo semelhante ao que está acontecendo com o WebAssembly fora do navegador. Muitos aplicativos queriam acesso a recursos comuns do sistema, como redes e sistemas de arquivos, mas cada sistema operacional tinha uma maneira ligeiramente diferente de fazer isso. Por esse motivo, o POSIX estreou como uma interface padrão de sistema operacional portátil — todos os sistemas do tipo Unix podiam adotar essa interface para padronizar como os programas se comunicavam com o sistema operacional. Isso também fez com que programas projetados para funcionar em um sistema do tipo Unix pudessem ser facilmente portados para funcionar em outro.
Entre com WASI, a Interface do Sistema WebAssembly
Para fornecer uma maneira padrão para os programas WebAssembly se comunicarem com um sistema operacional, nasceu o WASI, WebAssembly System Interface. O WASI foi amplamente inspirado por um projeto chamado CloudABI, que por sua vez foi inspirado pelo POSIX. Isso abriu um mundo de oportunidades para o WebAssembly brilhar fora do navegador — os usuários agora tinham todas as propriedades de segurança e sandbox do WebAssembly combinadas com APIs conscientes para acessar recursos comuns do sistema sem perder completamente o sandbox. Naturalmente, uma tecnologia semelhante vem à mente: contêineres. Nenhuma discussão sobre este tópico é considerada completa sem uma referência a uma das postagens mais profundas e compartilhadas sobre WASI pelo cofundador do Docker, Solomon Hykes:
Essa é uma afirmação e tanto. O WebAssembly fornece uma maneira portátil de empacotar código que pode ser executado com segurança em qualquer plataforma em velocidades quase nativas, com o benefício adicional sobre contêineres de que nenhum sistema operacional precisa estar presente. A maioria dos contêineres produzidos pelos desenvolvedores tem algum tipo de sistema operacional Linux no qual os programas são executados, gerando tamanhos de contêineres de muitas vezes centenas de megabytes ou vários gigabytes. Os binários do WebAssembly são código puro, com tamanhos geralmente em kilobytes ou megabytes de um dígito. Parece loucura imaginar um mundo onde, em vez de implantar contêineres em todos os lugares, os desenvolvedores implantam o WebAssembly, mas essa realidade já está se concretizando, com vários projetos sendo desenvolvidos ativamente para executar o Wasm no Kubernetes.
WebAssembly do lado do servidor em produção
Várias empresas já estão se beneficiando do Wasm do lado do servidor em produção. Tanto a Cloudflare quanto a Fastly têm enormes redes de computação de ponta que permitem aos clientes implantar códigos em todo o mundo, o mais próximo possível dos usuários. Ambos escolheram estrategicamente o WebAssembly para ter binários pequenos e ultraportáteis com tempos de inicialização rápidos e multilocação sólida. Uma empresa iniciante, a Cosmonic, usa redes inteligentes para permitir que os componentes do WebAssembly se comuniquem perfeitamente entre si, não importa onde estejam sendo executados, seja um pequeno dispositivo na palma da sua mão ou uma máquina em execução do outro lado do mundo. Outra novata, a Fermyon, usa o WebAssembly para aumentar significativamente a densidade da carga de trabalho do servidor. O resultado é uma redução drástica nos custos do servidor e uma computação mais ecológica para o planeta.
Crescimento fora do navegador
Para resumir, o WebAssembly, embora inicialmente desenvolvido para computação no navegador, continua mostrando alta viabilidade fora do navegador. Seu design, com suporte a diversas linguagens de programação e ênfase na segurança, o torna uma excelente escolha para executar código de forma isolada e obter portabilidade. A introdução do WASI permitiu que o WebAssembly do lado do servidor prosperasse, permitindo que as organizações aproveitassem o Wasm e fornecessem produtos melhores, ao mesmo tempo em que eram substancialmente mais econômicos. O potencial do WebAssembly fora do navegador não é apenas uma ideia, mas uma realidade crescente para a indústria.
Para saber mais, veja nossa postagem anterior no blog, “ Por que você deve se importar com o WebAssembly ”.
Assista ou ouça também nosso podcast “WebAssembly Unleashed” .