Cloudflare, पूरे प्रोडक्ट पोर्टफोलियो को कवर करने वाला एकीकृत CLI बना रहा है

• Cloudflare 100 से अधिक प्रोडक्ट्स और लगभग 3,000 HTTP APIs को एक एकीकृत CLI(cf) के रूप में देने के लिए अगली पीढ़ी के Wrangler को फिर से बना रहा है, और इसका टेक्निकल प्रीव्यू अभी npx cf के जरिए उपलब्ध है
• मौजूदा OpenAPI schema केवल CLI commands, Workers bindings, agent skills जैसे विभिन्न interfaces को व्यक्त नहीं कर पाता, इसलिए TypeScript-आधारित नया schema system अपनाया गया है
• एजेंट्स द्वारा CLI को मुख्य consumer के रूप में उपयोग करने की प्रवृत्ति को देखते हुए, get/--force/--json जैसे command consistency rules और guardrails को schema स्तर पर लागू किया जा रहा है
• लोकल development के दौरान simulated resources को आसानी से एक्सप्लोर करने के लिए Local Explorer फीचर को open beta में जारी किया गया है, जिससे KV, R2, D1 आदि के लोकल डेटा को सीधे देखा जा सकता है
• Cloudflare के पूरे API को CLI और लोकल environment में एक ही API रूप में लगातार उपलब्ध कराकर, एजेंट्स और डेवलपर्स दोनों के लिए अनुकूलित development experience देना लक्ष्य है

---

Cloudflare के API का पैमाना और agent-केंद्रित बदलाव

• Cloudflare के पास 100 से अधिक प्रोडक्ट्स और लगभग 3,000 HTTP API operations हैं
• एजेंट्स API के प्रमुख consumer के रूप में उभर रहे हैं, और डेवलपर्स coding agents के जरिए applications, agents और platforms को Cloudflare पर build और deploy कर रहे हैं
• Cloudflare अपने पूरे API को 1,000 tokens से कम वाले एक single Code Mode MCP server के रूप में दे रहा है, लेकिन CLI commands, Workers bindings, SDKs, config files, Terraform, developer docs, Agent Skills जैसे और interfaces को भी कवर करने की जरूरत है
• मौजूदा Wrangler CLI में Cloudflare के कई प्रोडक्ट्स के CLI commands नहीं थे, और agents का CLI को पसंद करने का रुझान है

अगली पीढ़ी के Wrangler CLI का पुनर्निर्माण

• Wrangler CLI को पूरे Cloudflare के लिए CLI के रूप में फिर से बनाया जा रहा है, ताकि सभी प्रोडक्ट्स के commands उपलब्ध हों और infrastructure-as-code शैली में unified configuration संभव हो
• टेक्निकल प्रीव्यू को npx cf या npm install -g cf से install किया जा सकता है
• अभी केवल कुछ प्रोडक्ट्स समर्थित हैं, लेकिन अंदरूनी तौर पर पूरे Cloudflare API surface को support करने वाले version का परीक्षण चल रहा है
• हर प्रोडक्ट के commands को एजेंट्स और इंसानों दोनों के लिए ergonomic output के साथ review और tune किया जा रहा है
• आने वाले महीनों में इसे मौजूदा Wrangler की खूबियों के साथ जोड़ा जाएगा

TypeScript-आधारित schema और code generation pipeline

• पहले OpenAPI schema के आधार पर API SDK, Terraform provider, Code Mode MCP server को auto-generate किया जाता था
• CLI, Workers bindings, wrangler.jsonc configuration, Agent Skills, dashboard, docs updates अब भी manual process से किए जाते थे, जिससे errors अक्सर होते थे और scale करना मुश्किल था
• OpenAPI schema केवल REST API का वर्णन कर सकता है, इसलिए लोकल development और API requests को जोड़ने वाले interactive CLI commands, RPC-आधारित Workers bindings, Agent Skills और docs को व्यक्त नहीं किया जा सकता था
• Cloudflare ने इस बात पर ध्यान दिया कि भीतर TypeScript एक common language की तरह इस्तेमाल होती है, और Cap n' Web, Code Mode, Workers platform की RPC system आदि में TypeScript के जरिए API व्यक्त करना अधिक प्रभावी साबित हुआ
• नया TypeScript schema अपनाकर API, CLI commands और arguments, तथा interface generation के लिए जरूरी पूरा context परिभाषित किया जा रहा है
  • यह TypeScript types पर conventions, linting और guardrails लागू करने वाला रूप है
  • क्योंकि यह उनका अपना format है, इसलिए किसी भी जरूरी interface को लचीले ढंग से support करते हुए OpenAPI schema generation भी संभव है

agents और CLI में consistency तथा context engineering

• agents CLI में consistency की अपेक्षा करते हैं; यदि एक command info और दूसरा get इस्तेमाल करे, तो agent ऐसे command को भी call कर सकता है जो अस्तित्व में ही नहीं है
• सैकड़ों से हजारों engineers वाले बड़े संगठन में सिर्फ review से consistency बनाए रखना Swiss cheese model की तरह है, जिसमें छेद रह जाना लगभग तय है
• यदि consistency केवल CLI layer पर लागू की जाए, तो CLI, REST API और SDK के बीच naming mismatch की समस्या और बढ़ सकती है
• schema स्तर पर rules और guardrails लागू किए जा रहे हैं: हमेशा get (कभी info नहीं), हमेशा --force (कभी --skip-confirmations नहीं), हमेशा --json (कभी --format नहीं) जैसे नियम सभी commands में एकसमान support होंगे
• Wrangler CLI की एक खास संरचना है, जो लोकल simulated resources और remote resources दोनों पर काम करती है
  • D1 databases, R2 storage buckets, KV namespaces आदि लोकल और remote दोनों में supported हैं
  • agent को लग सकता है कि वह remote database बदल रहा है, जबकि वास्तव में वह लोकल database में record जोड़ रहा हो — ऐसी भ्रम की स्थिति संभव है
  • consistent defaults और लोकल/remote स्थिति को स्पष्ट बताने वाला output देकर agents को स्पष्ट guidance दी जा रही है

Local Explorer — लोकल में भी remote जैसा resource exploration

• Local Explorer को open beta में जारी किया गया है, और यह Wrangler CLI तथा Cloudflare Vite plugin दोनों में उपलब्ध है
• लोकल development के दौरान Worker द्वारा उपयोग किए जा रहे simulated resources को सीधे एक्सप्लोर किया जा सकता है: KV, R2, D1, Durable Objects, Workflows
• Cloudflare API और dashboard में जो समान कार्य किए जा सकते हैं, उन्हें पूरी तरह लोकल environment में उसी API structure के साथ किया जा सकता है
• Cloudflare कई वर्षों से पूर्ण लोकल development में निवेश कर रहा है, और D1 जैसी hosted serverless database भी अलग setup या tools के बिना bindings के जरिए पूरी तरह लोकल में चल सकती है
  • Miniflare (लोकल development platform emulator) production जैसी ही API देता है और लोकल SQLite database का उपयोग करता है
  • network access के बिना तेज़ी से tests लिखना और चलाना संभव है, और यह offline भी काम करता है
• पहले लोकल में कौन-सा डेटा सेव हुआ है यह देखने के लिए .wrangler/state directory को reverse engineer करना पड़ता था या third-party tools install करने पड़ते थे
• Wrangler CLI या Cloudflare Vite plugin से app चलाने पर Local Explorer खोलने का prompt दिखता है, और keyboard shortcut e से इसमें जाया जा सकता है
  • यह लोकल interface देता है, जहाँ वर्तमान Worker से जुड़े bindings और उनका डेटा देखा जा सकता है
• agents के साथ build करते समय agent डेटा को कैसे handle कर रहा है, यह समझने में यह उपयोगी है; साथ ही schema validation, test record seeding, DROP TABLE reset जैसी चीजें भी की जा सकती हैं
• यह केवल लोकल डेटा को संशोधित करने वाला Cloudflare API का mirror देता है, ताकि लोकल resources को remote जैसी ही API से access किया जा सके
  • क्योंकि लोकल और remote की API shape समान है, CLI में --local flag देने पर request लोकल mirror API की ओर switch हो जाती है और वही command काम करती है
• लोकल API /cdn-cgi/explorer/api path पर उपलब्ध है, और agents इस पते के जरिए OpenAPI spec खोजकर लोकल resources को manage कर सकते हैं

फीडबैक अनुरोध और आगे की योजना

• अगली पीढ़ी के CLI का टेक्निकल प्रीव्यू npx cf या npm install -g cf से उपलब्ध है
• Cloudflare वर्तमान टेक्निकल प्रीव्यू की capabilities के साथ-साथ, पूरे Cloudflare platform के CLI में लोग क्या चाहते हैं इस पर फीडबैक मांग रहा है
  • ऐसे काम जो dashboard में कई बार क्लिक करने पड़ते हैं, लेकिन एक लाइन के CLI command से करना चाहेंगे
  • wrangler.jsonc में configure करना चाहने वाले items (जैसे DNS records, cache rules)
  • वे बिंदु जहाँ agents अटक जाते हैं, और वे commands जिन्हें लोग CLI में देखना चाहते हैं
• Cloudflare Developers Discord पर फीडबैक लिया जा रहा है

[eoeoe]

उम्मीद है कि FTS टेबल सेट किए हुए D1 डेटाबेस को export करने की कोशिश करते समय आने वाली error को भी साथ में ठीक किया जाएगा।
wrangler इस्तेमाल करते समय यही सबसे ज़्यादा असुविधाजनक लगता है।

[GN⁺]

Hacker News की राय

• अच्छा होगा अगर Wrangler CLI लोकल development के दौरान पहले से ज़रूरी API token permissions दिखा दे
  इससे deploy से पहले साफ़ पता चल जाएगा कि कौन-सी permissions चाहिए, और cf permissions check जैसे command से missing या अनावश्यक permissions को जाँचा जा सके तो आदर्श होगा

  • पूरी तरह सहमत। अगर ChatGPT शुरुआत में permissions गलत सेट कर दे, तो आखिरकार घंटों docs खंगालने या token combinations आज़माने पड़ते हैं
  • ऐसा काम करने वाला doctor command हो तो सच में बहुत सुविधाजनक होगा। काश और services भी यह देतीं
  • पहले मुझसे typo की वजह से token गलत सेट हो गया था, ऐसी सुविधा होती तो बहुत मदद मिलती
  • इससे भी आगे बढ़कर, CLI में अपने-आप key generate करने की सुविधा भी अच्छी लगती है
  • आखिरकार असली बात API की discoverability बढ़ाने की है
    GraphQL, HATEOAS सिद्धांतों का अच्छी तरह पालन करता है, इसलिए LLM के लिए API को explore करना आसान होता है
    docs version mismatch से होने वाली समस्याओं की तुलना में, API का खुद अपनी capabilities उजागर करना कहीं बेहतर संरचना है

• पहले resource group स्तर पर access control जोड़ना चाहिए
  अभी सिर्फ zone(डोमेन) आधारित permissions हैं, इसलिए worker जैसे वे resources जो zone से जुड़े नहीं हैं, उन्हें कम permission होने पर भी code replace या delete किया जा सकता है
  GitHub Enterprise की तरह super account + sub account structure का support मिले तो और अच्छा होगा। उदाहरण: ACME Corp / ACME Corp (Prod)

  • क्या यह Cloudflare Organization feature वाले concept जैसा है?
  • भले domains share न किए जा सकें, superaccount + subaccount structure फिर भी बहुत उपयोगी लगेगा
  • मैं भी सहमत हूँ कि worker के zone-based न होने से इसकी उपयोगिता कम हो जाती है

• शानदार लेख है, इससे प्रेरणा मिली। लेकिन TypeSpec का ज़िक्र न होना थोड़ा हैरान करने वाला है
  यह TypeScript-style schema language है, जिसे मैं अक्सर इस तरह समझाता हूँ: “अगर OpenAPI सच में बहुत अच्छी तरह बनाया गया होता, तो शायद ऐसा लगता”
  शायद उन्हें लगा होगा कि in-house implementation ज़्यादा simple और flexible है। आजकल agent की वजह से BYO cost भी काफी घट गई है

  • मुझे TypeSpec बहुत पसंद है। OpenAPI लिखना इससे कहीं आसान हो जाता है
    लेकिन आजकल मैं aep.dev style APIs को पसंद करता हूँ। consistent patterns की वजह से aepcli को तुरंत इस्तेमाल करना या खुद बनाना आसान होता है
    Terraform भी अलग provider के बिना सीधे काम करता है
  • जानना चाहूँगा कि OpenAPI के किन हिस्सों को इसने बेहतर किया है

• इन दिनों AI agent-केंद्रित CLI-first design दिलचस्प लग रही है
  हमने भी developer tools बनाते समय पहले CLI और API बनाए, dashboard बाद में जोड़ा
  ऊपर बताया गया cf permissions check वाला idea खास तौर पर अच्छा लगा
  agent, CLI इस्तेमाल करने में तो अच्छे हैं लेकिन error cause diagnosis में कमज़ोर होते हैं।
  “scope X missing है, cf token add --scope X चलाएँ” जैसे स्पष्ट error messages कहीं अधिक महत्वपूर्ण हैं

• कहा जा रहा है कि npx cf से tech preview तुरंत आज़माया जा सकता है, तो कुछ बातें जाननी हैं
  क्या यह open source है, और क्या Node.js के बिना single binary form में देने की योजना है?
  क्या हाल में अधिग्रहित Bun जैसी किसी चीज़ का इस्तेमाल किया जा सकता है?

  • मुझे भी repository नहीं मिली, लेकिन npm package MIT license पर है और उसमें source maps शामिल हैं, इसलिए लगता है जल्द public होगा

• उम्मीद है long-lived tokens से बचा जाएगा।
  इसकी जगह CLI में short-lived, restricted tokens आसानी से बनाए जा सकें, उन्हें file के रूप में manage किया जा सके या auto-refresh किया जा सके तो बेहतर होगा
  एक और तरीका proxy mode भी हो सकता है, जहाँ access को सिर्फ किसी खास domain या bucket तक delegate किया जाए

  • GitLab की तरह SSH server के जरिए एक बार में short-lived PAT generate करने का तरीका मुझे पसंद है

• विडंबना यह है कि AI agent के दौर में हम फिर से CLI-केंद्रित development की ओर लौट रहे हैं
  हर बार Cloudflare cache साफ़ करते समय web UI में कई steps क्लिक करने पड़ते हैं, जबकि अच्छा हो कि बस OpenClaw agent को command दे दिया जाए

  • OpenClaw इस्तेमाल करने की कोई खास ज़रूरत नहीं। CLI command सीधे call कर सकते हैं। यही तो CLI का सार है

• Wrangler का authentication सिर्फ दो तरीकों से होता है: OAuth(पूर्ण permissions) और dashboard में manually बनाए गए static tokens
  लेकिन जब इंसानों और AI agents के लिए अलग permission boundaries चाहिए हों, तब यह उपयुक्त नहीं है
  अच्छा होगा अगर CLI से सीधे scoped, short-lived tokens बनाए जा सकें
  इस पर GitHub issue #13042 में भी चर्चा चल रही है।
  tokens को सिर्फ resource type नहीं, बल्कि resource ID और action स्तर तक भी granular होना चाहिए

• 1 अप्रैल को Cloudflare ने EmDash को x402 support के साथ पेश किया था, और अब लगता है कि वह CLI पर ध्यान केंद्रित कर रहा है
  ऐसा लगता है कि Cloudflare चुपचाप ऐसा developer ecosystem फिर से बना रहा है जिसमें इंसान नहीं बल्कि agents मुख्य उपयोगकर्ता हों

• उन्होंने कहा कि TypeScript schema से API, CLI commands, arguments और context define किए गए हैं,
  तो जिज्ञासा है कि वह tool या framework यहाँ पेश क्यों नहीं किया गया
  क्या यह ऊपर बताए गए TypeSpec जैसी मिलती-जुलती संरचना है?