- Código do runtime JavaScript/WASM realmente usado no Cloudflare Workers
- Apenas algumas partes foram modificadas para permitir portar para outros ambientes
- O nome vem do
-d de "daemon" em servidores Unix, pronunciado "worker dee"
Uso
- Permite fazer self-host do Workers. Também funciona simplesmente como um servidor web acessível por API. Fácil de aplicar em qualquer ambiente
- Uso para desenvolvimento e testes locais
- Proxy programável (forward e reverse). É possível interceptar e processar requisições/respostas com JavaScript
O que é
- Server-first : muitos runtimes JS/WASM podem ser usados para vários propósitos, mas o workerd é focado apenas em servidor. Mais especificamente, servidor HTTP
- APIs web padrão : fornece as mesmas APIs padrão usadas em navegadores web (Fetch, URL, WebCrypto etc.). Ou seja, o código desenvolvido aqui também pode ser portado para o navegador
- Nanoservices : agora além de microsserviços, nanosserviços!
- Nanosserviços são um novo modelo que mantém as vantagens de deploy independente com overhead comparável ao de chamadas de função de biblioteca
- Com workerd, muitos Workers podem ser configurados dentro do mesmo processo, e cada Worker roda de forma independente, mas também pode se comunicar com os outros
- Homogeneous deployment : antes era preciso executar determinados serviços em contêineres específicos, mas com workerd todas as máquinas podem rodar todos os serviços
- Capability bindings: configuração limpa e garantia de segurança contra SSRF
- Always backwards compatible : compatibilidade retroativa sempre garantida
O que não é
- workerd is not a Secure Sandbox : código malicioso pode ser executado. Para evitar isso, é necessária uma camada de sandbox separada
- workerd is not an independent project : é parte central do Cloudflare Workers. Aceita commits externos, mas é difícil garantir isso.
- workerd is not an off-the-shelf edge compute platform : não é o serviço Workers completo
2 comentários
Era algo que eu queria experimentar quando fosse lançado, opa.
Eu fiquei me perguntando o que isso significava, mas logo percebi que era exatamente o que se explicava na parte anterior sobre desenvolver no modelo de nanosserviços (
functions): você simplesmente implanta todos os nanosserviços em uma única máquina (algo viável porque o overhead é baixo) e, se precisar, basta aumentar a quantidade de máquinas idênticas, então não é necessária uma configuração de implantação complexa.