- El código real del runtime de JavaScript/WASM que se usa en Cloudflare Workers
- Solo se modificó una parte para que pueda portarse a otros entornos
- El nombre viene del
-d de "daemon" en los servidores Unix, y se pronuncia "worker dee"
Casos de uso
- Permite self-hostear Workers. También es, simplemente, un servidor web utilizable vía API. Puede aplicarse fácilmente en cualquier entorno
- Uso para desarrollo local y pruebas
- Proxy programable (forward y reverse). Permite interceptar y procesar solicitudes/respuestas con JavaScript
Qué es
- Server-first: muchos runtimes de JS/WASM pueden usarse para múltiples propósitos, pero workerd está enfocado únicamente en servidores, especialmente en servidores HTTP
- APIs web estándar: ofrece APIs estándar como las que se usan en navegadores web (Fetch, URL, WebCrypto, etc.). Es decir, el código desarrollado aquí también puede portarse al navegador
- Nanoservices: ahora, más allá de los microservicios, ¡nanoservicios!
- Los nanoservicios son un nuevo modelo con las ventajas del despliegue independiente y un overhead comparable al de llamar a una función de biblioteca
- Con workerd, muchos Workers pueden configurarse dentro del mismo proceso, y cada Worker se ejecuta de forma independiente, pero también puede comunicarse con los demás
- Homogeneous deployment: antes había que ejecutar ciertos servicios en contenedores específicos, pero con workerd todas las máquinas pueden ejecutar todos los servicios
- Capability bindings: configuración limpia y garantía de seguridad ante SSRF
- Always backwards compatible: garantiza siempre compatibilidad hacia atrás
Qué no es
- workerd is not a Secure Sandbox: puede ejecutarse código malicioso. Para evitarlo, se necesita una capa de sandboxing adicional
- workerd is not an independent project: es una parte central de Cloudflare Workers. Aceptan commits externos, pero es difícil garantizarlo.
- workerd is not an off-the-shelf edge compute platform: no es el servicio completo de Workers
2 comentarios
Era algo que quería probar cuando se publicara, oh.
No entendía qué significaba esto, pero resulta que, como explican justo antes, si desarrollas con el enfoque de nanoservicios (functions), puedes simplemente desplegar todos los nanoservicios en una sola máquina (dicen que es posible porque la sobrecarga es baja) y, si hace falta, solo aumentas la cantidad de máquinas iguales, así que no necesitas una configuración de despliegue compleja.