WASM, a nova tecnologia CGI

 (roborooter.com)
3 pontos por GN⁺ 2024-10-11 | 1 comentários | Compartilhar no WhatsApp

Wasm é o novo CGI

  • Papel do Wasm: O Wasm (WebAssembly) está se preparando para trazer uma nova mudança ao modelo de aplicações web. O foco é facilitar a construção e a manutenção de aplicações de alto desempenho.
  • Modelo antigo de aplicações web: O CGI transformou a web de um arquivo de documentos em uma rede de aplicações. O FastCGI foi desenvolvido para resolver problemas de desempenho e, depois, evoluiu para a computação serverless.
  • Computação serverless: A computação serverless, como o Amazon Lambda, faz com que você gerencie "funções" em vez de servidores. Isso oferece a vantagem de escalar rapidamente de acordo com o volume de requisições.

Wasm no servidor

  • Escalabilidade do Wasm: O Wasm pode ser executado não apenas no navegador, mas também no servidor, oferecendo um modelo de isolamento mais leve para aplicações do lado do servidor.
  • Ambiente de execução do Wasm: Os módulos Wasm são executados em uma máquina virtual e podem ser compilados a partir de várias linguagens. Isso pode contribuir para melhorar o desempenho em ambientes serverless.

Trade-offs do Wasm

  • Threads e compilação JIT: O Wasm não oferece suporte nativo a threads, e a compilação JIT não é possível. Isso pode afetar o desempenho.
  • Interface de memória: A movimentação de dados entre módulos Wasm e o host pode exigir cópia, o que pode impactar o desempenho.

Perspectivas futuras

  • Evolução do Wasm: À medida que os ambientes de execução e as ferramentas de desenvolvimento do Wasm evoluem, linguagens de script passarão a ter runtimes Wasm. Isso pode melhorar bastante a velocidade de execução das aplicações.
  • Edge computing: O Wasm permite realizar computação perto do usuário por meio de edge computing, o que melhora o desempenho.

# Resumo do GN⁺

  • O Wasm está liderando uma nova mudança no modelo de aplicações web, facilitando a construção e a manutenção de aplicações de alto desempenho.
  • A combinação de computação serverless e Wasm reduz a complexidade do gerenciamento de servidores e oferece a vantagem de escalar rapidamente conforme o volume de requisições.
  • O Wasm pode ser executado não apenas no navegador, mas também no servidor, oferecendo um modelo de isolamento mais leve para aplicações do lado do servidor.
  • A evolução do Wasm pode permitir que linguagens de script passem a ter runtimes Wasm, melhorando bastante a velocidade de execução das aplicações.
  • Por meio de edge computing, é possível realizar computação perto do usuário, o que melhora o desempenho.

Leituras relacionadas

1 comentários

 
GN⁺ 2024-10-11
Opiniões do Hacker News

  • A Amazon iniciou a era da computação serverless com o Lambda. O Google App Engine foi lançado 6 anos antes do Lambda.

  • É difícil entender a diferença entre WASM e tecnologias anteriores como Java Applets, ActiveX, Silverlight e Macromedia Flash. Achei que já tínhamos aprendido a lição sobre executar código compilado de terceiros não confiável no navegador.

  • Compilação JIT é impossível porque a geração dinâmica de código WASM não é permitida por motivos de segurança. Isso é uma funcionalidade essencial para fazer coisas como hot reload de código de forma limpa.

  • Acho que as alegações de segurança não são confiáveis. É possível fazer hot reload de JS ou gerar código em runtime, e também recarregar dinamicamente o runtime de WASM preservando a memória, mas a experiência do usuário seria incômoda.

  • Não encontrei um motivo pelo qual isso seria tecnicamente impossível. Se for uma medida de segurança, provavelmente seria fácil de contornar.

  • O bytecode do WASM é conceitualmente semelhante a coisas como .NET IL e bytecode Java, que foram projetados para compilação JIT.

  • Acho que o projeto WASM carece de direção clara e de vontade de sucesso. Funcionalidades básicas ainda estão faltando.

    • Isso inclui hot reload, threading sem hacks, interface nativa com o DOM, suporte a APIs gráficas/de computação de baixo overhead e acesso a áudio em baixo nível.

  • WASM substitui a VM de uma linguagem específica por uma VM de propósito geral. Isso permite executar quase tudo com compiladores ou interpretadores.

    • Em geral, ele é implementado como parte de um engine de JavaScript, herdando sandboxing e acesso a APIs. A padronização ainda está em andamento.

  • WASM é apresentado como substituto de JavaScript, de Docker, de Java, de CGI etc. Ou seja, é tudo.

  • Acho que WASM deveria poder ser hospedado e implantado com a mesma facilidade que uma aplicação PHP. Provavelmente ainda não chegamos lá.

  • Isso lembra uma velha lei do software: uma aplicação suficientemente grande e antiga acaba reimplementando toda a pilha de software em que está rodando.

  • A grande promessa do WASM no lado do servidor é fornecer uma plataforma eterna que não exija atualizações regulares.

    • Atualizar e reimplantar apps no AWS Lambda sempre que uma versão de Node.js ou Python deixa de ser suportada é um grande problema.

  • Acho que o modelo local-first é o futuro. Os apps rodam principalmente no navegador do usuário e quase não precisam de ajuda do servidor.

    • Apps como Figma, Linear e Superhuman estão usando esse modelo com sucesso.

  • WASM pode ter sucesso no navegador do usuário. A Microsoft está usando isso com C#/Blazor.

  • Parece que estamos reinventando a JVM e seu ecossistema.

  • Acho que WASM vai caminhar para substituir o código de execução de funções lambda na nuvem.

    • WASM é tradicionalmente visto como algo que roda na plataforma hospedeira, mas isso não precisa necessariamente ser assim.

    • Graças às propriedades de sandbox do WASM, ele pode rodar fora do sistema operacional ou em ring0.