Workflow SDK và Nitro v3: backend bền vững đi vào runtime của ứng dụng

Tech

Các luồng backend cần tạm dừng, tiếp tục hoặc retry thường kéo theo queue, worker, bảng trạng thái và monitoring. Workflow SDK trên Nitro v3 đưa mô hình đó gần hơn với code ứng dụng.

Sơ đồ ứng dụng Nitro v3 với API route, Workflow SDK, use workflow, use step, Nitro storage, retry và observability
Tích hợp Nitro đưa các step workflow đến gần runtime ứng dụng thay vì một worker bundle riêng.

Điều gì đã xảy ra

Ngày 13 tháng 6 năm 2026, Vercel công bố beta tích hợp native Workflow SDK với Nitro v3. Các step chạy trong cùng bundled runtime với ứng dụng, route workflow là một phần của Nitro build, và API server-side như useStorage có thể dùng trực tiếp trong hàm "use step".

Vì sao quan trọng

Với đội Nuxt/Nitro, điều này thay đổi nơi đặt các tác vụ dài hạn. API route có thể khởi động workflow, "use workflow" điều phối, và step xử lý side effect có retry và khả năng quan sát.

Tín hiệu cộng đồng

Điểm cần cẩn trọng là vận hành: side effect phải idempotent, lỗi cần phân loại fatal/retryable, run đang chạy gắn với deployment ban đầu, và CLI/Web UI phải cho thấy runId, stepId, retry count và lỗi.

Tác động tới phát triển và vận hành

The safest adoption path is incremental. Start with visible, low-blast-radius flows such as onboarding emails, report generation, delayed notifications, or approval-based AI agent work. Move payments, inventory, account deletion, and compliance notifications only after rollback steps and runbooks are boring.

Checklist thực tế

• Classify candidates into work that should finish inside a request, work that needs a queue, and work that needs human intervention.

• Keep the input and output shapes of `"use workflow"` and `"use step"` functions backward-compatible across deployments.

• Attach stable idempotency keys, preferably based on stepId, to payments, emails, external writes, and queue publishes.

• Separate non-retryable validation failures with FatalError and handle rate limits or transient outages with RetryableError plus retryAfter.

• Document how in-flight runs stay pinned to deployments and how affected runs are cancelled or rerun after a fix.

• When steps use Nitro useStorage, server APIs, or route handlers directly, test local and production backend differences.

• Verify that runId, stepId, input class, retry count, failure code, latency, and cost are visible in the CLI or Web UI.

Rủi ro và phản biện

This integration is beta, and it is not a reason to rewrite every job. Short cache refreshes and simple webhook forwarding may remain simpler as request/response code or a small queue. The same-runtime convenience should not blur the line between retryable code and code that must never run twice.

Nguồn

다른 글