Cloudflare construye una CLI unificada que abarcará todos sus productos

 (blog.cloudflare.com)
5 puntos por GN⁺ 16 일 전 | 2 comentarios | Compartir por WhatsApp
  • Cloudflare está reconstruyendo la próxima generación de Wrangler para ofrecer más de 100 productos y cerca de 3,000 API HTTP en una sola CLI unificada (cf), y actualmente ya se puede usar una vista previa técnica con npx cf
  • Como solo con el esquema OpenAPI existente no se pueden expresar interfaces diversas como comandos de CLI, bindings de Workers y habilidades de agentes, introdujo un nuevo sistema de esquemas basado en TypeScript
  • En línea con la tendencia de que los agentes usen la CLI como consumidor principal, impone a nivel de esquema reglas de consistencia y guardrails para los comandos como get/--force/--json
  • Lanzó en beta abierta la función Local Explorer, que permite explorar fácilmente recursos simulados durante el desarrollo local y revisar directamente datos locales de KV, R2, D1 y más
  • Su objetivo es ofrecer toda la API de Cloudflare de forma consistente con la misma forma de API tanto en la CLI como en el entorno local, para optimizar la experiencia de desarrollo tanto para agentes como para desarrolladores

La escala de las API de Cloudflare y el giro hacia agentes

  • Cloudflare cuenta con más de 100 productos y alrededor de 3,000 operaciones de API HTTP
  • Los agentes están emergiendo como consumidores principales de las API, y los desarrolladores están construyendo y desplegando aplicaciones, agentes y plataformas en Cloudflare mediante agentes de programación
  • Cloudflare ya ofrece toda su API mediante un único servidor MCP de Code Mode de menos de 1,000 tokens, pero necesita cubrir más interfaces como comandos de CLI, bindings de Workers, SDK, archivos de configuración, Terraform, documentación para desarrolladores y Agent Skills
  • En la CLI Wrangler existente faltaban comandos para muchos productos de Cloudflare, y los agentes tienden a preferir la CLI

Reconstrucción de la CLI Wrangler de próxima generación

  • Está reconstruyendo la CLI Wrangler como una CLI para todo Cloudflare, para ofrecer comandos para todos los productos y permitir una configuración unificada al estilo infrastructure-as-code
  • La vista previa técnica puede instalarse con npx cf o npm install -g cf
  • Por ahora solo admite algunos productos, pero internamente ya está probando una versión compatible con toda la superficie de API de Cloudflare
  • Está revisando y ajustando los comandos de cada producto con una salida ergonómica tanto para agentes como para personas
  • Planea combinarlo en los próximos meses con las fortalezas del Wrangler existente

Esquema basado en TypeScript y pipeline de generación de código

  • Antes generaba automáticamente API SDK, el proveedor de Terraform y el servidor MCP de Code Mode a partir de esquemas OpenAPI
  • Las actualizaciones de CLI, bindings de Workers, configuración de wrangler.jsonc, Agent Skills, dashboard y documentación seguían siendo un proceso manual, con errores frecuentes y sin posibilidad de escalar
  • El esquema OpenAPI solo puede describir API REST, por lo que no puede expresar comandos de CLI interactivos que combinan desarrollo local con solicitudes API, ni bindings de Workers basados en RPC, ni Agent Skills y documentación
  • Al observar que TypeScript funciona como lenguaje común dentro de Cloudflare, confirmó que expresar APIs en TypeScript es más efectivo en Cap n' Web, Code Mode y el sistema RPC de la plataforma Workers
  • Introdujo un nuevo esquema en TypeScript para definir la API, los comandos de CLI, sus argumentos y todo el contexto necesario para generar interfaces
    • Es una forma de tipos TypeScript con convenciones, linting y guardrails aplicados
    • Como es un formato propio, puede soportar con flexibilidad cualquier interfaz necesaria y aun así generar esquemas OpenAPI

Consistencia entre agentes y CLI, e ingeniería de contexto

  • Los agentes esperan consistencia en la CLI, y si un comando usa info y otro usa get, puede ocurrir que el agente invoque comandos que no existen
  • En una organización grande con cientos o miles de ingenieros, mantener la consistencia solo con revisiones inevitablemente genera huecos, como en el modelo del queso suizo
  • Si la consistencia se fuerza solo en la capa de CLI, se agrava el problema de que los nombres difieran entre la CLI, la API REST y los SDK
  • Aplica reglas y guardrails a nivel de esquema: siempre get (nunca info), siempre --force (nunca --skip-confirmations), siempre --json (nunca --format), con soporte consistente en todos los comandos
  • La CLI Wrangler tiene una estructura especial que funciona tanto con recursos locales simulados como con recursos remotos
    • Bases de datos D1, buckets de almacenamiento R2 y namespaces de KV se admiten tanto en local como en remoto
    • Puede generarse confusión cuando un agente cree que está modificando una base de datos remota, pero en realidad agrega registros a una base de datos local
    • Ofrece guía explícita a los agentes mediante valores predeterminados consistentes y una salida que indica claramente si algo es local o remoto

Local Explorer — exploración local de recursos igual que en remoto

  • Lanzó Local Explorer en beta abierta, disponible tanto en la CLI Wrangler como en el plugin de Cloudflare para Vite
  • Durante el desarrollo local, permite explorar directamente los recursos simulados que usa un Worker: KV, R2, D1, Durable Objects y Workflows
  • Permite realizar en un entorno completamente local las mismas acciones que se pueden hacer desde la API y el dashboard de Cloudflare, con la misma estructura de API
  • Cloudflare ha invertido durante años en el desarrollo completamente local, y hasta una base de datos serverless administrada como D1 puede ejecutarse totalmente en local mediante bindings sin configuración ni herramientas adicionales
    • Miniflare (emulador de la plataforma de desarrollo local) ofrece la misma API que producción y usa una base de datos SQLite local
    • Permite escribir y ejecutar pruebas rápidamente sin acceso a red, y funciona incluso sin conexión
  • Antes, para revisar qué datos se habían guardado localmente, era necesario hacer ingeniería inversa del directorio .wrangler/state o instalar herramientas de terceros
  • Al ejecutar una app con la CLI Wrangler o el plugin de Cloudflare para Vite, aparece un prompt para abrir Local Explorer y se puede acceder con el atajo de teclado e
    • Proporciona una interfaz local para ver los bindings conectados al Worker actual y sus datos correspondientes
  • Al construir con agentes, resulta útil para entender cómo el agente maneja los datos, y permite validación de esquemas, sembrado de registros de prueba e inicialización con DROP TABLE
  • Ofrece un espejo local de la API de Cloudflare que solo modifica datos locales, permitiendo acceder a recursos locales con la misma API que en remoto
    • Como la forma de la API es la misma en local y en remoto, al pasar la bandera --local en la CLI la solicitud se redirige a la API espejo local y funciona igual
  • La API local está disponible en la ruta /cdn-cgi/explorer/api, donde los agentes pueden descubrir la especificación OpenAPI y administrar recursos locales

Solicitud de comentarios y próximos pasos

  • La vista previa técnica de la CLI de próxima generación ya puede usarse con npx cf o npm install -g cf
  • Solicita comentarios no solo sobre las funciones actuales de la vista previa técnica, sino también sobre lo que la gente quiere de una CLI para toda la plataforma de Cloudflare
    • Tareas que hoy requieren varios clics en el dashboard, pero que se quisieran hacer con un solo comando de CLI
    • Elementos que se quisiera configurar en wrangler.jsonc (por ejemplo, registros DNS o reglas de caché)
    • Puntos donde los agentes se atascan y comandos que se espera que la CLI ofrezca
  • Está recibiendo comentarios en Cloudflare Developers Discord

Lecturas relacionadas

2 comentarios

 
eoeoe 15 일 전

Ojalá también arreglaran el error que ocurre al intentar exportar una base de datos D1 con una tabla FTS configurada.
Es lo más incómodo de usar wrangler.
 
GN⁺ 16 일 전
Comentarios de Hacker News

  • Estaría bueno que Wrangler CLI mostrara de antemano los permisos del token de API necesarios durante el desarrollo local
    Así quedaría claro qué permisos hacen falta antes de desplegar, y sería ideal tener un comando como cf permissions check para verificar permisos faltantes o innecesarios

    • Totalmente de acuerdo. Si ChatGPT configura mal los permisos al principio, al final uno termina pasando horas revisando la documentación o probando combinaciones de tokens
    • Un comando doctor para hacer esto sería realmente útil. Ojalá más servicios ofrecieran algo así
    • Antes configuré mal un token por un error tipográfico, y una función así me habría ayudado muchísimo
    • Yendo más allá, también estaría bueno que la CLI pudiera generar claves automáticamente
    • Al final, lo importante es mejorar la descubribilidad (discoverability) de la API
      GraphQL sigue muy bien los principios de HATEOAS, así que favorece que los LLM exploren la API
      Me parece mucho mejor una estructura donde la propia API exponga sus capacidades, en lugar de sufrir problemas porque la versión de la documentación no coincide

  • Ojalá primero agregaran control de permisos a nivel de grupos de recursos
    Ahora solo hay permisos basados en zone (dominio), así que recursos que no pertenecen a una zone, como los workers, pueden tener su código reemplazado o ser eliminados incluso con permisos bajos
    Sería aún mejor si soportaran una estructura de supercuenta + subcuenta como GitHub Enterprise. Ej.: ACME Corp / ACME Corp (Prod)

    • Me pregunto si esto sería el mismo concepto que la función Cloudflare Organization
    • Aunque no se puedan compartir dominios, una estructura de supercuenta + subcuenta sería realmente útil
    • Coincido en que el hecho de que los workers no estén basados en zone reduce bastante su utilidad

  • Excelente artículo, me inspiró bastante. Igual me sorprendió que no mencionaran TypeSpec
    Es un lenguaje de esquemas con estilo TypeScript que suelo describir como “así se sentiría OpenAPI si de verdad estuviera bien hecho”
    Supongo que habrán pensado que una implementación propia sería más simple y flexible. Últimamente, además, gracias a los agents el costo de BYO ha bajado bastante

    • Me encanta TypeSpec. Hace que escribir OpenAPI sea mucho más fácil
      Pero últimamente prefiero las APIs estilo aep.dev. Gracias a sus patrones consistentes, es fácil usar aepcli de inmediato o crear uno propio
      Terraform también funciona directamente sin necesidad de un provider aparte
    • Me da curiosidad qué parte de OpenAPI mejora exactamente

  • Últimamente me parece interesante este enfoque de diseño CLI-first centrado en agentes de IA
    Nosotros también, al crear herramientas para desarrolladores, hicimos primero la CLI y la API, y recién después agregamos el dashboard
    La idea de cf permissions check que se mencionó arriba me parece especialmente buena
    Los agents usan bien la CLI, pero son malos para diagnosticar la causa de los errores.
    Mensajes de error claros como “falta scope X, ejecuta cf token add --scope X” son mucho más importantes

  • Dicen que se puede probar la vista previa tecnológica directamente con npx cf, pero tengo algunas dudas
    Quisiera saber si es open source y si planean ofrecerlo como binario único sin depender de Node.js.
    ¿Tal vez podrían aprovechar algo como Bun, que adquirieron hace poco?

    • Yo tampoco pude encontrar el repositorio, pero el paquete npm tiene licencia MIT e incluye source maps, así que parece que pronto lo van a publicar

  • Ojalá evitaran los tokens de larga duración.
    En cambio, estaría bueno poder crear fácilmente desde la CLI tokens restringidos y de corta duración, administrarlos en archivos o renovarlos automáticamente
    Otra opción sería tener un modo proxy para delegar acceso solo a dominios o buckets específicos

    • Me gusta el enfoque de GitLab de generar de una sola vez PAT de corta duración a través de un servidor SSH

  • Irónicamente, con la llegada de la era de los agentes de IA estamos volviendo otra vez al desarrollo centrado en la CLI
    Cada vez que tengo que limpiar la caché de Cloudflare, debo hacer varios clics en la web UI; sería mucho mejor simplemente darle la orden a OpenClaw agent

    • Ni siquiera hace falta usar OpenClaw. Puedes invocar directamente el comando de la CLI. Esa es justamente la esencia de la CLI

  • El método de autenticación de Wrangler solo ofrece dos opciones: OAuth (acceso total) y tokens estáticos creados manualmente desde el dashboard
    Pero eso no encaja cuando personas y agentes de IA necesitan límites de permisos distintos
    Estaría bueno poder crear directamente desde la CLI tokens con scope y de corta duración
    También se está discutiendo en GitHub issue #13042.
    Los tokens deberían poder detallarse no solo por tipo de recurso, sino también por ID de recurso y acción

  • El 1 de abril, Cloudflare presentó EmDash junto con soporte para x402, y ahora parece que está enfocándose en la CLI
    Da la impresión de que Cloudflare está reconstruyendo silenciosamente un ecosistema para desarrolladores donde los agentes, más que los humanos, son los principales usuarios

  • Dicen que definieron la API, los comandos de la CLI, los argumentos y el contexto con esquemas TypeScript,
    así que me pregunto por qué no presentaron aquí esa herramienta o framework
    También quisiera saber si tiene una estructura similar a la de TypeSpec mencionada arriba