Visualização 2 do WASI: O que o WebAssembly pode e o que ainda não pode fazer

O WASI Preview 2 do WebAssembly pode não ser considerado um desenvolvimento inovador, mas é uma promessa para o futuro.

O novo padrão WebAssembly System Interface (WASI) é um passo na direção certa, potencialmente abrindo caminho para que o WebAssembly cumpra seu entusiasmo e promessa. Paradoxalmente, o seu estado actual não é necessariamente oportuno. Indiscutivelmente, chega tarde, embora não por culpa da comunidade vibrante e ativa que desenvolve o WebAssembly e, neste caso, o modelo de componente.

O lançamento, portanto, não pressagia uma nova era para o WebAssembly, tornando-o mais um marco atrasado do que um novo começo. Na verdade, o trabalho de padronização WASI está em andamento há muito tempo, antecedendo grande parte do uso generalizado do WebAssembly em aplicativos e ainda não está completamente pronto.

Neste contexto, a evolução do Wasm levou à necessidade de um modelo de componentes e principalmente de sua relação com o WASI, que é a interface padrão ou API que liga os módulos web assembly aos componentes. Um componente WebAssembly desempenha um papel crítico na forma como os tempos de execução executados dentro dos módulos WebAssembly são implantados.

Uma vez finalizado, um modelo de componente que permitirá ao WebAssembly não apenas ver seu uso em expansão além de navegadores e servidores da Web – mas também permitirá que os usuários implantem diferentes aplicativos executados em vários módulos leves em velocidades muito altas em milhares de terminais simultaneamente por meio de um interface de componente chamada sem alterar um pingo de código.

“Embora o WASI Preview 2 seja uma importante ‘aposta no terreno’ e mostre a grande visão do que os aplicativos WebAssembly poderiam eventualmente se tornar, também precisamos deixar claro o fato de que ainda há muito trabalho a ser feito e terá que ser feito rapidamente antes que o entusiasmo diminua”, disse Torsten Volk, analista da Enterprise Management Associates (EMA), ao The New Stack.

Embora seja um pequeno passo, o WASI Preview 2 “é necessário agora”, disse Daniel Lopez Ridruejo, fundador e ex-CEO da Bitnami (agora parte da VMware), ao The New Stack. “WASI Preview 2 significa que Wasm, e WASI em particular, estão indo na direção certa e esperamos que isso acelere as coisas”, já que uma API de componente irá se popularizar e eventualmente se tornar geralmente disponível, disse ele.

O mundo

O WASI Preview é digno de nota porque aproxima o Wasm de um modelo de componente finalizado, dependente de “mundos”.

Dan Gohman, um dos principais contribuidores e criadores do Wasm, em uma postagem recente no blog observa como o subgrupo WASI diz oficialmente que as APIs do Preview 2 são estáveis ​​e que o Preview 2 inclui dois “mundos”:

• wasi-cli, o mundo da “interface de linha de comando”, que corresponde aproximadamente ao POSIX. Arquivos, soquetes, relógios, números aleatórios, etc.
• wasi-http, um mundo proxy HTTP, organizado em torno de solicitações e respostas.

“Uma coisa boa sobre o atraso do WASI Preview 2 é que agora o WASI abraçou totalmente a abordagem de componentes – uma parte do ecossistema Wasm que não se estabilizou até o final de 2023. Mesmo com o avanço dos padrões, agora é possível usar mundos declarar dependências em nível programático”, disse Matt Butcher, cofundador e CEO da Fermyon, ao The New Stack. “Este é um grande benefício para a compatibilidade e interoperabilidade (e ajuda a prevenir a fragmentação nociva do ecossistema Wasm). Estou impaciente com o WASI Preview 2, mas, pensando bem, devo dizer que rebasear o WASI no modelo de componentes foi a decisão certa a tomar.”

O sonho continua

O hype em torno do WebAssembly é atribuído ao seu potencial de oferecer uma API, conectando linguagens de um endpoint a outro ou distribuindo de um endpoint para vários endpoints por meio de linhas de código concisas em um único módulo. O padrão WASI desempenha um papel crucial na viabilização dessa eventual capacidade.

Como Gohman, em um post anunciando a pré-visualização, escreve: “O trabalho para a Pré-visualização 3 estará em andamento. O banner principal do Preview 3 é assíncrono e adiciona os tipos futuro e de fluxo ao Wit. E aqui novamente o tema é composição. Uma coisa é fazer assíncrono, outra é fazer assíncrono combinável, onde dois componentes assíncronos podem ser compostos juntos sem que nenhum loop de evento precise ser aninhado dentro do outro. Projetar um sistema assíncrono flexível o suficiente para Rust, C#, JavaScript, Go e muitos outros, que têm suas próprias perspectivas sobre assíncrono, levará algum tempo, portanto, enquanto o trabalho de design está começando agora, espera-se que o Preview 3 seja pelo menos daqui a um ano.”

No entanto, o estado atual do WASI não indica a deficiência geral do WebAssembly. Paradoxalmente, o WebAssembly alcançou uma adoção significativa para navegadores e servidores web, graças à sua grande e crescente comunidade de código aberto que aprimora continuamente esse aspecto.

Embora menos divulgado, o WebAssembly está em uso prático dessa maneira há alguns anos. Passando para o avanço em questão – o alegado desenvolvimento do WASI, conforme eloquentemente descrito por Gohman – ele é promissor.

Gohman também escreve: “Ainda há muito mais a fazer, escrever mais documentação, mais testes, mais conjuntos de ferramentas, mais implementações e há muito mais recursos que todos nós queremos adicionar. Esta votação de hoje é um marco no caminho, e não um destino em si. “

WASI Preview 2 não é exatamente um desenvolvimento inovador, mas fornece uma visão sobre o que o WebAssembly pode e deve ser. A maioria dos desenvolvedores não está preocupada com as complexidades do WebAssembly, embora alguns, movidos pela curiosidade intelectual e pela paixão pela computação, o considerem fascinante.

Em termos de aplicação prática, muitos desenvolvedores desejam simplesmente integrar perfeitamente um aplicativo escrito em sua linguagem preferida. Esse desejo vai além de linguagens difíceis de aprender, como Rust, Python ou Go, e inclui a incorporação de JavaScript. O processo envolve escrever o aplicativo, adicioná-lo ao módulo WebAssembly e, posteriormente, distribuí-lo para potencialmente milhares de terminais por meio de um único módulo. Esta distribuição pode ocorrer em dispositivos de IA incorporados em vários dispositivos, servidores ou qualquer local com uma CPU executando um conjunto de instruções.

Mais trabalho

O que o WASI Preview 2 faz agora é fornecer um “vislumbre de um mundo novo e excitante de aplicativos completamente modulares, onde cada módulo pode ser escrito em uma linguagem diferente, mas todos os módulos podem se comunicar entre si e com o mundo exterior através do modelo de componente, Volk disse. “Em última análise, isso poderia nos permitir adicionar ou eliminar novos recursos de aplicativos em tempo de execução.”

No entanto, surgem duas questões principais, observou Volk: o que podemos fazer com wasi-cli e wasi-http agora e quando o restante do modelo de componentes será definido? A resposta é que o wasi-http nos permite enviar e receber dados por meio de respostas HTTP e o wasi-cli nos fornece a capacidade de interagir com o sistema operacional por meio da linha de comando, disse Volk. Isso deve permitir a criação de microsserviços e servidores web que possam se comunicar por meio de chamadas HTTP e executar tarefas básicas de computação. “No entanto, como o WASI 0.2 não fornece acesso a bancos de dados, sistemas de arquivos, mensagens, GPUs, sistemas de arquivos ou rede física e como as bibliotecas UI padrão e multithreading não estão disponíveis, nossos microsserviços e servidores web são limitados no que podem fazer”, disse Volk. “Embora existam soluções alternativas, como, por exemplo, interagir com bancos de dados via HTTP, o WASI 0.2 ainda não oferece uma experiência completa para o desenvolvedor.”

Entretanto, o WASI Preview 2 representa um passo na direção certa, marcando um marco significativo. Contribui para o objetivo abrangente de permitir a distribuição de aplicações, inaugurando o potencial para isso em diversas plataformas de computação. Embora este seja um marco, ainda é necessário um desenvolvimento significativo para estabelecê-lo como um padrão comum, conforme descrito acima. “Os componentes e o WASI Preview 2 impõem um trabalho considerável aos desenvolvedores de tempo de execução do WebAssembly e aos engenheiros de compilador. Mas este é um trabalho com benefícios óbvios. Wasmtime, Rust, Kotlin, Python, JavaScript e outros tempos de execução e linguagens já estão avançando rapidamente”, disse Butcher. “Ficarei surpreso se não vermos a adoção generalizada do WASI Preview 2 e dos componentes até meados de 2024. Sim, eu realmente acho que isso vai acontecer tão rápido.”

Cada versão do WASI também abre novas possibilidades para o emprego do Wasm, disse Butcher. “Isso é uma faca de dois gumes. Sim, é óptimo ver progressos, mas se não conseguirmos fazer as coisas colectivamente de uma forma mais atempada, corremos o risco de a impaciência afastar os implementadores”, disse Butcher. “Desbloquear um novo conjunto de recursos aumenta a pressão para desbloquear o próximo mais cedo.”

A postagem WASI Preview 2: O que o WebAssembly pode e não pode fazer ainda apareceu pela primeira vez em The New Stack.