Workflow SDKとNitro v3: durable backendがアプリ実行環境へ近づく

Tech
閲覧数 156

1回のHTTP requestに収まらない処理には、queue、retry、状態管理、監視が必要になる。Workflow SDKのNitro v3統合は、そのdurable executionをNitro/Nuxtのコードに近づける。

Nitro v3アプリ内でAPI routeがWorkflow SDKを開始し、use workflow、use step、Nitro storage、retry、observabilityにつながる図
Nitro v3統合は、長時間実行タスクを別workerではなくアプリruntimeに近い場所で扱わせる。

何が起きたか

Vercelは2026年6月13日、Workflow SDKのNitro v3ネイティブ統合がbetaになったと発表した。stepはアプリと同じbundled runtimeで実行され、workflow routeはNitro buildの一部になり、useStorageのようなserver-side APIを"use step"内で直接使える。

なぜ重要か

Nuxt/Nitroチームにとって、これは長時間実行処理の置き場所を変える。API routeがworkflowを開始し、"use workflow"が orchestration を担い、stepがretry可能なside effectを実行する。別workerを作る前に、アプリruntime内でdurable backendを設計できる。

コミュニティのシグナル

ただし便利さは責任も増やす。外部API書き込みにはidempotency keyが必要で、FatalErrorとRetryableErrorを使い分け、実行中のrunが開始deploymentに固定されることをrunbookに書く必要がある。

開発と運用への影響

導入は段階的に行うべきです。オンボーディングメール、レポート生成、遅延通知、承認付きAI agent flowのように観測しやすく巻き戻しやすい処理から始め、決済や在庫のような不可逆処理はrollback stepとrunbookを揃えてから移行します。

実務チェックリスト

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

リスクと反論

この統合はbetaであり、すべてのjobをworkflowへ置き換える理由にはなりません。短いcache更新や単純なwebhook forwardingは通常のrequest/responseや小さなqueueで十分な場合があります。便利な同一runtimeアクセスは、retryしてよいコードとしてはいけないコードの境界を曖昧にしない範囲で使うべきです。

出典

다른 글