概要
https://vercel.com/blog/inside-workflow-devkit-how-framework-integrations-work
詳細内容
## Workflow DevKitの内側：フレームワーク統合の仕組み
https://vercel.com/blog/inside-workflow-devkit-how-framework-integrations-work
**Original Title**: Inside Workflow DevKit: How framework integrations work
VercelのWorkflow DevKitは、ビルド時のワークフローハンドラ生成とランタイム時のエンドポイント公開という二段階パターン、およびSWCコンパイラ変換によって、様々なJavaScriptフレームワークとシームレスに統合し、開発者が既存の環境を移行することなく耐久性のあるワークフローを利用できるようにする仕組みを解説する。
**Content Type**: ⚙️ Tools
**Language**: en
**Scores**: Signal:5/5 | Depth:4/5 | Unique:3/5 | Practical:4/5 | Anti-Hype:4/5
**Main Journal**: 79/100 | **Annex Potential**: 76/100 | **Overall**: 80/100
**Topics**: [[Workflow DevKit, フレームワーク統合, SWCコンパイラ, Hot Module Replacement, 耐久性のあるワークフロー]]
VercelのWorkflow Development Kit (WDK) は、Next.jsやNitroに加え、SvelteKit、Astro、Express、Honoなど8つのフレームワークに対応し、さらに拡張を続けています。この記事は、これらの多様なフレームワーク統合を可能にする内部パターンと仕組みを解説しています。
WDKのフレームワーク統合は、本質的に「ビルド時」と「ランタイム時」の2つのフェーズに従います。ビルド時には、ワークフローとステップ関数が実行可能なハンドラファイルにコンパイルされ、バンドル、出力先決定、フレームワーク固有のパッチ適用、ホットモジュールリプレースメント (HMR) の設定が行われます。これにより、開発者は開発サーバーを再起動することなく、ワークフローの変更を即座に確認できます。ランタイム時には、ビルドされたハンドラファイルがアプリケーションのサーバーからアクセス可能なHTTPエンドポイントとして公開され、手動でのエンドポイント設定は不要です。
この「魔法」は、WDKのSWCコンパイラプラグインによって実現されます。このプラグインは、同じ入力ファイルを3つの異なるモード（Client、Step、Workflow）に応じて変換します。Clientモードはフレームワークのビルド中に実行され、ワークフロー呼び出しをHTTPクライアントコードに変換します。StepモードとWorkflowモードはWDKのesbuildフェーズで実行され、それぞれ「use step」関数をサーバーでステップロジックを実行するHTTPハンドラに、「use workflow」関数をサンドボックス化された仮想環境で実行されるオーケストレータに変換します。これにより、開発者はコードを一度書くだけで、クライアント、ステップハンドラ、ワークフローハンドラが自動生成されます。
SvelteKitの統合は具体例として挙げられており、`workflowPlugin()`がViteのビルドにフックし、クライアント変換とesbuildによるハンドラ生成を並行して行います。SvelteKitのファイルベースルーティングは、生成された`+server.js`ファイルを自動的に検出し、HTTPエンドポイントとして公開します。ExpressやHonoのようなバンドラーを持たないHTTPサーバーフレームワークには、Nitroが利用され、ワークフローを仮想ハンドラとしてマウントすることで同様の機能を提供します。
統合の過程で、異なるフレームワークのリクエストオブジェクトの形式が異なるという課題に直面しましたが、これは各生成ハンドラに小さなコンバータ関数を注入することで解決されました。
著者は、この統合パターンを構築することで、フレームワークの選択がWDKの採用における不要な障壁になっていることが明らかになったと述べています。各フレームワークとの統合は、そのエコシステムにコミットしている開発者コミュニティ全体にWDKを開放することを意味します。これにより、チームは耐久性のあるワークフローを利用するために別のフレームワークに移行する必要がなくなり、既存のスタックに単一行の設定を追加するだけで導入できるため、開発者の生産性が向上し、フレームワークのロックインを回避できます。このアプローチは、耐久性をエコシステム全体で「言語レベルのコンセプト」に近づけるというWDKの目標を達成する上で重要な一歩であると結論付けられています。