- Cloudflare đang tái cấu trúc Wrangler thế hệ tiếp theo để cung cấp hơn 100 sản phẩm và khoảng 3.000 HTTP API thông qua một CLI hợp nhất (
cf), hiện đã có bản xem trước kỹ thuật dùng bằng npx cf
- Chỉ với schema OpenAPI hiện có thì không thể biểu đạt nhiều giao diện như lệnh CLI, Workers bindings hay Agent Skills, nên công ty đã đưa vào hệ thống schema mới dựa trên TypeScript
- Phù hợp với xu hướng agent trở thành bên tiêu thụ CLI chính, Cloudflare áp dụng bắt buộc ở cấp schema các quy tắc nhất quán của lệnh và guardrail như
get/--force/--json
- Cloudflare phát hành open beta tính năng Local Explorer, cho phép dễ dàng duyệt các tài nguyên mô phỏng khi phát triển cục bộ và trực tiếp kiểm tra dữ liệu local của KV, R2, D1
- Mục tiêu là mang đến trải nghiệm phát triển tối ưu cho cả agent lẫn lập trình viên bằng cách cung cấp toàn bộ API của Cloudflare theo cùng một hình thức API nhất quán trong CLI và môi trường local
Quy mô API của Cloudflare và sự chuyển dịch sang agent làm trung tâm
- Cloudflare có hơn 100 sản phẩm và khoảng 3.000 thao tác HTTP API
- Agent đang nổi lên như bên tiêu thụ API chính, và các lập trình viên đang dùng coding agent để xây dựng và triển khai ứng dụng, agent và nền tảng lên Cloudflare
- Cloudflare hiện cung cấp toàn bộ API của mình thông qua một máy chủ Code Mode MCP duy nhất dưới 1.000 token, nhưng vẫn cần bao phủ thêm nhiều giao diện như lệnh CLI, Workers bindings, SDK, tệp cấu hình, Terraform, tài liệu cho lập trình viên và Agent Skills
- CLI Wrangler hiện tại thiếu lệnh CLI cho nhiều sản phẩm Cloudflare, trong khi agent có xu hướng ưu tiên CLI
Tái cấu trúc Wrangler CLI thế hệ tiếp theo
- Cloudflare đang tái cấu trúc Wrangler CLI thành CLI cho toàn bộ Cloudflare, cung cấp lệnh cho mọi sản phẩm và cho phép cấu hình hợp nhất theo cách infrastructure-as-code
- Có thể dùng bản xem trước kỹ thuật qua
npx cf hoặc cài đặt bằng npm install -g cf
- Hiện mới chỉ hỗ trợ một số sản phẩm, nhưng nội bộ công ty đã thử nghiệm phiên bản hỗ trợ toàn bộ bề mặt API của Cloudflare
- Các lệnh theo từng sản phẩm đang được rà soát và tinh chỉnh để có đầu ra thuận tiện cho cả agent lẫn con người
- Trong vài tháng tới, Cloudflare dự kiến sẽ kết hợp nó với các điểm mạnh của Wrangler hiện tại
Schema dựa trên TypeScript và pipeline sinh mã
- Trước đây, Cloudflare tự động sinh API SDK, Terraform provider và máy chủ Code Mode MCP dựa trên schema OpenAPI
- Nhưng lệnh CLI, Workers bindings, cấu hình
wrangler.jsonc, Agent Skills, dashboard và cập nhật tài liệu vẫn là quy trình thủ công, dễ phát sinh lỗi và không thể mở rộng
- Schema OpenAPI chỉ mô tả được REST API, nên không thể biểu đạt lệnh CLI tương tác kết hợp phát triển local với yêu cầu API, Workers bindings dựa trên RPC, hay cả Agent Skills và tài liệu
- Từ việc TypeScript được dùng như ngôn ngữ chung trong nội bộ Cloudflare, công ty xác nhận rằng biểu đạt API bằng TypeScript hiệu quả hơn trong Cap n' Web, Code Mode và hệ thống RPC của nền tảng Workers
- Cloudflare đã đưa vào schema TypeScript mới để định nghĩa API, lệnh CLI và tham số, cùng mọi ngữ cảnh cần thiết cho việc sinh giao diện
- Đây là dạng áp dụng convention, linting và guardrail lên các kiểu TypeScript
- Vì là định dạng tự xây dựng, nó có thể linh hoạt hỗ trợ bất kỳ giao diện nào cần thiết, đồng thời vẫn có thể sinh ra schema OpenAPI
Tính nhất quán giữa agent và CLI, cùng kỹ thuật ngữ cảnh
- Agent kỳ vọng tính nhất quán của CLI; nếu một lệnh dùng
info còn lệnh khác dùng get, agent có thể gọi các lệnh không hề tồn tại
- Trong tổ chức quy mô lớn có hàng trăm đến hàng nghìn kỹ sư, việc chỉ dựa vào review để giữ tính nhất quán là điều khó tránh khỏi lỗ hổng, giống như mô hình pho mát Thụy Sĩ
- Nếu chỉ ép tính nhất quán ở tầng CLI, vấn đề khác biệt tên gọi giữa CLI, REST API và SDK lại càng trầm trọng hơn
- Cloudflare áp dụng quy tắc và guardrail ở cấp schema: luôn dùng
get (không bao giờ là info), luôn dùng --force (không bao giờ là --skip-confirmations), luôn dùng --json (không bao giờ là --format) để hỗ trợ nhất quán trên mọi lệnh
- Wrangler CLI có cấu trúc đặc biệt là hoạt động trên cả tài nguyên mô phỏng cục bộ lẫn tài nguyên từ xa
- Cơ sở dữ liệu D1, bucket lưu trữ R2, namespace KV đều hỗ trợ cả local và remote
- Có thể gây nhầm lẫn khi agent nghĩ rằng đang sửa đổi cơ sở dữ liệu từ xa nhưng thực tế lại thêm bản ghi vào cơ sở dữ liệu local
- Cloudflare cung cấp hướng dẫn rõ ràng cho agent bằng giá trị mặc định nhất quán và đầu ra thể hiện rõ đang là local hay remote
Local Explorer — khám phá tài nguyên local giống hệt remote
- Cloudflare phát hành open beta Local Explorer, dùng được trong cả Wrangler CLI và plugin Cloudflare Vite
- Khi phát triển local, có thể trực tiếp duyệt các tài nguyên mô phỏng mà Worker đang dùng: KV, R2, D1, Durable Objects, Workflows
- Có thể thực hiện ngay trong môi trường local hoàn toàn những thao tác giống như trên API và dashboard của Cloudflare, với cùng một cấu trúc API
- Cloudflare đã đầu tư nhiều năm vào phát triển local hoàn chỉnh, và ngay cả cơ sở dữ liệu serverless được lưu trữ như D1 cũng có thể chạy hoàn toàn local thông qua binding mà không cần cấu hình hay công cụ riêng
- Miniflare (trình giả lập nền tảng phát triển local) cung cấp cùng API như production và dùng cơ sở dữ liệu SQLite local
- Có thể viết và chạy test nhanh mà không cần truy cập mạng, và vẫn hoạt động khi offline
- Trước đây, để kiểm tra dữ liệu nào đã được lưu local, người dùng phải reverse engineer thư mục
.wrangler/state hoặc cài công cụ bên thứ ba
- Khi chạy ứng dụng bằng Wrangler CLI hoặc plugin Cloudflare Vite, lời nhắc mở Local Explorer sẽ xuất hiện và có thể truy cập bằng phím tắt
e
- Nó cung cấp giao diện local để xem các binding đang kết nối với Worker hiện tại và dữ liệu tương ứng
- Khi build bằng agent, tính năng này hữu ích để nắm được agent đang xử lý dữ liệu như thế nào; đồng thời có thể kiểm tra schema, seed bản ghi thử nghiệm và đặt lại bằng
DROP TABLE
- Local Explorer cung cấp bản phản chiếu của Cloudflare API chỉ sửa dữ liệu local, cho phép truy cập tài nguyên local bằng cùng API như remote
- Vì hình thức API giữa local và remote là giống nhau, chỉ cần truyền cờ
--local trong CLI thì yêu cầu sẽ được chuyển sang local mirror API và tiếp tục hoạt động như cũ
- Có thể truy cập local API tại đường dẫn
/cdn-cgi/explorer/api, và agent có thể thông qua địa chỉ này để phát hiện OpenAPI spec và quản lý tài nguyên local
Yêu cầu phản hồi và kế hoạch tiếp theo
- Có thể dùng bản xem trước kỹ thuật của CLI thế hệ tiếp theo qua
npx cf hoặc npm install -g cf
- Cloudflare đang kêu gọi phản hồi không chỉ về các tính năng hiện có trong bản xem trước kỹ thuật, mà còn về những gì người dùng muốn ở một CLI cho toàn bộ nền tảng Cloudflare
- Những tác vụ hiện phải bấm nhiều lần trong dashboard nhưng người dùng muốn thực hiện bằng một lệnh CLI một dòng
- Những mục muốn cấu hình trong
wrangler.jsonc (ví dụ: bản ghi DNS, quy tắc cache)
- Những điểm agent bị mắc kẹt và các lệnh mà người dùng muốn CLI cung cấp
- Cloudflare đang tiếp nhận phản hồi trên Cloudflare Developers Discord
2 bình luận
Mong họ cũng sửa luôn lỗi phát sinh khi thử xuất cơ sở dữ liệu D1 đã thiết lập bảng FTS.
Đó là điều bất tiện nhất khi dùng
wrangler.Ý kiến trên Hacker News
Sẽ rất tốt nếu Wrangler CLI hiển thị trước quyền API token cần thiết trong lúc phát triển cục bộ
Nhờ đó có thể biết rõ cần quyền gì trước khi triển khai, và sẽ lý tưởng hơn nữa nếu có lệnh như
cf permissions checkđể kiểm tra các quyền còn thiếu hoặc không cần thiếtGraphQL tuân theo nguyên tắc HATEOAS khá tốt nên thuận lợi cho LLM khám phá API
Tôi cho rằng một cấu trúc để API tự bộc lộ chức năng của nó sẽ tốt hơn nhiều so với các vấn đề phát sinh vì phiên bản tài liệu không khớp
Tôi muốn họ bổ sung kiểm soát quyền hạn theo đơn vị resource group trước
Hiện tại chỉ có quyền theo zone (domain), nên với các tài nguyên như worker không thuộc zone thì ngay cả với quyền thấp vẫn có thể bị thay mã hoặc xóa
Sẽ còn tốt hơn nếu hỗ trợ cấu trúc super account + sub account như GitHub Enterprise. Ví dụ: ACME Corp / ACME Corp (Prod)
Bài viết rất hay và truyền cảm hứng. Tuy vậy tôi khá ngạc nhiên vì không thấy nhắc đến TypeSpec
Đây là một ngôn ngữ schema kiểu TypeScript, thường được mô tả là “nếu OpenAPI thực sự được thiết kế tốt thì sẽ trông như thế này”
Có lẽ họ cho rằng tự triển khai sẽ đơn giản và linh hoạt hơn. Dạo gần đây nhờ agent mà chi phí BYO cũng giảm đi nhiều
Nhưng dạo này tôi lại thích API theo phong cách aep.dev. Nhờ các mẫu nhất quán nên rất dễ dùng ngay aepcli hoặc tự làm một cái
Terraform cũng hoạt động ngay mà không cần provider riêng
Gần đây hướng thiết kế CLI-first xoay quanh AI agent rất thú vị
Khi chúng tôi làm công cụ cho nhà phát triển, chúng tôi cũng làm CLI và API trước, rồi mới gắn dashboard sau
Ý tưởng
cf permissions checkđược nhắc ở trên đặc biệt hayagent dùng CLI khá tốt nhưng lại kém trong chẩn đoán nguyên nhân lỗi.
Các thông báo lỗi rõ ràng như “thiếu scope X, hãy chạy cf token add --scope X” quan trọng hơn nhiều
Họ nói có thể dùng thử technical preview ngay bằng
npx cf, nhưng tôi có vài điều muốn hỏiNó có phải mã nguồn mở không, và có kế hoạch cung cấp dưới dạng binary đơn không cần Node.js hay không.
Liệu có thể tận dụng thứ như Bun mà họ mới mua lại gần đây không?
Tôi mong họ tránh dùng token dài hạn.
Thay vào đó sẽ tốt hơn nếu CLI có thể dễ dàng tạo token ngắn hạn với phạm vi hạn chế, quản lý qua file hoặc tự động gia hạn
Một hướng khác là có chế độ proxy để ủy quyền quyền truy cập chỉ cho một domain hay bucket cụ thể
Trớ trêu là khi kỷ nguyên AI agent đến, chúng ta lại quay về phát triển xoay quanh CLI
Mỗi lần xóa cache Cloudflare tôi đều phải bấm qua nhiều bước trong web UI, trong khi giá như chỉ cần ra lệnh cho OpenClaw agent là xong
Cách xác thực của Wrangler chỉ có hai kiểu: OAuth (toàn quyền) và token tĩnh tạo thủ công từ dashboard
Nhưng như vậy không phù hợp khi con người và AI agent cần các ranh giới quyền hạn khác nhau
Sẽ rất tốt nếu có thể tạo trực tiếp token scoped, short-lived từ CLI
Vấn đề này cũng đang được bàn trong GitHub issue #13042.
Token không chỉ nên được chia nhỏ theo loại tài nguyên mà còn phải theo resource ID và từng hành động
Vào ngày 1 tháng 4, Cloudflare đã công bố EmDash cùng hỗ trợ x402, còn bây giờ có vẻ họ đang tập trung vào CLI
Có cảm giác Cloudflare đang âm thầm tái xây dựng hệ sinh thái nhà phát triển với agent phi con người là người dùng chính
Họ nói đã định nghĩa API, lệnh CLI, tham số và context bằng schema TypeScript,
nên tôi tò mò tại sao công cụ hay framework đó lại không được giới thiệu ở đây
Không rõ liệu nó có phải là cấu trúc tương tự như TypeSpec được nhắc ở trên hay không