別Workerからの投入

performerを持たないWorkerからジョブを投入する場合、tsumugi/clientのcreateClientを使用してください。
performerを定義したWorkerでは、defineTsumugiの戻り値から投入します。

使い方

import { createClient } from 'tsumugi/client';

const jobs = createClient<Env>();

export default {
  async fetch(request, env) {
    const id = await jobs.enqueue(env, {
      binding: 'MAIL',
      payload: { to: 'a@example.com', subject: 'hi' },
    });
    return Response.json({ id });
  },
} satisfies ExportedHandler<Env>;

必要なbinding

投入するWorkerに設定するbindingは、JOB_SHARDに限定されます。
script_nameには、Tsumugiを設定したWorkerの名前を指定してください。

{
  "durable_objects": {
    "bindings": [
      {
        "name": "JOB_SHARD",
        "class_name": "TsumugiJobShard",
        "script_name": "my-jobs",
      },
    ],
  },
}

設定の一致

shardsを2以上に設定したbindingでは、createClientにも同じshardsを指定してください。

const jobs = createClient<Env>({
  MAIL: { shards: 4 },
});

policyと保持期間は、bindingごとにTsumugiを設定したWorkerと同じ値を指定してください。

API

メソッド	内容
`enqueue(env, input)`	1件のジョブの投入。戻り値はジョブID
`enqueueMany(env, inputs)`	複数のジョブの一括投入
`shardFor(env, binding, partitionKey?)`	投入先のshardのstubの取得

型

tsumugi/clientは、EnqueueInput, EnqueueOptions, EnqueueItem, JobQueue, Performers, BindingConfig, TsumugiClientなどの型を提供します。

createClientのenqueueが受け取るEnqueueInputでは、bindingはstring型, payloadはunknown型です。
そのため、bindingごとの型検査とキーの必須化は適用されません。
performerの型を共有している場合は、JobQueue<M>に適合するラッパーを作成すると、defineTsumugiと同じ型検査が適用されます。
両者の違いは、投入方法にまとめています。

REST APIからの投入

Workerを追加せずにジョブを投入する場合は、Tsumugiを設定したWorkerのREST APIにリクエストを送信してください。

curl -X POST https://my-jobs.example.workers.dev/api/jobs \
  -H "Authorization: Bearer $TSUMUGI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"binding":"MAIL","payload":{"to":"a@example.com","subject":"hi"}}'

リクエストの形式は、REST APIを参照してください。

このページを編集

公開日: 2026年7月22日最終更新: 2026年10月25日

別Workerからの投入

使い方

必要なbinding

設定の一致

投入時の既定値

API

型

REST APIからの投入