Cloudflare กำลังสร้าง CLI แบบรวมศูนย์ที่ครอบคลุมทุกผลิตภัณฑ์

• Cloudflare กำลังสร้าง Wrangler รุ่นถัดไปขึ้นใหม่เพื่อให้บริการ CLI แบบรวมศูนย์ (cf) สำหรับผลิตภัณฑ์มากกว่า 100 รายการและ HTTP API ราว 3,000 รายการ โดยขณะนี้สามารถทดลองใช้พรีวิวทางเทคนิคได้ผ่าน npx cf
• เนื่องจาก OpenAPI schema แบบเดิมไม่สามารถอธิบายอินเทอร์เฟซที่หลากหลาย เช่น คำสั่ง CLI, Workers bindings และ Agent Skills ได้ จึงได้เปิดตัว ระบบสคีมาใหม่ที่อิงกับ TypeScript
• เพื่อตอบรับแนวโน้มที่เอเจนต์ใช้ CLI เป็นผู้ใช้หลัก จึงมีการบังคับใช้ กฎความสม่ำเสมอของคำสั่งและ guardrails ในระดับสคีมา เช่น get / --force / --json
• เปิดตัวฟีเจอร์ Local Explorer ในสถานะโอเพนเบตา เพื่อให้สำรวจทรัพยากรจำลองระหว่างการพัฒนาแบบโลคัลได้ง่าย และตรวจสอบข้อมูลโลคัลของ KV, R2, D1 ฯลฯ ได้โดยตรง
• เป้าหมายคือการมอบ รูปแบบ API เดียวกันอย่างสม่ำเสมอ ให้กับทั้ง CLI และสภาพแวดล้อมโลคัลสำหรับ API ทั้งหมดของ Cloudflare เพื่อสร้างประสบการณ์การพัฒนาที่เหมาะสมทั้งสำหรับเอเจนต์และนักพัฒนา

---

ขนาดของ API ของ Cloudflare และการเปลี่ยนผ่านสู่แนวทางที่มีเอเจนต์เป็นศูนย์กลาง

• Cloudflare มี ผลิตภัณฑ์มากกว่า 100 รายการ และมี HTTP API operations ประมาณ 3,000 รายการ
• เอเจนต์กำลังกลายเป็นผู้ใช้หลักของ API และนักพัฒนาก็กำลังสร้างและดีพลอยแอปพลิเคชัน เอเจนต์ และแพลตฟอร์มบน Cloudflare ผ่าน coding agents
• ปัจจุบัน Cloudflare ให้บริการ API ทั้งหมดผ่าน Code Mode MCP server เดียวที่ใช้โทเคนน้อยกว่า 1,000 โทเคน แต่ยังต้องรองรับอินเทอร์เฟซอื่นเพิ่มเติม เช่น คำสั่ง CLI, Workers bindings, SDK, ไฟล์ตั้งค่า, Terraform, เอกสารสำหรับนักพัฒนา และ Agent Skills
• Wrangler CLI แบบเดิมยังขาดคำสั่ง CLI สำหรับผลิตภัณฑ์ Cloudflare จำนวนมาก และ เอเจนต์มีแนวโน้มจะชอบใช้ CLI

การสร้าง Wrangler CLI รุ่นถัดไปขึ้นใหม่

• กำลังสร้าง Wrangler CLI ขึ้นใหม่ให้เป็น CLI สำหรับ Cloudflare ทั้งหมด เพื่อให้มีคำสั่งสำหรับทุกผลิตภัณฑ์ และรองรับการตั้งค่าแบบรวมศูนย์ในแนวทาง infrastructure-as-code
• ติดตั้งพรีวิวทางเทคนิคได้ด้วย npx cf หรือ npm install -g cf
• ตอนนี้รองรับเพียงบางผลิตภัณฑ์ แต่ภายในกำลังทดสอบ เวอร์ชันที่รองรับพื้นผิว API ทั้งหมดของ Cloudflare
• กำลังตรวจทานและปรับแต่งคำสั่งของแต่ละผลิตภัณฑ์ให้มี ผลลัพธ์ที่ใช้งานได้สะดวกตามหลักสรีรศาสตร์ ทั้งสำหรับเอเจนต์และมนุษย์
• ในอีกไม่กี่เดือนข้างหน้า มีแผนจะผสานเข้ากับจุดแข็งของ Wrangler เดิม

สคีมาที่อิงกับ TypeScript และไปป์ไลน์การสร้างโค้ด

• ก่อนหน้านี้ใช้ OpenAPI schema เป็นฐานในการสร้าง API SDK, Terraform provider และ Code Mode MCP server แบบอัตโนมัติ
• แต่การอัปเดต CLI, Workers bindings, การตั้งค่า wrangler.jsonc, Agent Skills, แดชบอร์ด และเอกสาร ยังเป็น กระบวนการแบบแมนนวล ซึ่งเกิดข้อผิดพลาดได้บ่อยและขยายต่อได้ยาก
• OpenAPI schema สามารถอธิบายได้เฉพาะ REST API จึงไม่สามารถอธิบาย คำสั่ง CLI แบบอินเทอร์แอกทีฟ ที่ผสานการพัฒนาโลคัลเข้ากับคำขอ API, Workers bindings แบบอิง RPC, รวมถึง Agent Skills และเอกสารได้
• จากการที่ภายใน Cloudflare ใช้ TypeScript เป็นภาษากลาง จึงพบว่าการอธิบาย API ด้วย TypeScript มีประสิทธิภาพมากกว่าในระบบอย่าง Cap n' Web, Code Mode และ ระบบ RPC ของแพลตฟอร์ม Workers
• จึงนำ TypeScript schema แบบใหม่มาใช้ เพื่อกำหนด API, คำสั่ง CLI, อาร์กิวเมนต์ และบริบททั้งหมดที่จำเป็นต่อการสร้างอินเทอร์เฟซ
  • เป็นรูปแบบที่นำ convention, linting และ guardrails มาใช้กับ TypeScript types
  • เนื่องจากเป็นฟอร์แมตของตนเอง จึงรองรับอินเทอร์เฟซที่ต้องการได้อย่างยืดหยุ่น พร้อมทั้งยังสามารถสร้าง OpenAPI schema ได้

ความสม่ำเสมอของเอเจนต์และ CLI และ context engineering

• เอเจนต์คาดหวังให้ CLI มี ความสม่ำเสมอ หากคำสั่งหนึ่งใช้ info แต่อีกคำสั่งใช้ get ก็อาจทำให้เอเจนต์เรียกคำสั่งที่ไม่มีอยู่จริง
• ในองค์กรขนาดใหญ่ที่มีวิศวกรหลักร้อยถึงหลักพัน การรักษาความสม่ำเสมอด้วยการรีวิวเพียงอย่างเดียว ย่อมมีช่องโหว่แบบ Swiss cheese model อย่างหลีกเลี่ยงไม่ได้
• หากบังคับใช้ความสม่ำเสมอเฉพาะในชั้น CLI ก็อาจยิ่งทำให้ปัญหาความแตกต่างด้านการตั้งชื่อระหว่าง CLI, REST API และ SDK รุนแรงขึ้น
• จึงมีการใช้ กฎและ guardrails ในระดับสคีมา: ใช้ get เสมอ (ไม่ใช้ info), ใช้ --force เสมอ (ไม่ใช้ --skip-confirmations), ใช้ --json เสมอ (ไม่ใช้ --format) เพื่อให้รองรับอย่างสม่ำเสมอในทุกคำสั่ง
• Wrangler CLI มีโครงสร้างพิเศษที่ทำงานได้ทั้งกับ ทรัพยากรจำลองแบบโลคัลและทรัพยากรระยะไกล
  • เช่น D1 databases, R2 storage buckets และ KV namespaces รองรับทั้งแบบโลคัลและระยะไกล
  • อาจเกิดความสับสนได้เมื่อเอเจนต์คิดว่ากำลังแก้ไขฐานข้อมูลระยะไกล แต่จริง ๆ แล้วกำลังเพิ่มเรคคอร์ดในฐานข้อมูลโลคัล
  • จึงให้แนวทางที่ชัดเจนแก่เอเจนต์ด้วย ค่าเริ่มต้นที่สม่ำเสมอ และเอาต์พุตที่ระบุอย่างชัดเจนว่าเป็นโลคัลหรือระยะไกล

Local Explorer — สำรวจทรัพยากรแบบเดียวกับรีโมตได้จากโลคัล

• เปิดตัว Local Explorer ในสถานะโอเพนเบตา และใช้งานได้ทั้งใน Wrangler CLI และ Cloudflare Vite plugin
• ระหว่างการพัฒนาแบบโลคัล สามารถสำรวจทรัพยากรจำลองที่ Worker ใช้งานได้โดยตรง เช่น KV, R2, D1, Durable Objects, Workflows
• สามารถทำงานแบบเดียวกับที่ทำได้ผ่าน Cloudflare API และแดชบอร์ด ได้ใน สภาพแวดล้อมโลคัลทั้งหมด ด้วยโครงสร้าง API แบบเดียวกัน
• Cloudflare ลงทุนกับ การพัฒนาแบบโลคัลอย่างสมบูรณ์ มาหลายปี และแม้แต่ฐานข้อมูล serverless แบบโฮสต์อย่าง D1 ก็สามารถรันแบบโลคัลได้เต็มรูปแบบผ่าน bindings โดยไม่ต้องมีการตั้งค่าหรือเครื่องมือเพิ่มเติม
  • Miniflare (emulator ของแพลตฟอร์มพัฒนาแบบโลคัล) ให้ API แบบเดียวกับโปรดักชัน และใช้ฐานข้อมูล SQLite แบบโลคัล
  • สามารถเขียนและรันทดสอบได้อย่างรวดเร็วโดยไม่ต้องเข้าถึงเครือข่าย และยังทำงานแบบออฟไลน์ได้
• ก่อนหน้านี้ หากต้องการตรวจสอบว่ามีข้อมูลอะไรถูกเก็บไว้ในโลคัล ต้อง ย้อนวิเคราะห์ ไดเรกทอรี .wrangler/state หรือติดตั้งเครื่องมือจากภายนอก
• เมื่อรันแอปด้วย Wrangler CLI หรือ Cloudflare Vite plugin จะมีพรอมป์ต์ให้เปิด Local Explorer และเข้าถึงได้ด้วยคีย์ลัด e
  • มี อินเทอร์เฟซแบบโลคัล ให้ดู bindings ที่เชื่อมต่อกับ Worker ปัจจุบันและข้อมูลของมันได้
• มีประโยชน์ระหว่างการสร้างด้วยเอเจนต์เพื่อดูว่าเอเจนต์จัดการข้อมูลอย่างไร และสามารถทำ schema validation, seed test records และรีเซ็ตด้วย DROP TABLE ได้
• มี mirror ของ Cloudflare API ที่แก้ไขเฉพาะข้อมูลโลคัล ทำให้เข้าถึงทรัพยากรโลคัลได้ผ่าน API แบบเดียวกับรีโมต
  • เนื่องจาก API ของโลคัลและรีโมตมีรูปแบบเดียวกัน เมื่อส่งแฟล็ก --local ใน CLI คำขอจะถูกสลับไปยัง local mirror API และทำงานต่อได้ทันที
• Local API เข้าถึงได้ผ่านพาธ /cdn-cgi/explorer/api ทำให้เอเจนต์สามารถ ค้นพบ OpenAPI spec จากที่อยู่นี้และจัดการทรัพยากรโลคัลได้

การขอฟีดแบ็กและแผนต่อไป

• สามารถใช้งานพรีวิวทางเทคนิคของ CLI รุ่นถัดไปได้ด้วย npx cf หรือ npm install -g cf
• Cloudflare ขอ ฟีดแบ็ก ไม่เพียงเกี่ยวกับฟีเจอร์ในพรีวิวทางเทคนิคปัจจุบัน แต่รวมถึงสิ่งที่ผู้ใช้ต้องการจาก CLI สำหรับทั้งแพลตฟอร์ม Cloudflare
  • งานที่ต้องคลิกหลายครั้งบนแดชบอร์ด แต่ผู้ใช้ต้องการทำด้วย คำสั่ง CLI บรรทัดเดียว
  • รายการที่อยากตั้งค่าใน wrangler.jsonc (เช่น DNS records, cache rules)
  • จุดที่เอเจนต์ติดขัดและคำสั่งที่อยากให้มีใน CLI
• เปิดรับฟีดแบ็กผ่าน Cloudflare Developers Discord

[eoeoe]

หวังว่าจะแก้ข้อผิดพลาดที่เกิดขึ้นตอนพยายาม export ฐานข้อมูล D1 ที่ตั้งค่า FTS table ไว้ด้วยนะครับ
ตอนใช้ wrangler นี่ไม่สะดวกที่สุดเลย

[GN⁺]

ความคิดเห็นจาก Hacker News

• น่าจะดีถ้า Wrangler CLI แสดง สิทธิ์ของ API token ที่ต้องใช้ล่วงหน้าระหว่างพัฒนาแบบโลคัล
  จะได้รู้ชัดเจนว่าต้องใช้สิทธิ์อะไรบ้างก่อน deploy และถ้ามีคำสั่งอย่าง cf permissions check ที่ตรวจสอบสิทธิ์ที่ขาดหรือเกินความจำเป็นได้ก็คงเหมาะมาก

  • เห็นด้วยสุด ๆ ถ้า ChatGPT ตั้งค่าสิทธิ์ผิดตั้งแต่แรก สุดท้ายก็ต้องเสียเวลาหลายชั่วโมงไล่อ่านเอกสารหรือคอยลอง ชุด token ไปเรื่อย ๆ
  • ถ้ามี คำสั่ง doctor ที่ทำเรื่องนี้ได้จะสะดวกมาก อยากให้มีบริการอื่นทำแบบนี้มากขึ้น
  • เมื่อก่อนเคยตั้งค่า token ผิดเพราะพิมพ์ผิด ถ้ามีฟีเจอร์แบบนี้คงช่วยได้มาก
  • ถ้าไปได้ไกลกว่านั้น CLI ที่ สร้างคีย์ให้อัตโนมัติ ได้ก็น่าจะดี
  • สุดท้ายแก่นสำคัญคือการเพิ่ม discoverability ของ API
    GraphQL ปฏิบัติตามหลัก HATEOAS ได้ดี เลยเหมาะกับการให้ LLM สำรวจ API
    แทนที่จะเจอปัญหาเพราะเวอร์ชันเอกสารไม่ตรงกัน ผมมองว่าโครงสร้างที่ทำให้ API เปิดเผยความสามารถของตัวเองได้ดีกว่าน่าจะดีกว่ามาก

• อยากให้เพิ่ม การควบคุมสิทธิ์ ระดับ resource group ก่อน
  ตอนนี้มีแค่สิทธิ์แบบอิง zone (โดเมน) เท่านั้น ทำให้ resource อย่าง worker ที่ไม่ได้อยู่ใน zone ยังอาจถูกแทนที่โค้ดหรือลบได้แม้มีสิทธิ์ต่ำ
  ถ้ารองรับ โครงสร้าง super account + sub account แบบ GitHub Enterprise ได้ก็น่าจะดียิ่งขึ้น เช่น: ACME Corp / ACME Corp (Prod)

  • สงสัยว่านี่คือแนวคิดเดียวกับฟีเจอร์ Cloudflare Organization หรือเปล่า
  • ต่อให้แชร์โดเมนกันไม่ได้ โครงสร้าง superaccount + subaccount ก็ดูมีประโยชน์มากจริง ๆ
  • เห็นด้วยว่าเพราะ worker ไม่ได้อิงกับ zone จึง ใช้งานได้ไม่ค่อยคุ้มค่า

• เป็นบทความที่ดีมากและให้แรงบันดาลใจ แต่แปลกใจที่ไม่ได้พูดถึง TypeSpec
  มันเป็นภาษา schema สไตล์ TypeScript ที่มักถูกอธิบายว่า “ถ้า OpenAPI ถูกออกแบบมาได้ดีจริง ๆ ก็คงจะออกมาประมาณนี้”
  คงมองว่าทำเองจะเรียบง่ายและยืดหยุ่นกว่า ตอนนี้ ต้นทุน BYO ก็ลดลงมากเพราะ agent

  • ชอบ TypeSpec มาก ทำให้เขียน OpenAPI ง่ายขึ้นเยอะ
    แต่ช่วงนี้ชอบ API สไตล์ aep.dev มากกว่า เพราะมีแพตเทิร์นที่สม่ำเสมอเลยใช้ aepcli ได้ทันทีหรือจะเขียนเองก็ง่าย
    Terraform ก็ทำงานได้เลยโดยไม่ต้องมี provider แยก
  • อยากรู้ว่ามัน ปรับปรุง ส่วนไหนของ OpenAPI บ้าง

• ช่วงนี้แนวคิด ออกแบบแบบ CLI-first โดยมี AI agent เป็นศูนย์กลาง น่าสนใจมาก
  ตอนเราทำเครื่องมือสำหรับนักพัฒนา เราก็สร้าง CLI กับ API ก่อน แล้วค่อยทำ dashboard ทีหลัง
  ไอเดีย cf permissions check ที่พูดถึงข้างบนนี่ดีมากเป็นพิเศษ
  agent ใช้ CLI ได้เก่ง แต่ วิเคราะห์สาเหตุของ error ไม่ค่อยเก่ง
  ข้อความ error ที่ชัดเจนอย่าง “ไม่มี scope X ให้รัน cf token add --scope X” สำคัญกว่ามาก

• เห็นว่าลอง technical preview ได้เลยด้วย npx cf แต่มีอยู่ไม่กี่อย่างที่สงสัย
  เป็นโอเพนซอร์สไหม และมีแผนจะออกเป็น ไบนารีเดี่ยว โดยไม่ต้องพึ่ง Node.js หรือไม่
  หรืออาจใช้ของอย่าง Bun ที่เพิ่งเข้าซื้อไปไม่นานได้ไหม?

  • ผมก็หา repo ไม่เจอเหมือนกัน แต่แพ็กเกจ npm ใช้ไลเซนส์ MIT และมี source map รวมมาด้วย เลยคิดว่าน่าจะเปิดซอร์สเร็ว ๆ นี้

• อยากให้หลีกเลี่ยง token ระยะยาว
  แทนที่จะเป็นแบบนั้น ถ้าใน CLI ทำ token อายุสั้นที่มีข้อจำกัด ได้ง่าย และจัดการผ่านไฟล์หรือรีเฟรชอัตโนมัติได้ก็น่าจะดี
  อีกทางหนึ่งคือมี โหมด proxy ที่มอบสิทธิ์เข้าถึงเฉพาะบางโดเมนหรือบาง bucket ได้ก็ฟังดูไม่เลว

  • ชอบวิธีของ GitLab ที่สร้าง PAT อายุสั้น ผ่านเซิร์ฟเวอร์ SSH ได้ในครั้งเดียว

• น่าแปลกที่พอยุคของ AI agent มาถึง เรากลับกำลังย้อนกลับไปสู่ การพัฒนาแบบยึด CLI เป็นศูนย์กลาง อีกครั้ง
  ทุกครั้งที่ต้องล้างแคช Cloudflare ต้องคลิกหลายขั้นตอนบนเว็บ UI ถ้าสั่ง OpenClaw agent ไปตรง ๆ ได้เลยก็คงดี

  • ไม่จำเป็นต้องใช้ OpenClaw ก็ได้ เรียกคำสั่ง CLI ตรง ๆ ก็พอ นั่นแหละคือแก่นของ CLI

• วิธี auth ของ Wrangler มีแค่ OAuth (สิทธิ์ทั้งหมด) กับ token แบบคงที่ ที่สร้างเองจาก dashboard เท่านั้น
  แต่มันไม่เหมาะในกรณีที่คนกับ AI agent ควรมีขอบเขตสิทธิ์ต่างกัน
  ถ้าสร้าง token แบบ scoped และอายุสั้น ได้จากใน CLI โดยตรงก็น่าจะดีมาก
  ตอนนี้กำลังคุยกันอยู่ใน GitHub issue #13042
  token ควรถูกแยกละเอียดได้ไม่ใช่แค่ตามประเภท resource แต่รวมถึง resource ID และระดับ action ด้วย

• วันที่ 1 เมษายน Cloudflare เปิดตัว EmDash พร้อมการรองรับ x402 แต่ตอนนี้ดูเหมือนจะโฟกัสที่ CLI มากกว่า
  เหมือน Cloudflare กำลังค่อย ๆ สร้างระบบนิเวศนักพัฒนาใหม่ โดยมอง agent ที่ไม่ใช่มนุษย์เป็นผู้ใช้หลัก

• เห็นว่ากำหนด API, คำสั่ง CLI, argument และ context ด้วย TypeScript schema
  เลยสงสัยว่าทำไม เครื่องมือหรือเฟรมเวิร์ก นั้นถึงไม่ได้ถูกแนะนำไว้ตรงนี้
  ไม่รู้ว่ามันเป็น โครงสร้างคล้ายกัน กับ TypeSpec ที่พูดถึงข้างบนหรือไม่