Workflow SDK และ Nitro v3: backend แบบ durable กำลังย้ายเข้า runtime ของแอป

Tech

งาน backend ที่ต้องรอ ทำซ้ำ หรือกลับมาทำต่อ มักต้องพึ่ง queue, worker, state table และ monitoring. Workflow SDK บน Nitro v3 ทำให้รูปแบบนี้ใกล้กับโค้ดแอปมากขึ้น.

ไดอะแกรมแอป Nitro v3 ที่ API route เริ่ม Workflow SDK แล้วเชื่อมกับ use workflow, use step, Nitro storage, retry และ observability
การรวมกับ Nitro ทำให้ step ของ workflow อยู่ใกล้ runtime ของแอปมากกว่า worker แยกต่างหาก

เกิดอะไรขึ้น

เมื่อ 13 มิถุนายน 2026 Vercel ประกาศ beta ของ Workflow SDK ที่ผสานกับ Nitro v3 แบบ native. step ทำงานใน bundled runtime เดียวกับแอป, workflow route เป็นส่วนหนึ่งของ Nitro build และ API ฝั่ง server อย่าง useStorage ใช้ได้ในฟังก์ชัน "use step".

ทำไมจึงสำคัญ

สำหรับทีม Nuxt/Nitro นี่ทำให้ long-running backend อยู่ใกล้โค้ดแอปมากขึ้น ไม่ว่าจะเป็น onboarding, report generation, delayed notification หรือ agent ที่รอ human approval.

สัญญาณจากชุมชน

แต่ต้องออกแบบด้าน operation ให้ชัด: retry policy, idempotency key สำหรับ side effect, version boundary ของ deployment และเครื่องมือ inspect run ผ่าน CLI หรือ Web UI.

ผลต่อการพัฒนาและปฏิบัติการ

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.

เช็กลิสต์เชิงปฏิบัติ

• 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.

ความเสี่ยงและข้อโต้แย้ง

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.

แหล่งข้อมูล

다른 글