Beyond CDN
Qué prepara y entrega Beyond CDN, cómo funcionan sus tres etapas, qué no puede hacer nunca una solicitud GET y qué queda fuera de la versión 1.
- Disponibilidad: Experimental
- Evidencia: Leído del código fuente
- Explicación
Qué hace el CDN
Beyond CDN prepara una aplicación publicada y luego la entrega. Una aplicación tiene targets de frontend, targets de backend, o ambos. Cada target indica una entrada pública de un paquete, y el CDN determina todo lo que esa entrada necesita: las versiones exactas de los paquetes, los módulos públicos alcanzables desde ella, sus estilos y los recursos estáticos que los paquetes declaran.
La entrega es HTTP simple. Un módulo público compilado tiene una dirección, y esa dirección tiene la misma forma relativa en un servidor de desarrollo local y en el CDN:
https://cdn.beyondjs.com/m/@example/app@1.0.0/modules/core/router?target=browser&format=esm
https://cdn.beyondjs.com- Origen base: lo único que cambias
/m/- Espacio de nombres
@example/app- Paquete
@1.0.0- Versión exacta
/modules/- Familia de recursos
core/router- Subruta del módulo público
?target=browser&format=esm- Opciones
Un consumidor que funciona contra un servidor de desarrollo funciona contra el CDN cambiando el origen base y nada más. La ruta, las opciones, los encabezados de respuesta y los cuerpos de error siguen un contrato compartido, @beyond-js/artifact-api. Consulta URL e identidades.
Todo origen responde además su resolución, /resolution.json y /importmap.json: qué dirección entrega cada especificador público. Cada entorno consume esos dos documentos a su manera: un navegador con un import map o con SystemJS, Node.js mediante BEE Node, Deno con --import-map. El modelo es uno; las estrategias difieren. Consulta Estrategias por entorno.
Los paquetes vienen de npm, de otros registros compatibles con npm accesibles por Internet, de repositorios Git fijados a un commit y de URL de archivos comprimidos fijadas a un digest, y la dirección de cada módulo indica de cuál. Un paquete público produce salidas públicas aunque se haya usado el token de tu organización para leerlo. Consulta Fuentes y Proveedores de registro.
Cómo se verifica esta sección
A estas páginas se les aplican dos tipos de verificación, y no son lo mismo.
- Verificada contra los contratos. Una prueba automatizada compara la referencia con los contratos: cada operación de administración con su método, su ruta, su capacidad y su tipo de reintento; cada código de error y de fallo con su estado; cada tipo de evento con sus canales y su clase de entrega; cada opción de solicitud con sus valores y su valor predeterminado; la tabla de roles y las capacidades que dependen de un entorno; los miembros de una solicitud de registro; los nombres de las cuotas; el puntero de tiempo real; y cada valor predeterminado de ingeniería que cita una página. Una página que nombra algo que los contratos no definen hace fallar esa prueba.
- Verificada en ejecución. Un ejemplo se ejecutó contra un servicio real y se registró su resultado. No hay nada desplegado y el servicio integrado todavía se está ensamblando, así que todo ejemplo que necesita un origen está registrado como no ejecutado. La única excepción es el ejemplo de resolución, que se ejecuta sin conexión contra el códec compartido.
Una página con la etiqueta «Leído del código fuente» está verificada solo contra los contratos. Ninguna página de esta sección afirma que exista una versión con soporte.
Obtener un recurso nunca compila
Una solicitud GET al CDN devuelve contenido que ya existe, o informa que no existe. Nunca inicia una compilación, no reanuda ninguna y no pone trabajo en una cola. Esto vale para cualquier obtención: un módulo, una hoja de estilos, un source map, un recurso estático, una navegación del navegador y un fallo de caché.
Cuando el CDN conoce un módulo pero no tiene la salida que pediste, responde 404 con el código OUTPUT_NOT_AVAILABLE. Volver a pedirlo da la misma respuesta. El trabajo solo comienza cuando alguien envía una solicitud explícita de preparación mediante la API de administración.
Esta es la diferencia principal con un servidor de desarrollo. El Dev Server de Packages compila a partir de tus fuentes actuales cuando solicitas un módulo, y responde BUILD_FAILED cuando no compilan. El CDN no contiene un servidor de desarrollo y nunca ejecuta uno.
Las tres etapas
La preparación son tres etapas separadas. Cada una tiene su propio estado durable, sus registros y sus eventos en tiempo real, y cada una puede fallar sin tocar el release que está activo.
| Etapa | Qué ocurre | Qué no hace |
|---|---|---|
| 1. Registrar y resolver | Registras la aplicación, sus targets y sus selecciones de dependencias. El CDN resuelve el grafo completo de paquetes y versiones a partir de los metadatos del registro y lo fija, con el origen y la integridad de cada paquete. | No analiza código ni descarga ningún archivo de paquete. Un proveedor que no ofrece metadatos queda registrado como una excepción que requirió obtener un manifiesto. |
| 2. Preparar y analizar | Una tarea independiente descarga todos los paquetes del grafo fijado que el CDN aún no tiene, verifica su integridad y aplica límites de tamaño. Luego rastrea lo que es alcanzable desde tus entradas y guarda un inventario: módulos públicos de carga inmediata y diferida, estilos como módulos y recursos declarados. | No descarga los paquetes uno por uno a medida que se alcanzan los módulos, y no compila todos los módulos de todos los paquetes. El análisis está separado de la generación. |
| 3. Generar y servir | Solo se ponen en cola las salidas que faltan. Se reutiliza el trabajo compatible que otra aplicación autorizada ya pagó. Cuando todas las salidas requeridas están almacenadas y se pueden obtener, el release queda listo. | Un worker que terminó o un archivo almacenado no es estar listo. Todo el cierre de entrega debe ser durable. |
Una dependencia pública no espera a tu aplicación. Toda salida pública cuyo propio cierre alcanzable se verificó queda disponible por su identidad exacta en cuanto termina la preparación que la produjo, tanto si tu release quedó listo como si falló, y sin que la aplicación se promueva a ningún entorno. Si tu propio módulo no compila, la versión de React que sí compiló se sigue sirviendo a quien la pida; si falla React, no se sirve nada que lo importe. Esto nunca baja el listón de tu release: ese queda listo solo con su cierre completo.
La alcanzabilidad que da el análisis estático tiene un límite. Un import dinámico cuyo destino no se puede determinar necesita una declaración explícita; de lo contrario se informa como diagnóstico y el cierre no está completo. Consulta Preparación e inventario.
Releases
Un release es inmutable. Promover un release vincula un entorno (production o testing) a él con una operación atómica de comparar y establecer, y revertir vuelve a vincular el entorno a un release retenido. Ninguna de las dos operaciones vuelve a resolver dependencias ni recompila nada. Una preparación fallida o una promoción rechazada deja el release activo como estaba. Consulta Releases, promoción y reversión.
Una vez publicada, una aplicación se sigue entregando sin npm mientras se retengan sus fuentes y artefactos. Una caída del registro puede bloquear entradas nuevas que no estén en caché. Es una independencia respaldada por la retención, no una promesa de almacenamiento ilimitado ni de disponibilidad permanente.
Lo que conserva los bytes es una referencia, nunca una visita: una salida se retiene porque un release activo, un release retenido para revertir o una preparación en curso todavía la necesita, y no porque se haya pedido hace poco. Cuando desaparece el último de ellos, la salida y su identidad publicada se liberan juntas. Pedir una identidad pública no hace que se retenga, y ninguna URL se promete para siempre.
Desarrollo y CDN juntos
El Dev Server de Packages sigue siendo el lugar donde editas fuentes, usas la File API y recibes actualizaciones HMR. Durante el desarrollo local o en la nube, el CDN suministra las dependencias externas publicadas, mientras el Dev Server sirve los módulos que estás editando. Ambos responden las mismas URL de módulos y las mismas rutas de resolución. Los endpoints de edición, sesión y actualización del Dev Server son propios del desarrollo y no existen en el CDN. El runtime de desarrollo aplica las actualizaciones de la misma manera en un navegador, con SystemJS, en Node.js y en Deno; consulta Durante el desarrollo.
Gratuito y premium
La versión 1 tiene capacidades gratuitas y premium, y no tiene pagos ni proceso de compra. Un operador de la plataforma habilita premium para una organización de forma manual, y el crédito pertenece a la organización, nunca a un usuario.
| Gratuito | Premium (habilitado manualmente) | |
|---|---|---|
| Aplicaciones | Públicas | Públicas o privadas, con acceso de invitados que vence |
| Ejecución | Cola compartida, planificada en turnos cortos entre aplicaciones, sin SLA | Las mismas tareas sin el turno corto, con tiempos límite de seguridad y límites de crédito |
| Errores de compilación | Siempre se informan | Siempre se informan |
| Diagnósticos semánticos de TypeScript | No incluidos | Incluidos, medidos por separado |
| Subdominio de pruebas y dominios propios | Un subdominio de pruebas por aplicación; dominios propios verificados | Igual |
El almacenamiento y el tráfico no se prometen gratuitos ni ilimitados. Consulta Planes, crédito y consumo y Cuotas.
Fuera de la versión 1
Qué leer después
- Inicio rápido: solicita un módulo preparado desde dos orígenes con un solo cliente.
- Referencia de entrega: URL, opciones, salidas, entornos y cargadores, resolución, caché, acceso privado y errores.
- Referencia de administración: aplicaciones, las tres etapas, trabajos, releases, dominios, acceso, planes y cuotas.
- Referencia de tiempo real: canales, eventos, reconexión y revocación.
- Guías: publicación de paquetes, dependencias npm comunes, Widgets y frameworks de vista, targets de backend y solución de problemas.