Quando se fala em WebAssembly no universo .NET, é comum pensar imediatamente no Blazor, não é mesmo?
No entanto, para mim, a imagem que surge é a revolução que o WebAssembly no backend pode desencadear. Imagina mudar completamente a maneira como construímos, encapsulamos, hospedamos e gerenciamos sistemas, criando uma interoperabilidade inédita.
Não me refiro ao WebAssembly em navegadores. Estou falando sobre o WebAssembly no SERVIDOR, muito além dos limites dos browsers!
E o que estou prestes a revelar não tem qualquer relação com o Blazor!
Estamos falando de algo tão surpreendente quanto poderoso!
Sei que muitos ainda estão fascinados com o Blazor e com o WebAssembly no browser.
Introdução
E se eu dissesse que você poderia integrar classes Java, JS/Node, Python diretamente no seu projeto .NET?
E se você tivesse a possibilidade de inserir código .NET em projetos Java, Node, Python, isso te animaria?
Agora, imagine que independente da linguagem ou do runtime, você pudesse construir extensões para ela, na sua linguagem predileta!
Parece interessante?
Visualize que, para implementar um plugin no seu ERP, você precisa da interface X, com os dados de entrada Xi e os de saída Xo.
Pronto, não importa a linguagem na qual o desenvolvedor irá programar, ele poderá implementar essa interface em qualquer linguagem, e sua aplicação conseguirá executar com total segurança, estabelecendo precisamente o que esse plugin pode fazer (acesso a disco, rede, etc).
Sem a necessidade de mecanismos complexos de interoperabilidade e sem a exigência de runtimes diferentes.
Já pensou no poder disso?
Talvez você já tenha encontrado algo similar na plataforma .NET. Libraries podem implementar interfaces concebidas em C# a partir de qualquer linguagem que produza MSIL. Então você pode usar VB para implementar uma interface C# e vice-versa.
Agora imagine esse poder, sem as restrições da MSIL, sem as limitações da Microsoft. Java, Python, Rust, JavaScript, TypeScript, e quem sabe até Go.
Não estou falando apenas de permitir que outros desenvolvam plugins para nossas aplicações. Estou falando da nossa habilidade de desenvolver plugins que podem ser inseridos em qualquer coisa que possamos imaginar.
Pense na possibilidade de criar um plugin personalizado para o Kong, NGINX, CoreDNS, Envoy e várias outras tecnologias e ferramentas que usamos no dia a dia.
Imagine resolver, de forma segura, necessidades de colocar algum tipo de processamento perto de um banco de dados, seja ele relacional ou não. Não que essa seja uma boa ideia.
Mas estou falando de possibilidades. A possibilidade de expandir o Kubernetes, Docker, Docker Desktop, criar plugins para as soluções mais variadas e exóticas.
Pense em poder hospedar esses serviços na ponta, no edge, no Cloudflare, localizado a poucos quilômetros do seu cliente.
E, para além disso, estamos falando de repensar a maneira como embalamos, distribuímos e implementamos nossas aplicações.
Segundo Solomon Hykes fundador da docker:
“Se WASM+WASI existisse em 2008, não precisaríamos criar o Docker.
É assim que é importante.
Webassembly no servidor é o futuro da computação.
Uma interface de sistema padronizada era o elo que faltava.
Esperemos que o WASI esteja à altura da tarefa!“
É disso que estou falando…
Será que nesse futuro distópico usaremos docker ainda?
O que sabemos é que a docker já está correndo atrás docs.docker.com/desktop/wasm/
Contexto
No meio de 2021 eu estava avaliando tendências do nosso mercado, tecnologias relevantes que estivessem fazendo barulho e que pudessem direcionar meus estudos.
Minhas fontes apontavam que WebAssembly estava sendo muito notado e era um assunto bem quente.
Ao olhar no detalhe sobre o que estava sendo dito sobre WASM, eu me deparei com algo diferente: WebAssembly no server. Isso me chamou a atenção, mas eu não dei muita atenção porque imaginei que se tratasse de algo parecido com SSR (server-side-rendering).
Mas o assunto ganhou um espaço na minha cabeça e naturalmente WebAssembly estava deixando de ser ignorado por mim.
Em poucos meses me deparei com projetos usando WebAssembly para um propósito bem diferente do que eu havia entendido.
CloudFlare havia lançado uma série imensa de novos serviços baseados em WASM, enquanto API’s Gateways estavam usando WASM para extensibilidade, permitindo que criássemos plugins em qualquer linguagem.
Foi aí que resolvi dar atenção ao assunto.
Buscando novamente nas fontes, entendi que associado ao WASM estava um novo termo WASI. O tumulto e o frisson não era apenas sobre WASM, era sobre WASM + WASI.
WASI – WebAssembly System Interface
WASI, ou WebAssembly System Interface, é uma interface de sistema projetada como um conjunto compacto e portátil de APIs que permitem a execução segura de programas WebAssembly fora do contexto do navegador. É uma forma de trazer a portabilidade e a segurança do WebAssembly para muitos outros tipos de sistemas e ambientes.
O WASI é um esforço para desenvolver um ambiente de execução padrão que permita aos desenvolvedores de software criar e executar aplicações WebAssembly em uma ampla variedade de sistemas e dispositivos, sem ter que se preocupar com as diferenças específicas do sistema operacional ou do hardware subjacente.
Ele é projetado para ser seguro, e cada operação de sistema é explicitamente concedida pelo ambiente de execução. Isto inclui coisas como acesso ao sistema de arquivos, rede e outros recursos do sistema. Isso permite que os aplicativos WebAssembly sejam executados com segurança, mesmo em ambientes que exigem alta segurança.
WASI é uma parte crucial do futuro do WebAssembly, ao ter o potencial de tornar o WebAssembly uma plataforma de computação universal, não apenas uma tecnologia para a web.
WASI abre um leque de possibilidades para a execução de aplicações WebAssembly em diferentes contextos, não apenas em navegadores da web. Aqui estão alguns exemplos de como o WASI pode ser aplicado:
- Portabilidade de Aplicações: Com WASI, é possível escrever uma aplicação uma vez e rodá-la em qualquer lugar que suporte WASI. Por exemplo, poderia desenvolver um jogo em WebAssembly e rodá-lo tanto no navegador quanto em um dispositivo IoT que suporte WASI.
- Segurança e Isolamento: WASI permite executar código em um ambiente isolado e seguro. Isso pode ser útil em cenários como a execução de scripts enviados por usuários em um servidor, sem risco de comprometer a segurança do sistema.
- Edge Computing: WASI pode permitir a execução de WebAssembly em dispositivos de edge computing. Por exemplo, poderia rodar aplicações WebAssembly em um roteador ou gateway IoT para processar dados localmente.
- Serverless Computing: WASI pode ser usado para executar funções serverless de forma segura e eficiente. Por exemplo, um provedor de cloud poderia usar WASI para isolar funções serverless umas das outras, enquanto ainda permite que elas sejam escritas em uma variedade de linguagens que compilam para WebAssembly.
- Aplicações de Desktop: WASI também poderia ser usado para criar aplicações de desktop seguras e portáveis. As aplicações poderiam ser escritas em qualquer linguagem que compila para WebAssembly e depois executadas em qualquer sistema operacional que suporte WASI.
Imagine a portabilidade que o javascript alcançou (e que o java nunca), ao ponto de rodar em relógios, geladeiras, e qualquer dispositivo. Mas agora com o poder de permitir que seja desenvolvido em qualquer linguagem.
Imagine as possibilidades de termos componentes de baixo nível desenvolvidos com wasm e integráveis, coisas que só eram possíveis de se fazer com linguagem A ou B por causa de uma biblioteca, furam as bolhas das suas próprias plataformas.
Imagine um Redis ou um banco de dados em WASM rodando talvez no seu roteador. Com uma API ao lado, onde você pode usar o celular para enviar chamadas autenticas que notificam presença e só estão disponíveis porque você está na rede.
Não há limites para as possibilidades de interoperabilidade, não há limites para dizer onde esses componentes podem rodar. Talvez, embarcar um código .NET em um mainfraime de um banco, possa ser o início do fim do COBOL.
Talvez possamos mover processamento de imagem e video direto para o navegador do usuário, removendo necessidades de instalações.
Conclusão
O futuro do WebAssembly, na minha opinião, não é o Blazor.
Blazor é apenas o que os devs conseguem enxergar, aquilo que a Microsoft conseguiu ancoragem no desejo pré-existente dos desenvolvedores.
O real potencial para WASM, o que pode de fato revolucionar o mercado, na minha opinião, é o WASM + WASI.
Mas essa é a minha opinião. Comente com a sua!
Continue sua descoberta com outros links úteis
WebAssembly System Interface (WASI)
Unexpectedly Useful: A Real World Use Case For WebAssembly System Interface (WASI)
Solomon Hykes / @[email protected] / If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task!
Exploring .NET WebAssembly with WASI and Wasmtime
Experimental WASI SDK for .NET Core
Future Possibilities for .NET Core and WASI (WebAssembly on the Server)
Using WASM and WASI to run .NET 7 on a Raspberry PI Zero 2 W
isso é legal. voltamos aos applets…
mas, ao que parece, rodar um live ubuntu extension no browser, em todos os browsers, nos liberta do ubuntu meia boca rodando sob wsl que se quer pode instalar um npm o que é possivel via ubuntu live cd ou usb em um momento em que londres, com 42.9 oC derrubou o GCP, e, tristemente, descobrimos que o cloud era na verdade um CPD, da década de 70, quando não havia rede nem redundancia, ja que varios clientes ficaram mais de 24 horas fora do ar na city, a ex capital financeira do planeta.
Então cara, se você acha que o “ubuntu meia boca rodando sob wsl”, tá precisando entender esse rolê melhor. Leia sobre linux server vs Linux desktop.
“que se quer pode instalar um npm” leia sobre WSL1 vs WSL2.
Vale lembrar que WSL é uma ferramenta de desenvolvimento, ponto.
Não é uma ferramenta para rodar um linux em produção.
Outro ponto é que, se tá com dificuldade com NPM no ubuntu, wsl não tem culpa.
Toda reclamação que escutar sobre o WSL, entenda como ignorância, burrice ou preguiça do usuário.
Porque é sobre um descasamento entre expectativa e realidade.
WSL, no que se propõem a fazer e a ser, beira a perfeição.
Nenhuma ação no mundo Linux foi capaz de trazer mais familiarização com o mundo Linux do que o próprio WSL.
Tem de ser um imbecil pra criticar o WSL, porque ele está fazendo o mundo Linux ganhar uma tribo que nunca teria contato com Linux na vida.
E hoje começa-se com o WSL, depois instala o Ubuntu em uma VM… depois em um desktop…
e assim vai.
Nenhuma UI, nenhuma distro, nada no mundo Linux foi capaz de fazer o Linux ultrapassar os 2% de marketshare em 30 anos (2021).
Agora em 2023 está acima de 3%.
Em resumo, em 3 ou 4 anos o crescimento do uso de Linux impulsionado pelo WSL (apenas como porta de entrada) será maior do que todos os 30 anos de Linux.
Vocês tem de parar de fazer hating gratuito…
O WSL ajuda a comunidade Linux
E se você reclama do WSL, é porque não entendeu o propósito do WSL, está na área cincenta da bolha do twitter.
Grande abraço!
Ahh, o link para os dados históricos sobre Linux estão aqui
https://gs.statcounter.com/os-market-share/desktop/worldwide/#monthly-200901-202307