WebAssembly (abreviado como Wasm) tem muito a oferecer ao mundo das aplicações web. No navegador, ele fornece um ambiente de execução seguro e isolado que permite aos desenvolvedores de frontend trabalhar com diversas linguagens de alto nível (não apenas JavaScript!) sem comprometer o desempenho. Já no backend (lado do servidor), o suporte multiplataforma e a portabilidade entre diferentes arquiteturas do WebAssembly prometem tornar o desenvolvimento, a implantação e a escalabilidade mais fáceis do que nunca.
Na NGINX, vislumbramos um mundo em que você possa criar um módulo WebAssembly para o lado do servidor e executá-lo em qualquer lugar, sem modificações e sem vários pipelines de compilação. Assim, seu módulo WebAssembly poderia partir do desenvolvimento local e chegar até ambientes multicloud de missão crítica.
Com o lançamento do NGINX Unit 1.31, temos o prazer de concretizar essa visão. O NGINX Unit é um servidor universal de aplicações web no qual o código da aplicação é executado juntamente com outros recursos essenciais, como TLS, arquivos estáticos e roteamento de solicitações. Além disso, o NGINX Unit faz tudo isso enquanto oferece uma experiência de desenvolvimento consistente para sete ambientes de execução de linguagens de programação e, agora, também para WebAssembly.
Adicionar WebAssembly ao NGINX Unit faz sentido por vários motivos:
- O padrão de solicitação-resposta do HTTP se encaixa naturalmente no fluxo de bytes de entrada/saída (E/S) do sandbox do WebAssembly.
- Os desenvolvedores podem aproveitar a produtividade das linguagens de alto nível sem comprometer o desempenho em tempo de execução.
- O roteador de requisições do NGINX Unit pode facilitar a criação de aplicações complexas a partir de vários módulos WebAssembly.
- O rápido tempo de inicialização do WebAssembly o torna igualmente adequado para implantar microsserviços e funções individuais ou até mesmo aplicações completas.
- A portabilidade universal e a compatibilidade entre plataformas permitem o desenvolvimento local sem pipelines de build complexos.
- O NGINX Unit já oferece isolamento por aplicação, e o sandbox do WebAssembly torna a execução de código não confiável ainda mais segura.
Observação: No momento da redação deste texto, o módulo WebAssembly está em versão de prévia tecnológica — mais detalhes abaixo.
Como funciona o módulo WebAssembly do NGINX Unit?
A arquitetura do NGINX Unit desacopla os protocolos de rede do ambiente de execução da aplicação. O processo unitd: router trata a solicitação HTTP recebida, cuidando da camada TLS conforme necessário. Depois de decidir o que fazer com essa solicitação, o “contexto HTTP” (URI, cabeçalhos e corpo) é então repassado ao ambiente de execução da aplicação.
Muitas linguagens de programação têm uma especificação precisa sobre como o contexto HTTP é disponibilizado ao código da aplicação e como um desenvolvedor pode acessar o URI, os cabeçalhos e o corpo. O NGINX Unit fornece vários módulos de linguagem que implementam uma camada de interface entre o roteador do NGINX Unit e o ambiente de execução da aplicação.
O módulo de linguagem WebAssembly para o NGINX Unit fornece uma camada de interface semelhante entre o runtime do WebAssembly e o processo do roteador. A memória linear do sandbox do WebAssembly é inicializada com o contexto HTTP da solicitação atual, e a resposta finalizada é enviada de volta ao roteador para transmissão ao cliente.
O ambiente de execução isolado é fornecido pelo runtime Wasmtime. O diagrama abaixo ilustra o fluxo de uma solicitação HTTP do cliente, passando pelo roteador, até o módulo WebAssembly executado pelo Wasmtime.
Executando módulos WebAssembly no NGINX Unit
Configurar o NGINX Unit para executar um módulo WebAssembly é tão simples quanto configurá-lo para qualquer outra linguagem. No trecho de configuração abaixo, há uma aplicação chamada helloworld com estes atributos:
typedefine o módulo de linguagem a ser carregado para esta aplicaçãomoduleaponta para um bytecode WebAssembly compiladoaccessé um recurso do runtime Wasmtime que permite que a aplicação acesse recursos fora do sandboxrequest_handler,malloc_handlerefree_handlerestão relacionados às funções do SDK que transferem o contexto HTTP para o Wasmtime (mais detalhes na próxima seção)
{
"applications":{
"helloworld":{
"type":"wasm",
"module":"/path/to/wasm_module.wasm",
"access":{
"filesystem":[
"/tmp",
"/var/tmp"
]
},
"request_handler":"luw_request_handler",
"malloc_handler":"luw_malloc_handler",
"free_handler":"luw_free_handler"
}
}
}Encontrando o contexto HTTP dentro do sandbox do WebAssembly
Como mencionado acima, o módulo de linguagem WebAssembly do NGINX Unit inicializa o ambiente isolado de execução do WebAssembly com o contexto HTTP da solicitação atual. Embora muitos ambientes de execução de linguagens de programação ofereçam acesso nativo e direto aos metadados HTTP, não existe um padrão desse tipo para WebAssembly.
Esperamos que o padrão WASI-HTTP venha a atender a essa necessidade no futuro. Enquanto isso, disponibilizamos um kit de desenvolvimento de software (SDK) para Rust e C. O SDK Unit-Wasm facilita a criação de aplicações web e APIs que podem ser compiladas para WebAssembly e executadas no NGINX Unit. Em nosso guia prático sobre WebAssembly, você pode conhecer o ambiente de desenvolvimento e as etapas de compilação.
Apesar da nossa visão e do nosso desejo de concretizar o potencial do WebAssembly como um ambiente de execução universal, os aplicativos criados com este SDK serão executados apenas no NGINX Unit. Por isso, estamos introduzindo o suporte ao WebAssembly como uma versão de prévia da tecnologia — esperamos substituí-lo pelo suporte ao WASI-HTTP assim que isso for possível.
Experimente a versão de prévia da tecnologia
A versão de prévia da tecnologia foi criada para demonstrar o potencial do WebAssembly no lado do servidor, oferecendo ao mesmo tempo um servidor leve para executar aplicações web. Explore-a com o intuito de testá-la na prática: faça experimentos e envie seus comentários. Gostaríamos muito de ouvir sua opinião no Slack da comunidade NGINX ou por meio do repositório do NGINX Unit no GitHub.
Para começar, instale o NGINX Unit e acesse o guia prático do WebAssembly
Sobre o autor

Publicações relacionadas no blog

Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.

Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.

Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.

Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.