diff --git a/docs/next/creating-workers/http.mdx b/docs/next/creating-workers/http.mdx index f3ef628d24..aa837159c1 100644 --- a/docs/next/creating-workers/http.mdx +++ b/docs/next/creating-workers/http.mdx @@ -1,20 +1,20 @@ --- title: "HTTP" -description: "Expose functions as HTTP endpoints with the iii-http worker." +description: "Expose functions as HTTP endpoints with the http worker." owner: "devrel" type: "how-to" --- -The `iii-http` worker exposes your functions as HTTP endpoints, turning a function into a REST route +The `http` worker exposes your functions as HTTP endpoints, turning a function into a REST route without standing up a separate web server. ```bash -iii worker add iii-http +iii worker add http ``` This page is a quick tour. For path patterns, methods, headers, and response handling, see the - [iii-http worker docs](https://workers.iii.dev/workers/iii-http). The worker's server settings + [http worker docs](https://workers.iii.dev/workers/http). The worker's server settings (port, host, CORS, timeouts) are managed at runtime through the [configuration worker](../using-iii/configuration). @@ -139,7 +139,7 @@ iii worker add ./my-worker ``` For path patterns, request and response shapes, and the other configuration options, see the -[iii-http worker docs](https://workers.iii.dev/workers/iii-http). +[http worker docs](https://workers.iii.dev/workers/http). ## Calling the endpoint diff --git a/docs/next/creating-workers/http.mdx.skill.md b/docs/next/creating-workers/http.mdx.skill.md index 1e22121d1e..6d5cdffe0d 100644 --- a/docs/next/creating-workers/http.mdx.skill.md +++ b/docs/next/creating-workers/http.mdx.skill.md @@ -1,16 +1,16 @@ -The `iii-http` worker exposes your functions as HTTP endpoints, turning a function into a REST route +The `http` worker exposes your functions as HTTP endpoints, turning a function into a REST route without standing up a separate web server. ```bash -iii worker add iii-http +iii worker add http ``` This page is a quick tour. For path patterns, methods, headers, and response handling, see the - [iii-http worker docs](https://workers.iii.dev/workers/iii-http). The worker's server settings + [http worker docs](https://workers.iii.dev/workers/http). The worker's server settings (port, host, CORS, timeouts) are managed at runtime through the [configuration worker](../using-iii/configuration). @@ -135,7 +135,7 @@ iii worker add ./my-worker ``` For path patterns, request and response shapes, and the other configuration options, see the -[iii-http worker docs](https://workers.iii.dev/workers/iii-http). +[http worker docs](https://workers.iii.dev/workers/http). ## Calling the endpoint diff --git a/docs/next/creating-workers/queues.mdx b/docs/next/creating-workers/queues.mdx index e8f51c1794..31a46dc6d9 100644 --- a/docs/next/creating-workers/queues.mdx +++ b/docs/next/creating-workers/queues.mdx @@ -1,18 +1,18 @@ --- title: "Queues" description: - "Async job processing with named topics, retries, and dead-letter support via the iii-queue + "Async job processing with named topics, retries, and dead-letter support via the queue worker." owner: "devrel" type: "how-to" --- -The `iii-queue` worker decouples producers from consumers: a function publishes a message to a named +The `queue` worker decouples producers from consumers: a function publishes a message to a named topic and returns right away, and any function subscribed to that topic processes the message in the background, with retries and a dead-letter queue (DLQ) for messages that keep failing. ```bash -iii worker add iii-queue +iii worker add queue ``` @@ -27,10 +27,10 @@ number of retries then you can use `TriggerAction.Enqueue` to place that operati ### Creating a Queue -Queues are defined in the `iii-queue` worker's config under `queue_configs`: +Queues are defined in the `queue` worker's config under `queue_configs`: ```yaml -- name: iii-queue +- name: queue config: queue_configs: email-jobs: diff --git a/docs/next/creating-workers/queues.mdx.skill.md b/docs/next/creating-workers/queues.mdx.skill.md index accee2007e..7b55742b32 100644 --- a/docs/next/creating-workers/queues.mdx.skill.md +++ b/docs/next/creating-workers/queues.mdx.skill.md @@ -1,12 +1,12 @@ -The `iii-queue` worker decouples producers from consumers: a function publishes a message to a named +The `queue` worker decouples producers from consumers: a function publishes a message to a named topic and returns right away, and any function subscribed to that topic processes the message in the background, with retries and a dead-letter queue (DLQ) for messages that keep failing. ```bash -iii worker add iii-queue +iii worker add queue ``` @@ -21,10 +21,10 @@ number of retries then you can use `TriggerAction.Enqueue` to place that operati ### Creating a Queue -Queues are defined in the `iii-queue` worker's config under `queue_configs`: +Queues are defined in the `queue` worker's config under `queue_configs`: ```yaml -- name: iii-queue +- name: queue config: queue_configs: email-jobs: diff --git a/docs/next/creating-workers/triggers.mdx b/docs/next/creating-workers/triggers.mdx index 9907e829b0..b46a2a6cfb 100644 --- a/docs/next/creating-workers/triggers.mdx +++ b/docs/next/creating-workers/triggers.mdx @@ -9,10 +9,10 @@ type: "how-to" ## What "writing a trigger" means A worker uses triggers two ways. Most of the time, you bind the worker's functions by registering a -trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/iii-http), -[`cron`](https://workers.iii.dev/workers/iii-cron), -[queue messages](https://workers.iii.dev/workers/iii-queue), -[`state` changes](https://workers.iii.dev/workers/iii-state), and any other event source in the +trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/http), +[`cron`](https://workers.iii.dev/workers/cron), +[queue messages](https://workers.iii.dev/workers/queue), +[`state` changes](https://workers.iii.dev/workers/state), and any other event source in the system. Less often, you register a new trigger type from your worker so other workers can bind their functions to events your worker emits. @@ -30,10 +30,10 @@ triggers in new workers then refer to [Using iii / Triggers](../using-iii/trigge ## Bind a function to an existing trigger type Most workers consume trigger types that other workers already publish: `http` from -[iii-http](https://workers.iii.dev/workers/iii-http) to expose a function as an endpoint, `cron` -from [iii-cron](https://workers.iii.dev/workers/iii-cron) to run a function on a schedule, queue -triggers from [iii-queue](https://workers.iii.dev/workers/iii-queue) to fire a function on each -message, `state` from [iii-state](https://workers.iii.dev/workers/iii-state) to react to data +[http](https://workers.iii.dev/workers/http) to expose a function as an endpoint, `cron` +from [cron](https://workers.iii.dev/workers/cron) to run a function on a schedule, queue +triggers from [queue](https://workers.iii.dev/workers/queue) to fire a function on each +message, `state` from [state](https://workers.iii.dev/workers/state) to react to data changes. Bind one of your worker's functions to a trigger type with `worker.registerTrigger({ type, function_id, config })`. The worker that publishes the trigger type must be connected when you register; otherwise the registration fails. @@ -146,7 +146,7 @@ Don't confuse trigger _metadata_ with trigger type [_schemas_](#attach-schemas-t surfaces this information on request. - **Schemas** are set by the **publisher** when declaring the trigger type. They document the JSON shapes the consumer interacts with. For example, the `http` type published by - [iii-http](https://workers.iii.dev/workers/iii-http) declares: + [http](https://workers.iii.dev/workers/http) declares: - `config` (what the consumer passes at bind time): `{ api_path, http_method }`. - invocation payload (what their bound function receives on each request): `{ method, headers, query_params, body }`. @@ -190,11 +190,11 @@ The trigger type can be torn down at any point during runtime with See the [Unregister a Trigger Type](#unregister-a-trigger-type) section below for per-language signatures. -### Example: A mini `iii-http` from scratch +### Example: A mini `http` from scratch {/* TODO: Review against real SDK/CLI surface (now, and post-sdk rework, separately) */} -The example below sketches a tiny version of [iii-http](https://workers.iii.dev/workers/iii-http), +The example below sketches a tiny version of [http](https://workers.iii.dev/workers/http), the worker that publishes the real `http` trigger type. The publisher worker: 1. Declares an HTTP-shaped trigger type called `mini-http` diff --git a/docs/next/creating-workers/triggers.mdx.skill.md b/docs/next/creating-workers/triggers.mdx.skill.md index 8572c1e479..cff4738956 100644 --- a/docs/next/creating-workers/triggers.mdx.skill.md +++ b/docs/next/creating-workers/triggers.mdx.skill.md @@ -4,10 +4,10 @@ ## What "writing a trigger" means A worker uses triggers two ways. Most of the time, you bind the worker's functions by registering a -trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/iii-http), -[`cron`](https://workers.iii.dev/workers/iii-cron), -[queue messages](https://workers.iii.dev/workers/iii-queue), -[`state` changes](https://workers.iii.dev/workers/iii-state), and any other event source in the +trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/http), +[`cron`](https://workers.iii.dev/workers/cron), +[queue messages](https://workers.iii.dev/workers/queue), +[`state` changes](https://workers.iii.dev/workers/state), and any other event source in the system. Less often, you register a new trigger type from your worker so other workers can bind their functions to events your worker emits. @@ -25,10 +25,10 @@ triggers in new workers then refer to [Using iii / Triggers](../using-iii/trigge ## Bind a function to an existing trigger type Most workers consume trigger types that other workers already publish: `http` from -[iii-http](https://workers.iii.dev/workers/iii-http) to expose a function as an endpoint, `cron` -from [iii-cron](https://workers.iii.dev/workers/iii-cron) to run a function on a schedule, queue -triggers from [iii-queue](https://workers.iii.dev/workers/iii-queue) to fire a function on each -message, `state` from [iii-state](https://workers.iii.dev/workers/iii-state) to react to data +[http](https://workers.iii.dev/workers/http) to expose a function as an endpoint, `cron` +from [cron](https://workers.iii.dev/workers/cron) to run a function on a schedule, queue +triggers from [queue](https://workers.iii.dev/workers/queue) to fire a function on each +message, `state` from [state](https://workers.iii.dev/workers/state) to react to data changes. Bind one of your worker's functions to a trigger type with `worker.registerTrigger({ type, function_id, config })`. The worker that publishes the trigger type must be connected when you register; otherwise the registration fails. @@ -141,7 +141,7 @@ Don't confuse trigger _metadata_ with trigger type [_schemas_](#attach-schemas-t surfaces this information on request. - **Schemas** are set by the **publisher** when declaring the trigger type. They document the JSON shapes the consumer interacts with. For example, the `http` type published by - [iii-http](https://workers.iii.dev/workers/iii-http) declares: + [http](https://workers.iii.dev/workers/http) declares: - `config` (what the consumer passes at bind time): `{ api_path, http_method }`. - invocation payload (what their bound function receives on each request): `{ method, headers, query_params, body }`. @@ -185,11 +185,11 @@ The trigger type can be torn down at any point during runtime with See the [Unregister a Trigger Type](#unregister-a-trigger-type) section below for per-language signatures. -### Example: A mini `iii-http` from scratch +### Example: A mini `http` from scratch {/* TODO: Review against real SDK/CLI surface (now, and post-sdk rework, separately) */} -The example below sketches a tiny version of [iii-http](https://workers.iii.dev/workers/iii-http), +The example below sketches a tiny version of [http](https://workers.iii.dev/workers/http), the worker that publishes the real `http` trigger type. The publisher worker: 1. Declares an HTTP-shaped trigger type called `mini-http` diff --git a/docs/next/creating-workers/worker-manifest.mdx b/docs/next/creating-workers/worker-manifest.mdx index 65141b7efc..522e67e4f9 100644 --- a/docs/next/creating-workers/worker-manifest.mdx +++ b/docs/next/creating-workers/worker-manifest.mdx @@ -154,8 +154,8 @@ against the registry. ```yaml dependencies: - iii-http: "^0.20" - iii-state: "^0.20" + http: "^0.20" + state: "^0.20" ``` Rules: diff --git a/docs/next/creating-workers/worker-manifest.mdx.skill.md b/docs/next/creating-workers/worker-manifest.mdx.skill.md index 0c4871019e..d956632d96 100644 --- a/docs/next/creating-workers/worker-manifest.mdx.skill.md +++ b/docs/next/creating-workers/worker-manifest.mdx.skill.md @@ -150,8 +150,8 @@ against the registry. ```yaml dependencies: - iii-http: "^0.20" - iii-state: "^0.20" + http: "^0.20" + state: "^0.20" ``` Rules: diff --git a/docs/next/how-to/schedule-cron-task.mdx b/docs/next/how-to/schedule-cron-task.mdx index be46b77b91..d1d4dac1a3 100644 --- a/docs/next/how-to/schedule-cron-task.mdx +++ b/docs/next/how-to/schedule-cron-task.mdx @@ -1,8 +1,8 @@ --- title: "Schedule a cron task" -description: "Run a function on a recurring schedule with the iii-cron trigger type." +description: "Run a function on a recurring schedule with the cron trigger type." owner: "devrel" type: "how-to" --- -{/* TODO: write the how-to. Cover installing/enabling iii-cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */} +{/* TODO: write the how-to. Cover installing/enabling cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */} diff --git a/docs/next/how-to/schedule-cron-task.mdx.skill.md b/docs/next/how-to/schedule-cron-task.mdx.skill.md index 141b67b50a..56a0c3be95 100644 --- a/docs/next/how-to/schedule-cron-task.mdx.skill.md +++ b/docs/next/how-to/schedule-cron-task.mdx.skill.md @@ -3,4 +3,4 @@ # Schedule a cron task -{/* TODO: write the how-to. Cover installing/enabling iii-cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */} +{/* TODO: write the how-to. Cover installing/enabling cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */} diff --git a/docs/next/quickstart.mdx b/docs/next/quickstart.mdx index afeee3125c..6a372c7d59 100644 --- a/docs/next/quickstart.mdx +++ b/docs/next/quickstart.mdx @@ -138,7 +138,7 @@ Start by adding the state worker, which gives every function access to a persist From the folder containing iii's `config.yaml` run: ```bash -iii worker add iii-state +iii worker add state ``` Now open `workers/math-worker/src/math_worker.py` in your code editor and uncomment the state block so @@ -197,7 +197,7 @@ Now let's add an HTTP worker to expose your functions as REST endpoints. From the folder containing iii's `config.yaml` run: ```bash -iii worker add iii-http +iii worker add http ``` Open `workers/caller-worker/src/worker.ts` and uncomment the HTTP block at the bottom of the file: diff --git a/docs/next/quickstart.mdx.skill.md b/docs/next/quickstart.mdx.skill.md index e1605942bf..1b8b1fb6e7 100644 --- a/docs/next/quickstart.mdx.skill.md +++ b/docs/next/quickstart.mdx.skill.md @@ -134,7 +134,7 @@ Start by adding the state worker, which gives every function access to a persist From the folder containing iii's `config.yaml` run: ```bash -iii worker add iii-state +iii worker add state ``` Now open `workers/math-worker/src/math_worker.py` in your code editor and uncomment the state block so @@ -193,7 +193,7 @@ Now let's add an HTTP worker to expose your functions as REST endpoints. From the folder containing iii's `config.yaml` run: ```bash -iii worker add iii-http +iii worker add http ``` Open `workers/caller-worker/src/worker.ts` and uncomment the HTTP block at the bottom of the file: diff --git a/docs/next/reference/engine-protocol.mdx b/docs/next/reference/engine-protocol.mdx index d999999f20..1dd3a27621 100644 --- a/docs/next/reference/engine-protocol.mdx +++ b/docs/next/reference/engine-protocol.mdx @@ -99,7 +99,7 @@ functions (`HttpInvocationRef`); leave it `null` for in-process handlers. ``` `config` is the per-trigger-type configuration; the shape is defined by whatever worker advertised -that `trigger_type` (e.g. `iii-http` for `http` triggers). The engine responds with a +that `trigger_type` (e.g. `http` for `http` triggers). The engine responds with a `TriggerRegistrationResult` carrying an optional `error: ErrorBody`. ## `RegisterTriggerType` @@ -190,7 +190,7 @@ call and surfaces this code to the caller), `function_not_found`, `function_not_ | ---------------------------------------- | -------------------------------------------------------- | | omitted / `null` | Synchronous; the worker replies with `InvocationResult`. | | `{ "type": "void" }` | Fire-and-forget; no `invocation_id`, no reply. | -| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `iii-queue`). | +| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `queue`). | ## Invocation lifecycle diff --git a/docs/next/reference/engine-protocol.mdx.skill.md b/docs/next/reference/engine-protocol.mdx.skill.md index 70c328b83c..d8163e1dae 100644 --- a/docs/next/reference/engine-protocol.mdx.skill.md +++ b/docs/next/reference/engine-protocol.mdx.skill.md @@ -97,7 +97,7 @@ functions (`HttpInvocationRef`); leave it `null` for in-process handlers. ``` `config` is the per-trigger-type configuration; the shape is defined by whatever worker advertised -that `trigger_type` (e.g. `iii-http` for `http` triggers). The engine responds with a +that `trigger_type` (e.g. `http` for `http` triggers). The engine responds with a `TriggerRegistrationResult` carrying an optional `error: ErrorBody`. ## `RegisterTriggerType` @@ -188,7 +188,7 @@ call and surfaces this code to the caller), `function_not_found`, `function_not_ | ---------------------------------------- | -------------------------------------------------------- | | omitted / `null` | Synchronous; the worker replies with `InvocationResult`. | | `{ "type": "void" }` | Fire-and-forget; no `invocation_id`, no reply. | -| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `iii-queue`). | +| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `queue`). | ## Invocation lifecycle diff --git a/docs/next/reference/sdk-browser.mdx b/docs/next/reference/sdk-browser.mdx index 76bbdeffa6..1e0e1cc417 100644 --- a/docs/next/reference/sdk-browser.mdx +++ b/docs/next/reference/sdk-browser.mdx @@ -231,7 +231,7 @@ await worker.trigger({ }) // Enqueue for async processing (the queue must be declared in the -// iii-queue worker's queue_configs) +// queue worker's queue_configs) const receipt = await worker.trigger({ function_id: 'process-order', payload: { orderId: '123' }, diff --git a/docs/next/reference/sdk-browser.mdx.skill.md b/docs/next/reference/sdk-browser.mdx.skill.md index 7e6b004a5c..f95fa28670 100644 --- a/docs/next/reference/sdk-browser.mdx.skill.md +++ b/docs/next/reference/sdk-browser.mdx.skill.md @@ -229,7 +229,7 @@ await worker.trigger({ }) // Enqueue for async processing (the queue must be declared in the -// iii-queue worker's queue_configs) +// queue worker's queue_configs) const receipt = await worker.trigger({ function_id: 'process-order', payload: { orderId: '123' }, diff --git a/docs/next/reference/sdk-node.mdx b/docs/next/reference/sdk-node.mdx index 32dd957ecc..ae042c9e8e 100644 --- a/docs/next/reference/sdk-node.mdx +++ b/docs/next/reference/sdk-node.mdx @@ -266,7 +266,7 @@ await worker.trigger({ }) // Enqueue for async processing (the queue must be declared in the -// iii-queue worker's queue_configs) +// queue worker's queue_configs) const receipt = await worker.trigger({ function_id: 'process-order', payload: { orderId: '123' }, diff --git a/docs/next/reference/sdk-node.mdx.skill.md b/docs/next/reference/sdk-node.mdx.skill.md index ef2a692e07..16332c71f9 100644 --- a/docs/next/reference/sdk-node.mdx.skill.md +++ b/docs/next/reference/sdk-node.mdx.skill.md @@ -264,7 +264,7 @@ await worker.trigger({ }) // Enqueue for async processing (the queue must be declared in the -// iii-queue worker's queue_configs) +// queue worker's queue_configs) const receipt = await worker.trigger({ function_id: 'process-order', payload: { orderId: '123' }, diff --git a/docs/next/reference/sdk-rust.mdx b/docs/next/reference/sdk-rust.mdx index 047afff273..e0b9ea33b2 100644 --- a/docs/next/reference/sdk-rust.mdx +++ b/docs/next/reference/sdk-rust.mdx @@ -267,7 +267,7 @@ worker.trigger(TriggerRequest { timeout_ms: None, }).await?; -// Enqueue (the queue must be declared in the iii-queue worker's +// Enqueue (the queue must be declared in the queue worker's // queue_configs) let receipt = worker.trigger(TriggerRequest { function_id: "iii::durable::publish".to_string(), diff --git a/docs/next/reference/sdk-rust.mdx.skill.md b/docs/next/reference/sdk-rust.mdx.skill.md index 6d11cbb485..c714f3ceb9 100644 --- a/docs/next/reference/sdk-rust.mdx.skill.md +++ b/docs/next/reference/sdk-rust.mdx.skill.md @@ -265,7 +265,7 @@ worker.trigger(TriggerRequest { timeout_ms: None, }).await?; -// Enqueue (the queue must be declared in the iii-queue worker's +// Enqueue (the queue must be declared in the queue worker's // queue_configs) let receipt = worker.trigger(TriggerRequest { function_id: "iii::durable::publish".to_string(), diff --git a/docs/next/tutorials/linkly/durable-execution.mdx b/docs/next/tutorials/linkly/durable-execution.mdx index 194fb06c19..5dd9a02eda 100644 --- a/docs/next/tutorials/linkly/durable-execution.mdx +++ b/docs/next/tutorials/linkly/durable-execution.mdx @@ -14,23 +14,23 @@ independent subscribers: a Python analytics worker and a cache refresher, both d ## Add the workers -This chapter uses two workers. `iii-queue` is already in your project from `iii project init`. Add -`iii-pubsub` now; you publish your first event to it later in the chapter: +This chapter uses two workers. `queue` is already in your project from `iii project init`. Add +`pubsub` now; you publish your first event to it later in the chapter: ```bash -iii worker add iii-pubsub +iii worker add pubsub ``` ## Make redirects fast with a queue A queue holds work that is accepted now and run later. Here we'll define a `clicks` queue that we're -going to use for `link::record_click`. `iii-queue` has been running since Chapter 1, so its settings -are managed in `./config/iii-queue.yaml` (see [Configuration](/using-iii/configuration)). Define the +going to use for `link::record_click`. `queue` has been running since Chapter 1, so its settings +are managed in `./config/queue.yaml` (see [Configuration](/using-iii/configuration)). Define the queue by adding `queue_configs` under `value:` in that file and save; the change applies without a restart: -```yaml {4-8} config/iii-queue.yaml -id: iii-queue +```yaml {4-8} config/queue.yaml +id: queue # ... value: queue_configs: @@ -59,7 +59,7 @@ import { Logger } from "@iii-dev/helpers/observability"; ``` Then add an `action` to the existing `link::record_click` call in `http::redirect` so the -`iii-queue` worker enqueues it instead of running it inline: +`queue` worker enqueues it instead of running it inline: ```typescript src/index.ts {6} worker.registerFunction("http::redirect", async (req) => { @@ -82,13 +82,13 @@ A queue delivers each message to one consumer. When several unrelated parts of t react to the same event, use a publish subscribe design instead. - We ship both a `iii-queue` and `iii-pubsub` worker. While `iii-queue` provides standard queueing + We ship both a `queue` and `pubsub` worker. While `queue` provides standard queueing it also provides its own durable publish and subscribe. When you need a publish and subscribe flow to be guaranteed to succeed (or fail to a DLQ) then use -`iii-queue`s `iii::durable::publish` and `durable:subscriber`. +`queue`s `iii::durable::publish` and `durable:subscriber`. -When you don't need a publish and subscribe flow to be guaranteed then use `iii-pubsub`s `publish` +When you don't need a publish and subscribe flow to be guaranteed then use `pubsub`s `publish` and `subscribe`. @@ -119,7 +119,7 @@ worker.registerFunction("link::create", async (payload: { url: string; code?: st Now add an update path to the `link` worker so a link's target can change, and announce it. First, the domain function: it updates the database row and publishes a `link.updated` event through -durable pub/sub (`iii::durable::publish`, served by `iii-queue`). Place it at the end of +durable pub/sub (`iii::durable::publish`, served by `queue`). Place it at the end of `link/src/index.ts`: ```typescript src/index.ts @@ -185,9 +185,9 @@ event with a **durable** subscriber: **Durable vs. regular pub/sub.** `link.updated` uses durable pub/sub: `iii::durable::publish` with - a `durable:subscriber` trigger, both served by the `iii-queue` worker. Consumers like this cache + a `durable:subscriber` trigger, both served by the `queue` worker. Consumers like this cache refresher must receive every update. A dropped event would leave the cache pointing at a stale - URL. `link.created` stays on regular pub/sub (`iii-pubsub`). Its only consumer is a best-effort + URL. `link.created` stays on regular pub/sub (`pubsub`). Its only consumer is a best-effort daily counter, so an occasional miss is harmless. Use durable pub/sub when a missed event would corrupt state, and regular pub/sub for fire-and-forget fan-out. diff --git a/docs/next/tutorials/linkly/durable-execution.mdx.skill.md b/docs/next/tutorials/linkly/durable-execution.mdx.skill.md index bb1ac4c959..a2c7695218 100644 --- a/docs/next/tutorials/linkly/durable-execution.mdx.skill.md +++ b/docs/next/tutorials/linkly/durable-execution.mdx.skill.md @@ -9,23 +9,23 @@ independent subscribers: a Python analytics worker and a cache refresher, both d ## Add the workers -This chapter uses two workers. `iii-queue` is already in your project from `iii project init`. Add -`iii-pubsub` now; you publish your first event to it later in the chapter: +This chapter uses two workers. `queue` is already in your project from `iii project init`. Add +`pubsub` now; you publish your first event to it later in the chapter: ```bash -iii worker add iii-pubsub +iii worker add pubsub ``` ## Make redirects fast with a queue A queue holds work that is accepted now and run later. Here we'll define a `clicks` queue that we're -going to use for `link::record_click`. `iii-queue` has been running since Chapter 1, so its settings -are managed in `./config/iii-queue.yaml` (see [Configuration](/using-iii/configuration)). Define the +going to use for `link::record_click`. `queue` has been running since Chapter 1, so its settings +are managed in `./config/queue.yaml` (see [Configuration](/using-iii/configuration)). Define the queue by adding `queue_configs` under `value:` in that file and save; the change applies without a restart: -```yaml {4-8} config/iii-queue.yaml -id: iii-queue +```yaml {4-8} config/queue.yaml +id: queue # ... value: queue_configs: @@ -54,7 +54,7 @@ import { Logger } from "@iii-dev/helpers/observability"; ``` Then add an `action` to the existing `link::record_click` call in `http::redirect` so the -`iii-queue` worker enqueues it instead of running it inline: +`queue` worker enqueues it instead of running it inline: ```typescript src/index.ts {6} worker.registerFunction("http::redirect", async (req) => { @@ -77,13 +77,13 @@ A queue delivers each message to one consumer. When several unrelated parts of t react to the same event, use a publish subscribe design instead. - We ship both a `iii-queue` and `iii-pubsub` worker. While `iii-queue` provides standard queueing + We ship both a `queue` and `pubsub` worker. While `queue` provides standard queueing it also provides its own durable publish and subscribe. When you need a publish and subscribe flow to be guaranteed to succeed (or fail to a DLQ) then use -`iii-queue`s `iii::durable::publish` and `durable:subscriber`. +`queue`s `iii::durable::publish` and `durable:subscriber`. -When you don't need a publish and subscribe flow to be guaranteed then use `iii-pubsub`s `publish` +When you don't need a publish and subscribe flow to be guaranteed then use `pubsub`s `publish` and `subscribe`. @@ -114,7 +114,7 @@ worker.registerFunction("link::create", async (payload: { url: string; code?: st Now add an update path to the `link` worker so a link's target can change, and announce it. First, the domain function: it updates the database row and publishes a `link.updated` event through -durable pub/sub (`iii::durable::publish`, served by `iii-queue`). Place it at the end of +durable pub/sub (`iii::durable::publish`, served by `queue`). Place it at the end of `link/src/index.ts`: ```typescript src/index.ts @@ -180,9 +180,9 @@ event with a **durable** subscriber: **Durable vs. regular pub/sub.** `link.updated` uses durable pub/sub: `iii::durable::publish` with - a `durable:subscriber` trigger, both served by the `iii-queue` worker. Consumers like this cache + a `durable:subscriber` trigger, both served by the `queue` worker. Consumers like this cache refresher must receive every update. A dropped event would leave the cache pointing at a stale - URL. `link.created` stays on regular pub/sub (`iii-pubsub`). Its only consumer is a best-effort + URL. `link.created` stays on regular pub/sub (`pubsub`). Its only consumer is a best-effort daily counter, so an occasional miss is harmless. Use durable pub/sub when a missed event would corrupt state, and regular pub/sub for fire-and-forget fan-out. diff --git a/docs/next/tutorials/linkly/foundations.mdx b/docs/next/tutorials/linkly/foundations.mdx index a6454eaea1..80e0da8927 100644 --- a/docs/next/tutorials/linkly/foundations.mdx +++ b/docs/next/tutorials/linkly/foundations.mdx @@ -21,26 +21,26 @@ cd linkly ## Add the workers you'll need -Later in this chapter you'll serve the `link` worker over HTTP (provided by `iii-http`) and stash -short-code → URL mappings in a key-value store (provided by `iii-state`). Add both now so they're +Later in this chapter you'll serve the `link` worker over HTTP (provided by `http`) and stash +short-code → URL mappings in a key-value store (provided by `state`). Add both now so they're ready when the `link` worker reaches for them: ```bash -iii worker add iii-http -iii worker add iii-state +iii worker add http +iii worker add state ``` If you open `config.yaml` now you'll notice both workers have been added, plus a few that iii ships by default and uses itself. -`iii-state` keeps its store on disk by default, so links survive restarts. For this chapter, switch -it to an in-memory store instead. Find the `iii-state` entry in `config.yaml` and set its +`state` keeps its store on disk by default, so links survive restarts. For this chapter, switch +it to an in-memory store instead. Find the `state` entry in `config.yaml` and set its `store_method`: ```yaml {8-9} config.yaml workers: # ... - - name: iii-state + - name: state config: adapter: name: kv @@ -156,9 +156,9 @@ function makeCode(): string { #### Add `link::create` `registerFunction` publishes a function under a name like `link::create` that anything else on the -engine can call. This one stores the mapping by calling `state::set` on the `iii-state` worker +engine can call. This one stores the mapping by calling `state::set` on the `state` worker through `worker.trigger`. Worker-to-worker calls always flow through the engine, so the `link` -worker doesn't import anything from `iii-state`; it knows the function name. Append it: +worker doesn't import anything from `state`; it knows the function name. Append it: ```typescript src/index.ts worker.registerFunction("link::create", async (payload: { url: string; code?: string }) => { @@ -194,7 +194,7 @@ logger.info("link worker ready"); ``` The `state::set` / `state::get` calls pass a `scope` (`links`) and a `key` (the short code). Scopes -keep different kinds of data in `iii-state` from colliding; later chapters add more. +keep different kinds of data in `state` from colliding; later chapters add more. ## Start the engine @@ -280,7 +280,7 @@ iii trigger link::resolve code=nope ## Expose your functions over HTTP A function becomes an HTTP endpoint when you bind it to an `http` trigger. That trigger type is -served by the `iii-http` worker you added at the start of the chapter. +served by the `http` worker you added at the start of the chapter. ### Create a function to handle new links @@ -312,7 +312,7 @@ worker.registerFunction("http::create", async (req) => { ### Bind your create function to a Trigger In the same file (`link/src/index.ts`) at the end bind `http::create` to `POST /links` with a new -trigger. This Trigger has the `iii-http` worker listen for `POST` requests to `/links` and when it +trigger. This Trigger has the `http` worker listen for `POST` requests to `/links` and when it receives one it will run the function specified by `function_id`. ```typescript src/index.ts @@ -351,7 +351,7 @@ content-type: application/json {"code":"demo","url":"https://example.com"} ``` -The link sits in `iii-state` now, but `GET /s/demo` has nowhere to go yet. There's no handler; add +The link sits in `state` now, but `GET /s/demo` has nowhere to go yet. There's no handler; add one next. ### Create a function to handle redirects @@ -391,7 +391,7 @@ worker.registerTrigger({ ### Follow the short code -`iii-state` is in-memory in this chapter, so each time the engine restarts the previous link is +`state` is in-memory in this chapter, so each time the engine restarts the previous link is gone. Chapter 3 swaps in durable storage. For now create a fresh link and try it out: ```bash @@ -425,7 +425,7 @@ HTTP/1.1 404 Not Found You have built a real link shortener: a domain worker exposed over HTTP, where the same `link::create` and `link::resolve` functions serve both the command line and the web. Restarting the -engine still clears every link, though: `iii-state` is in-memory until Chapter 3 swaps it for +engine still clears every link, though: `state` is in-memory until Chapter 3 swaps it for durable storage. Next, in [Ch. 2: Observe everything](/tutorials/linkly/observability), you will add logs and traces diff --git a/docs/next/tutorials/linkly/foundations.mdx.skill.md b/docs/next/tutorials/linkly/foundations.mdx.skill.md index e4419f58ed..4f3cb1d87d 100644 --- a/docs/next/tutorials/linkly/foundations.mdx.skill.md +++ b/docs/next/tutorials/linkly/foundations.mdx.skill.md @@ -17,26 +17,26 @@ cd linkly ## Add the workers you'll need -Later in this chapter you'll serve the `link` worker over HTTP (provided by `iii-http`) and stash -short-code → URL mappings in a key-value store (provided by `iii-state`). Add both now so they're +Later in this chapter you'll serve the `link` worker over HTTP (provided by `http`) and stash +short-code → URL mappings in a key-value store (provided by `state`). Add both now so they're ready when the `link` worker reaches for them: ```bash -iii worker add iii-http -iii worker add iii-state +iii worker add http +iii worker add state ``` If you open `config.yaml` now you'll notice both workers have been added, plus a few that iii ships by default and uses itself. -`iii-state` keeps its store on disk by default, so links survive restarts. For this chapter, switch -it to an in-memory store instead. Find the `iii-state` entry in `config.yaml` and set its +`state` keeps its store on disk by default, so links survive restarts. For this chapter, switch +it to an in-memory store instead. Find the `state` entry in `config.yaml` and set its `store_method`: ```yaml {8-9} config.yaml workers: # ... - - name: iii-state + - name: state config: adapter: name: kv @@ -152,9 +152,9 @@ function makeCode(): string { #### Add `link::create` `registerFunction` publishes a function under a name like `link::create` that anything else on the -engine can call. This one stores the mapping by calling `state::set` on the `iii-state` worker +engine can call. This one stores the mapping by calling `state::set` on the `state` worker through `worker.trigger`. Worker-to-worker calls always flow through the engine, so the `link` -worker doesn't import anything from `iii-state`; it knows the function name. Append it: +worker doesn't import anything from `state`; it knows the function name. Append it: ```typescript src/index.ts worker.registerFunction("link::create", async (payload: { url: string; code?: string }) => { @@ -190,7 +190,7 @@ logger.info("link worker ready"); ``` The `state::set` / `state::get` calls pass a `scope` (`links`) and a `key` (the short code). Scopes -keep different kinds of data in `iii-state` from colliding; later chapters add more. +keep different kinds of data in `state` from colliding; later chapters add more. ## Start the engine @@ -276,7 +276,7 @@ iii trigger link::resolve code=nope ## Expose your functions over HTTP A function becomes an HTTP endpoint when you bind it to an `http` trigger. That trigger type is -served by the `iii-http` worker you added at the start of the chapter. +served by the `http` worker you added at the start of the chapter. ### Create a function to handle new links @@ -308,7 +308,7 @@ worker.registerFunction("http::create", async (req) => { ### Bind your create function to a Trigger In the same file (`link/src/index.ts`) at the end bind `http::create` to `POST /links` with a new -trigger. This Trigger has the `iii-http` worker listen for `POST` requests to `/links` and when it +trigger. This Trigger has the `http` worker listen for `POST` requests to `/links` and when it receives one it will run the function specified by `function_id`. ```typescript src/index.ts @@ -347,7 +347,7 @@ content-type: application/json {"code":"demo","url":"https://example.com"} ``` -The link sits in `iii-state` now, but `GET /s/demo` has nowhere to go yet. There's no handler; add +The link sits in `state` now, but `GET /s/demo` has nowhere to go yet. There's no handler; add one next. ### Create a function to handle redirects @@ -387,7 +387,7 @@ worker.registerTrigger({ ### Follow the short code -`iii-state` is in-memory in this chapter, so each time the engine restarts the previous link is +`state` is in-memory in this chapter, so each time the engine restarts the previous link is gone. Chapter 3 swaps in durable storage. For now create a fresh link and try it out: ```bash @@ -421,7 +421,7 @@ HTTP/1.1 404 Not Found You have built a real link shortener: a domain worker exposed over HTTP, where the same `link::create` and `link::resolve` functions serve both the command line and the web. Restarting the -engine still clears every link, though: `iii-state` is in-memory until Chapter 3 swaps it for +engine still clears every link, though: `state` is in-memory until Chapter 3 swaps it for durable storage. Next, in [Ch. 2: Observe everything](/tutorials/linkly/observability), you will add logs and traces diff --git a/docs/next/tutorials/linkly/frontend.mdx b/docs/next/tutorials/linkly/frontend.mdx index beafbf8271..d747b25eda 100644 --- a/docs/next/tutorials/linkly/frontend.mdx +++ b/docs/next/tutorials/linkly/frontend.mdx @@ -113,7 +113,7 @@ iii worker add ./auth ## Add a server-initiated delete First give the `link` worker a `link::delete` that removes a link from both the database and the -`iii-state` cache. Add it to `link/src/index.ts`: +`state` cache. Add it to `link/src/index.ts`: ```typescript link/src/index.ts worker.registerFunction("link::delete", async (payload: { code: string }) => { diff --git a/docs/next/tutorials/linkly/frontend.mdx.skill.md b/docs/next/tutorials/linkly/frontend.mdx.skill.md index 17004301cb..6844e025a3 100644 --- a/docs/next/tutorials/linkly/frontend.mdx.skill.md +++ b/docs/next/tutorials/linkly/frontend.mdx.skill.md @@ -107,7 +107,7 @@ iii worker add ./auth ## Add a server-initiated delete First give the `link` worker a `link::delete` that removes a link from both the database and the -`iii-state` cache. Add it to `link/src/index.ts`: +`state` cache. Add it to `link/src/index.ts`: ```typescript link/src/index.ts worker.registerFunction("link::delete", async (payload: { code: string }) => { diff --git a/docs/next/tutorials/linkly/observability.mdx b/docs/next/tutorials/linkly/observability.mdx index c7b3e95caf..0d30c83174 100644 --- a/docs/next/tutorials/linkly/observability.mdx +++ b/docs/next/tutorials/linkly/observability.mdx @@ -29,7 +29,7 @@ curl -s -X POST http://127.0.0.1:3111/links \ for n in $(seq 1 5); do curl -s -o /dev/null http://127.0.0.1:3111/s/iii; done ``` -Click any redirect to see a full waterfall of timed spans crossing from `iii-http` into `link` and +Click any redirect to see a full waterfall of timed spans crossing from `http` into `link` and back: ![iii console Traces page showing redirect spans sorted by duration with the waterfall for a selected GET /s/:code trace](/next/tutorials/linkly/console-traces.png) @@ -130,7 +130,7 @@ GET /s/:code (iii) 2.044 ms execute link::resolve (iii-node) 0.52 ms ``` -This shows the redirect arriving through `/s/:code` via the `iii-http` worker's Trigger, calling +This shows the redirect arriving through `/s/:code` via the `http` worker's Trigger, calling `http::redirect` in `link`, which then calls `link::resolve` in the `link` worker via the engine. The per-span timing shows where the request spends its time. diff --git a/docs/next/tutorials/linkly/observability.mdx.skill.md b/docs/next/tutorials/linkly/observability.mdx.skill.md index 2dde2cf4b2..3c942eefdd 100644 --- a/docs/next/tutorials/linkly/observability.mdx.skill.md +++ b/docs/next/tutorials/linkly/observability.mdx.skill.md @@ -26,7 +26,7 @@ curl -s -X POST http://127.0.0.1:3111/links \ for n in $(seq 1 5); do curl -s -o /dev/null http://127.0.0.1:3111/s/iii; done ``` -Click any redirect to see a full waterfall of timed spans crossing from `iii-http` into `link` and +Click any redirect to see a full waterfall of timed spans crossing from `http` into `link` and back: ![iii console Traces page showing redirect spans sorted by duration with the waterfall for a selected GET /s/:code trace](/next/tutorials/linkly/console-traces.png) @@ -127,7 +127,7 @@ GET /s/:code (iii) 2.044 ms execute link::resolve (iii-node) 0.52 ms ``` -This shows the redirect arriving through `/s/:code` via the `iii-http` worker's Trigger, calling +This shows the redirect arriving through `/s/:code` via the `http` worker's Trigger, calling `http::redirect` in `link`, which then calls `link::resolve` in the `link` worker via the engine. The per-span timing shows where the request spends its time. diff --git a/docs/next/tutorials/linkly/overview.mdx b/docs/next/tutorials/linkly/overview.mdx index f8cded2975..341076fbe1 100644 --- a/docs/next/tutorials/linkly/overview.mdx +++ b/docs/next/tutorials/linkly/overview.mdx @@ -22,7 +22,7 @@ each other's functions through the engine. You add capability without rewriting ## Ch. 1: Foundations Build a custom `link` worker with `link::create` and `link::resolve`, store links in memory, then -expose them over HTTP with `iii-http` as `POST /links` and `GET /s/:code`. +expose them over HTTP with `http` as `POST /links` and `GET /s/:code`. ## Ch. 2: Observe everything @@ -32,12 +32,12 @@ and live invocations. ## Ch. 3: Persist everything Add a `database` worker (SQLite) so links and click events are stored durably and survive restarts, -with `iii-state` kept in front as a fast read cache. +with `state` kept in front as a fast read cache. ## Ch. 4: Make it durable -Push click events onto `iii-queue` so redirects stay fast, and publish `link.created` events with -`iii-pubsub` that a cache and an analytics function each subscribe to. +Push click events onto `queue` so redirects stay fast, and publish `link.created` events with +`pubsub` that a cache and an analytics function each subscribe to. ## Ch. 5: Stream live clicks diff --git a/docs/next/tutorials/linkly/overview.mdx.skill.md b/docs/next/tutorials/linkly/overview.mdx.skill.md index 95fe412f9c..0ce935cc87 100644 --- a/docs/next/tutorials/linkly/overview.mdx.skill.md +++ b/docs/next/tutorials/linkly/overview.mdx.skill.md @@ -20,7 +20,7 @@ each other's functions through the engine. You add capability without rewriting ## Ch. 1: Foundations Build a custom `link` worker with `link::create` and `link::resolve`, store links in memory, then -expose them over HTTP with `iii-http` as `POST /links` and `GET /s/:code`. +expose them over HTTP with `http` as `POST /links` and `GET /s/:code`. ## Ch. 2: Observe everything @@ -30,12 +30,12 @@ and live invocations. ## Ch. 3: Persist everything Add a `database` worker (SQLite) so links and click events are stored durably and survive restarts, -with `iii-state` kept in front as a fast read cache. +with `state` kept in front as a fast read cache. ## Ch. 4: Make it durable -Push click events onto `iii-queue` so redirects stay fast, and publish `link.created` events with -`iii-pubsub` that a cache and an analytics function each subscribe to. +Push click events onto `queue` so redirects stay fast, and publish `link.created` events with +`pubsub` that a cache and an analytics function each subscribe to. ## Ch. 5: Stream live clicks diff --git a/docs/next/tutorials/linkly/persistence.mdx b/docs/next/tutorials/linkly/persistence.mdx index c15a796da4..dc0f95a79d 100644 --- a/docs/next/tutorials/linkly/persistence.mdx +++ b/docs/next/tutorials/linkly/persistence.mdx @@ -6,13 +6,13 @@ owner: "devrel" type: "tutorial" --- -Linkly's links live in `iii-state`, which you set to in-memory back in Chapter 1. Restart the engine +Linkly's links live in `state`, which you set to in-memory back in Chapter 1. Restart the engine and everything is gone. In this chapter you add a `database` worker (SQLite) that holds the durable -record of links and a timestamped row for every click on a short code. `iii-state` stays in the +record of links and a timestamped row for every click on a short code. `state` stays in the picture as a fast read cache in front of the database. - `iii-state` can also persist on its own (`store_method: file_based` with a `file_path`). This + `state` can also persist on its own (`store_method: file_based` with a `file_path`). This chapter uses a dedicated `database` worker instead, which gives you durable storage plus SQL to query it. @@ -101,7 +101,7 @@ ensureSchema() #### Setup database writing -**Modify `link::create`** to write to both the database (durable record) and `iii-state` (hot +**Modify `link::create`** to write to both the database (durable record) and `state` (hot cache): ```typescript src/index.ts {4-11} @@ -257,7 +257,7 @@ iii trigger database::query db=primary sql="SELECT COUNT(*) AS clicks FROM click database::query --help` to see what arguments `database::query` accepts. -Linkly's links are now durable: the database is the source of truth, `iii-state` keeps lookups fast, +Linkly's links are now durable: the database is the source of truth, `state` keeps lookups fast, and every redirect appends a timestamped row to the `clicks` table. But that row is written on the redirect's hot path, so a slow database write slows the redirect. Next, in [Ch. 4: Make it durable](/tutorials/linkly/durable-execution), you move that write onto a queue so diff --git a/docs/next/tutorials/linkly/persistence.mdx.skill.md b/docs/next/tutorials/linkly/persistence.mdx.skill.md index 85439cb593..523794820a 100644 --- a/docs/next/tutorials/linkly/persistence.mdx.skill.md +++ b/docs/next/tutorials/linkly/persistence.mdx.skill.md @@ -1,13 +1,13 @@ -Linkly's links live in `iii-state`, which you set to in-memory back in Chapter 1. Restart the engine +Linkly's links live in `state`, which you set to in-memory back in Chapter 1. Restart the engine and everything is gone. In this chapter you add a `database` worker (SQLite) that holds the durable -record of links and a timestamped row for every click on a short code. `iii-state` stays in the +record of links and a timestamped row for every click on a short code. `state` stays in the picture as a fast read cache in front of the database. - `iii-state` can also persist on its own (`store_method: file_based` with a `file_path`). This + `state` can also persist on its own (`store_method: file_based` with a `file_path`). This chapter uses a dedicated `database` worker instead, which gives you durable storage plus SQL to query it. @@ -96,7 +96,7 @@ ensureSchema() #### Setup database writing -**Modify `link::create`** to write to both the database (durable record) and `iii-state` (hot +**Modify `link::create`** to write to both the database (durable record) and `state` (hot cache): ```typescript src/index.ts {4-11} @@ -252,7 +252,7 @@ iii trigger database::query db=primary sql="SELECT COUNT(*) AS clicks FROM click database::query --help` to see what arguments `database::query` accepts. -Linkly's links are now durable: the database is the source of truth, `iii-state` keeps lookups fast, +Linkly's links are now durable: the database is the source of truth, `state` keeps lookups fast, and every redirect appends a timestamped row to the `clicks` table. But that row is written on the redirect's hot path, so a slow database write slows the redirect. Next, in [Ch. 4: Make it durable](/tutorials/linkly/durable-execution), you move that write onto a queue so diff --git a/docs/next/tutorials/linkly/streaming.mdx b/docs/next/tutorials/linkly/streaming.mdx index 2b217cfad7..fda50b58e8 100644 --- a/docs/next/tutorials/linkly/streaming.mdx +++ b/docs/next/tutorials/linkly/streaming.mdx @@ -27,7 +27,7 @@ iii worker init click-streamer --language typescript We'll continue to keep `link` decoupled by having it announce that a click happened, and `click-streamer` reacts by pushing it onto the live feed. A live counter can tolerate the rare -dropped event, so a regular `iii-pubsub` event is the right tool here. +dropped event, so a regular `pubsub` event is the right tool here. ### Add a `link.clicked` event to the `link` worker diff --git a/docs/next/tutorials/linkly/streaming.mdx.skill.md b/docs/next/tutorials/linkly/streaming.mdx.skill.md index b9cac52351..aa0a46e0d8 100644 --- a/docs/next/tutorials/linkly/streaming.mdx.skill.md +++ b/docs/next/tutorials/linkly/streaming.mdx.skill.md @@ -24,7 +24,7 @@ iii worker init click-streamer --language typescript We'll continue to keep `link` decoupled by having it announce that a click happened, and `click-streamer` reacts by pushing it onto the live feed. A live counter can tolerate the rare -dropped event, so a regular `iii-pubsub` event is the right tool here. +dropped event, so a regular `pubsub` event is the right tool here. ### Add a `link.clicked` event to the `link` worker diff --git a/docs/next/understanding-iii/index.mdx b/docs/next/understanding-iii/index.mdx index ca020ee55d..70c116489e 100644 --- a/docs/next/understanding-iii/index.mdx +++ b/docs/next/understanding-iii/index.mdx @@ -53,7 +53,7 @@ The Quickstart tutorial produces a running system with two Workers connected to 1. `caller-worker` is a TypeScript Worker that registers `math::add_two_numbers`, which calls `math::add` through the Engine. -By the end of the Quickstart, the system also includes the `iii-state` and `iii-http` Workers, an +By the end of the Quickstart, the system also includes the `state` and `http` Workers, an HTTP Trigger that exposes `math::add_two_numbers` at `POST /math/add-two-numbers`, and a key-value scope named `math` holding a `running_total`. @@ -66,8 +66,8 @@ graph TD Engine <--> Math["math-worker (Python) math::add"] Engine <--> Caller["caller-worker (TypeScript) math::add_two_numbers"] - Engine <--> State["iii-state"] - Engine <--> HttpWorker["iii-http"] + Engine <--> State["state"] + Engine <--> HttpWorker["http"] ``` Every arrow is a WebSocket connection between a Worker and the Engine. There is no direct @@ -77,7 +77,7 @@ to `math-worker`. ## Workers -Workers are what actually do things in an iii system. Every category of capability is built as a +Workers do the work in an iii system. Every category of capability is built as a Worker: queues, scheduling, sandboxing, observability, agents, business logic, devices, and even code executing in a browser. @@ -139,8 +139,8 @@ invocations through Triggers. Trigger types come from connected Workers. A Worker that can source events declares one or more -trigger types alongside their configuration schemas. The iii-http Worker provides the `http` trigger -type. The iii-cron Worker provides the `cron` trigger type. The iii-state Worker provides the +trigger types alongside their configuration schemas. The http Worker provides the `http` trigger +type. The cron Worker provides the `cron` trigger type. The state Worker provides the `state` trigger type. A Trigger of a given type can only be registered while a Worker advertising that type is connected, because that Worker is what produces the events that fire it. @@ -173,9 +173,9 @@ result. Synchronous invocations are appropriate when the caller needs the value returns. Fire-and-forget is for side-effect work where the caller does not need to wait. - Workers can also define their own `TriggerAction`s. The iii-queue Worker provides + Workers can also define their own `TriggerAction`s. The queue Worker provides `TriggerAction.Enqueue({queue})`, which routes the invocation through a named queue with retries. - See iii-queue for the queue mechanics. + See queue for the queue mechanics. ### Trigger lifecycle @@ -193,17 +193,17 @@ The Quickstart tutorial invokes Functions with Triggers in three different ways: the invocation to whatever Worker provides `math::add`. 1. The SDK call `worker.trigger({ function_id: 'math::add', ... })` is another version of the same idea: one Function inside one Worker firing a Trigger that invokes another Function, routed - through the Engine just like the CLI version. + through the Engine like the CLI version. Both paths work against any registered Function without registering an explicit Trigger; every `registerFunction()` inherently gets a Trigger that can be invoked with these two methods. -1. The HTTP Trigger added by the `iii-http` Worker is done through `worker.registerTrigger()` and is +1. The HTTP Trigger added by the `http` Worker is done through `worker.registerTrigger()` and is the common reactive way to implement Triggers. - In this example `iii-http` owns the HTTP socket; when a request arrives at + In this example `http` owns the HTTP socket; when a request arrives at `POST /math/add-two-numbers` the following happens: - 1. `iii-http` looks up the matching Trigger and fires a request targeting the `math::add` + 1. `http` looks up the matching Trigger and fires a request targeting the `math::add` Function. 1. The Engine receives the request and routes the invocation to `caller-worker`. 1. Finally the response flows back the same way. The `math::add` Function never sees an HTTP @@ -274,7 +274,7 @@ provides. When a Worker disconnects, the Engine removes its Functions, cancels a invocations of those Functions, and notifies the rest of the system that the topology changed. Routing is independent of language, runtime, and location. The Engine does not need to know where -`math::add` is running in Docker, on a Raspberry Pi, or in a browser tab. It just knows that _some_ +`math::add` is running in Docker, on a Raspberry Pi, or in a browser tab. It knows that _some_ Worker provides it. The same tutorial can be redeployed across different runtimes without touching the function code. diff --git a/docs/next/understanding-iii/index.mdx.skill.md b/docs/next/understanding-iii/index.mdx.skill.md index 446692440f..2c07ce7f3f 100644 --- a/docs/next/understanding-iii/index.mdx.skill.md +++ b/docs/next/understanding-iii/index.mdx.skill.md @@ -49,7 +49,7 @@ The Quickstart tutorial produces a running system with two Workers connected to 1. `caller-worker` is a TypeScript Worker that registers `math::add_two_numbers`, which calls `math::add` through the Engine. -By the end of the Quickstart, the system also includes the `iii-state` and `iii-http` Workers, an +By the end of the Quickstart, the system also includes the `state` and `http` Workers, an HTTP Trigger that exposes `math::add_two_numbers` at `POST /math/add-two-numbers`, and a key-value scope named `math` holding a `running_total`. @@ -62,8 +62,8 @@ graph TD Engine <--> Math["math-worker (Python) math::add"] Engine <--> Caller["caller-worker (TypeScript) math::add_two_numbers"] - Engine <--> State["iii-state"] - Engine <--> HttpWorker["iii-http"] + Engine <--> State["state"] + Engine <--> HttpWorker["http"] ``` Every arrow is a WebSocket connection between a Worker and the Engine. There is no direct @@ -73,7 +73,7 @@ to `math-worker`. ## Workers -Workers are what actually do things in an iii system. Every category of capability is built as a +Workers do the work in an iii system. Every category of capability is built as a Worker: queues, scheduling, sandboxing, observability, agents, business logic, devices, and even code executing in a browser. @@ -135,8 +135,8 @@ invocations through Triggers. Trigger types come from connected Workers. A Worker that can source events declares one or more -trigger types alongside their configuration schemas. The iii-http Worker provides the `http` trigger -type. The iii-cron Worker provides the `cron` trigger type. The iii-state Worker provides the +trigger types alongside their configuration schemas. The http Worker provides the `http` trigger +type. The cron Worker provides the `cron` trigger type. The state Worker provides the `state` trigger type. A Trigger of a given type can only be registered while a Worker advertising that type is connected, because that Worker is what produces the events that fire it. @@ -169,9 +169,9 @@ result. Synchronous invocations are appropriate when the caller needs the value returns. Fire-and-forget is for side-effect work where the caller does not need to wait. - Workers can also define their own `TriggerAction`s. The iii-queue Worker provides + Workers can also define their own `TriggerAction`s. The queue Worker provides `TriggerAction.Enqueue({queue})`, which routes the invocation through a named queue with retries. - See iii-queue for the queue mechanics. + See queue for the queue mechanics. ### Trigger lifecycle @@ -189,17 +189,17 @@ The Quickstart tutorial invokes Functions with Triggers in three different ways: the invocation to whatever Worker provides `math::add`. 1. The SDK call `worker.trigger({ function_id: 'math::add', ... })` is another version of the same idea: one Function inside one Worker firing a Trigger that invokes another Function, routed - through the Engine just like the CLI version. + through the Engine like the CLI version. Both paths work against any registered Function without registering an explicit Trigger; every `registerFunction()` inherently gets a Trigger that can be invoked with these two methods. -1. The HTTP Trigger added by the `iii-http` Worker is done through `worker.registerTrigger()` and is +1. The HTTP Trigger added by the `http` Worker is done through `worker.registerTrigger()` and is the common reactive way to implement Triggers. - In this example `iii-http` owns the HTTP socket; when a request arrives at + In this example `http` owns the HTTP socket; when a request arrives at `POST /math/add-two-numbers` the following happens: - 1. `iii-http` looks up the matching Trigger and fires a request targeting the `math::add` + 1. `http` looks up the matching Trigger and fires a request targeting the `math::add` Function. 1. The Engine receives the request and routes the invocation to `caller-worker`. 1. Finally the response flows back the same way. The `math::add` Function never sees an HTTP @@ -270,7 +270,7 @@ provides. When a Worker disconnects, the Engine removes its Functions, cancels a invocations of those Functions, and notifies the rest of the system that the topology changed. Routing is independent of language, runtime, and location. The Engine does not need to know where -`math::add` is running in Docker, on a Raspberry Pi, or in a browser tab. It just knows that _some_ +`math::add` is running in Docker, on a Raspberry Pi, or in a browser tab. It knows that _some_ Worker provides it. The same tutorial can be redeployed across different runtimes without touching the function code. diff --git a/docs/next/using-iii/configuration.mdx b/docs/next/using-iii/configuration.mdx index 5b1dd97038..e28230135d 100644 --- a/docs/next/using-iii/configuration.mdx +++ b/docs/next/using-iii/configuration.mdx @@ -16,7 +16,7 @@ iii splits configuration across two layers: [Engine configuration](./engine#engine-configuration). - **The `configuration` worker** owns _each worker's runtime settings_. It is a schema-validated, reactive registry that ships enabled by default: every worker registers its settings schema under - its own entry (`iii-http`, `iii-state`, `iii-queue`, ...), and every change is validated against + its own entry (`http`, `state`, `queue`, ...), and every change is validated against that schema and applied to the running worker. Most settings apply immediately; a few take effect at the next engine start (see [How changes apply](#how-changes-apply)). @@ -46,16 +46,16 @@ With the default `fs` adapter, every configuration entry is one YAML file named ``` config/ - iii-http.yaml - iii-queue.yaml - iii-state.yaml + http.yaml + queue.yaml + state.yaml ... ``` Each file carries the entry's identity plus its current value: -```yaml config/iii-http.yaml -id: iii-http +```yaml config/http.yaml +id: http name: HTTP description: HTTP server settings — host/port binding, CORS, request timeout, concurrency limit, and global @@ -98,15 +98,15 @@ own automation: ```bash - iii trigger configuration::get --json '{"id": "iii-http"}' - iii trigger configuration::set --json '{"id": "iii-http", "value": {"port": 8080, "host": "127.0.0.1"}}' + iii trigger configuration::get --json '{"id": "http"}' + iii trigger configuration::set --json '{"id": "http", "value": {"port": 8080, "host": "127.0.0.1"}}' ``` ```typescript await worker.trigger({ function_id: "configuration::set", - payload: { id: "iii-http", value: { port: 8080, host: "127.0.0.1" } }, + payload: { id: "http", value: { port: 8080, host: "127.0.0.1" } }, }); ``` @@ -127,10 +127,10 @@ a string. Pass `raw: true` to `configuration::get` to read the stored template f ## How changes apply -Most settings hot-apply the moment they change: `iii-http` swaps CORS, timeout, and middleware +Most settings hot-apply the moment they change: `http` swaps CORS, timeout, and middleware without dropping the listener, and binds a new `host`/`port` before releasing the old one. A few fields are restart-tier: the change is recorded, logged, and takes effect at the next engine start -(for example `iii-state`'s storage adapter). Each worker's page on +(for example `state`'s storage adapter). Each worker's page on [workers.iii.dev](https://workers.iii.dev/) documents its settings and how they apply. ## Changing where configuration is stored diff --git a/docs/next/using-iii/configuration.mdx.skill.md b/docs/next/using-iii/configuration.mdx.skill.md index 44c851d11a..448dfad97b 100644 --- a/docs/next/using-iii/configuration.mdx.skill.md +++ b/docs/next/using-iii/configuration.mdx.skill.md @@ -12,7 +12,7 @@ iii splits configuration across two layers: [Engine configuration](./engine#engine-configuration). - **The `configuration` worker** owns _each worker's runtime settings_. It is a schema-validated, reactive registry that ships enabled by default: every worker registers its settings schema under - its own entry (`iii-http`, `iii-state`, `iii-queue`, ...), and every change is validated against + its own entry (`http`, `state`, `queue`, ...), and every change is validated against that schema and applied to the running worker. Most settings apply immediately; a few take effect at the next engine start (see [How changes apply](#how-changes-apply)). @@ -42,16 +42,16 @@ With the default `fs` adapter, every configuration entry is one YAML file named ``` config/ - iii-http.yaml - iii-queue.yaml - iii-state.yaml + http.yaml + queue.yaml + state.yaml ... ``` Each file carries the entry's identity plus its current value: -```yaml config/iii-http.yaml -id: iii-http +```yaml config/http.yaml +id: http name: HTTP description: HTTP server settings — host/port binding, CORS, request timeout, concurrency limit, and global @@ -94,15 +94,15 @@ own automation: ```bash - iii trigger configuration::get --json '{"id": "iii-http"}' - iii trigger configuration::set --json '{"id": "iii-http", "value": {"port": 8080, "host": "127.0.0.1"}}' + iii trigger configuration::get --json '{"id": "http"}' + iii trigger configuration::set --json '{"id": "http", "value": {"port": 8080, "host": "127.0.0.1"}}' ``` ```typescript await worker.trigger({ function_id: "configuration::set", - payload: { id: "iii-http", value: { port: 8080, host: "127.0.0.1" } }, + payload: { id: "http", value: { port: 8080, host: "127.0.0.1" } }, }); ``` @@ -123,10 +123,10 @@ a string. Pass `raw: true` to `configuration::get` to read the stored template f ## How changes apply -Most settings hot-apply the moment they change: `iii-http` swaps CORS, timeout, and middleware +Most settings hot-apply the moment they change: `http` swaps CORS, timeout, and middleware without dropping the listener, and binds a new `host`/`port` before releasing the old one. A few fields are restart-tier: the change is recorded, logged, and takes effect at the next engine start -(for example `iii-state`'s storage adapter). Each worker's page on +(for example `state`'s storage adapter). Each worker's page on [workers.iii.dev](https://workers.iii.dev/) documents its settings and how they apply. ## Changing where configuration is stored diff --git a/docs/next/using-iii/engine.mdx b/docs/next/using-iii/engine.mdx index 4edf66b4a5..ab82d89b8b 100644 --- a/docs/next/using-iii/engine.mdx +++ b/docs/next/using-iii/engine.mdx @@ -29,12 +29,12 @@ defined by that worker and is read once, as a first-boot seed. ```yaml workers: - - name: iii-http + - name: http config: port: 3111 host: 127.0.0.1 - - name: iii-state + - name: state config: adapter: name: kv @@ -78,7 +78,7 @@ see [Configuration / Environment variables in values](./configuration#environmen ```yaml workers: - - name: iii-http + - name: http config: port: ${HTTP_PORT:3111} host: ${HTTP_HOST:127.0.0.1} diff --git a/docs/next/using-iii/engine.mdx.skill.md b/docs/next/using-iii/engine.mdx.skill.md index e7d1189e65..63315b98ae 100644 --- a/docs/next/using-iii/engine.mdx.skill.md +++ b/docs/next/using-iii/engine.mdx.skill.md @@ -21,12 +21,12 @@ defined by that worker and is read once, as a first-boot seed. ```yaml workers: - - name: iii-http + - name: http config: port: 3111 host: 127.0.0.1 - - name: iii-state + - name: state config: adapter: name: kv @@ -70,7 +70,7 @@ see [Configuration / Environment variables in values](./configuration#environmen ```yaml workers: - - name: iii-http + - name: http config: port: ${HTTP_PORT:3111} host: ${HTTP_HOST:127.0.0.1} diff --git a/docs/next/using-iii/functions.mdx b/docs/next/using-iii/functions.mdx index f57f07447d..905f1964d8 100644 --- a/docs/next/using-iii/functions.mdx +++ b/docs/next/using-iii/functions.mdx @@ -64,7 +64,7 @@ and returns the result. A function runs when a trigger fires. The same function can be invoked from many trigger types at once: direct CLI calls (`iii trigger`), in-process SDK calls (`worker.trigger`), or bindings to -event-source workers like iii-http, iii-cron, iii-queue, iii-state, and iii-stream. All paths leave +event-source workers like http, cron, queue, state, and iii-stream. All paths leave the handler unchanged. The two most common ways to invoke a function directly are from worker code with `worker.trigger` or @@ -87,7 +87,7 @@ fire. Pass a different `TriggerAction` to change that. function_id: "math::add", payload: { a: 2, b: 3 }, // action: TriggerAction.Void(), // fire-and-forget - // action: TriggerAction.Enqueue({ queue: "math" }), // route through iii-queue + // action: TriggerAction.Enqueue({ queue: "math" }), // route through queue }); ``` @@ -100,7 +100,7 @@ fire. Pass a different `TriggerAction` to change that. "function_id": "math::add", "payload": {"a": 2, "b": 3}, # "action": TriggerAction.Void(), # fire-and-forget - # "action": TriggerAction.Enqueue(queue="math"), # route through iii-queue + # "action": TriggerAction.Enqueue(queue="math"), # route through queue }) # result = await worker.trigger_async({...}) # awaitable form for asyncio callers ``` @@ -118,7 +118,7 @@ fire. Pass a different `TriggerAction` to change that. payload: json!({ "a": 2, "b": 3 }), action: None, // action: Some(TriggerAction::Void), // fire-and-forget - // action: Some(TriggerAction::Enqueue { queue: "math".to_string() }), // route through iii-queue + // action: Some(TriggerAction::Enqueue { queue: "math".to_string() }), // route through queue timeout_ms: None, }) .await?; @@ -134,7 +134,7 @@ Some common actions are: - **`TriggerAction.Void()`**. Fire-and-forget. The call returns immediately; the function still runs but the caller doesn't see the result. - **`TriggerAction.Enqueue({ queue })`**. Provided by - [iii-queue](https://workers.iii.dev/workers/iii-queue). Routes the invocation through a named + [queue](https://workers.iii.dev/workers/queue). Routes the invocation through a named queue with retries; the call returns once the message is enqueued. @@ -213,12 +213,12 @@ Each of these is published by a separate worker. Function ids, payload shapes, a behaviour are in the worker's own docs at [workers.iii.dev](https://workers.iii.dev): - **State**: KV-style state with scoped namespaces and reactive triggers on create/update/delete. - See [iii-state](https://workers.iii.dev/workers/iii-state). + See [state](https://workers.iii.dev/workers/state). - **Stream**: Real-time push to connected clients over WebSocket. See [iii-stream](https://workers.iii.dev/workers/iii-stream). - **Queue**: Durable, ordered job processing with retries, concurrency limits, and a dead-letter - queue. See [iii-queue](https://workers.iii.dev/workers/iii-queue). + queue. See [queue](https://workers.iii.dev/workers/queue). - **Pub/Sub**: Lightweight in-engine topic subscription for fan-out without durability guarantees. - See [iii-pubsub](https://workers.iii.dev/workers/iii-pubsub). + See [pubsub](https://workers.iii.dev/workers/pubsub). - **Observability**: Traces, logs, metrics, alerts, sampling rules, and rollups. See [iii-observability](https://workers.iii.dev/workers/iii-observability). diff --git a/docs/next/using-iii/functions.mdx.skill.md b/docs/next/using-iii/functions.mdx.skill.md index 0ea12b73e8..d6521c1148 100644 --- a/docs/next/using-iii/functions.mdx.skill.md +++ b/docs/next/using-iii/functions.mdx.skill.md @@ -60,7 +60,7 @@ and returns the result. A function runs when a trigger fires. The same function can be invoked from many trigger types at once: direct CLI calls (`iii trigger`), in-process SDK calls (`worker.trigger`), or bindings to -event-source workers like iii-http, iii-cron, iii-queue, iii-state, and iii-stream. All paths leave +event-source workers like http, cron, queue, state, and iii-stream. All paths leave the handler unchanged. The two most common ways to invoke a function directly are from worker code with `worker.trigger` or @@ -83,7 +83,7 @@ fire. Pass a different `TriggerAction` to change that. function_id: "math::add", payload: { a: 2, b: 3 }, // action: TriggerAction.Void(), // fire-and-forget - // action: TriggerAction.Enqueue({ queue: "math" }), // route through iii-queue + // action: TriggerAction.Enqueue({ queue: "math" }), // route through queue }); ``` @@ -96,7 +96,7 @@ fire. Pass a different `TriggerAction` to change that. "function_id": "math::add", "payload": {"a": 2, "b": 3}, # "action": TriggerAction.Void(), # fire-and-forget - # "action": TriggerAction.Enqueue(queue="math"), # route through iii-queue + # "action": TriggerAction.Enqueue(queue="math"), # route through queue }) # result = await worker.trigger_async({...}) # awaitable form for asyncio callers ``` @@ -114,7 +114,7 @@ fire. Pass a different `TriggerAction` to change that. payload: json!({ "a": 2, "b": 3 }), action: None, // action: Some(TriggerAction::Void), // fire-and-forget - // action: Some(TriggerAction::Enqueue { queue: "math".to_string() }), // route through iii-queue + // action: Some(TriggerAction::Enqueue { queue: "math".to_string() }), // route through queue timeout_ms: None, }) .await?; @@ -130,7 +130,7 @@ Some common actions are: - **`TriggerAction.Void()`**. Fire-and-forget. The call returns immediately; the function still runs but the caller doesn't see the result. - **`TriggerAction.Enqueue({ queue })`**. Provided by - [iii-queue](https://workers.iii.dev/workers/iii-queue). Routes the invocation through a named + [queue](https://workers.iii.dev/workers/queue). Routes the invocation through a named queue with retries; the call returns once the message is enqueued. @@ -209,12 +209,12 @@ Each of these is published by a separate worker. Function ids, payload shapes, a behaviour are in the worker's own docs at [workers.iii.dev](https://workers.iii.dev): - **State**: KV-style state with scoped namespaces and reactive triggers on create/update/delete. - See [iii-state](https://workers.iii.dev/workers/iii-state). + See [state](https://workers.iii.dev/workers/state). - **Stream**: Real-time push to connected clients over WebSocket. See [iii-stream](https://workers.iii.dev/workers/iii-stream). - **Queue**: Durable, ordered job processing with retries, concurrency limits, and a dead-letter - queue. See [iii-queue](https://workers.iii.dev/workers/iii-queue). + queue. See [queue](https://workers.iii.dev/workers/queue). - **Pub/Sub**: Lightweight in-engine topic subscription for fan-out without durability guarantees. - See [iii-pubsub](https://workers.iii.dev/workers/iii-pubsub). + See [pubsub](https://workers.iii.dev/workers/pubsub). - **Observability**: Traces, logs, metrics, alerts, sampling rules, and rollups. See [iii-observability](https://workers.iii.dev/workers/iii-observability). diff --git a/docs/next/using-iii/triggers.mdx b/docs/next/using-iii/triggers.mdx index 1c2ac90e7a..a10f40ed37 100644 --- a/docs/next/using-iii/triggers.mdx +++ b/docs/next/using-iii/triggers.mdx @@ -83,7 +83,7 @@ You bind triggers to functions via the `function_id`. The trigger declares its ` Per-type configuration is documented in each worker's Worker Docs (e.g. -[iii-http](https://workers.iii.dev/workers/iii-http) for the `http` type). +[http](https://workers.iii.dev/workers/http) for the `http` type). ### Trigger metadata diff --git a/docs/next/using-iii/triggers.mdx.skill.md b/docs/next/using-iii/triggers.mdx.skill.md index 6c922b784d..ad1afbee49 100644 --- a/docs/next/using-iii/triggers.mdx.skill.md +++ b/docs/next/using-iii/triggers.mdx.skill.md @@ -81,7 +81,7 @@ You bind triggers to functions via the `function_id`. The trigger declares its ` Per-type configuration is documented in each worker's Worker Docs (e.g. -[iii-http](https://workers.iii.dev/workers/iii-http) for the `http` type). +[http](https://workers.iii.dev/workers/http) for the `http` type). ### Trigger metadata diff --git a/docs/next/using-iii/workers-registry.mdx b/docs/next/using-iii/workers-registry.mdx index e4593ef4bb..96b5ae5c33 100644 --- a/docs/next/using-iii/workers-registry.mdx +++ b/docs/next/using-iii/workers-registry.mdx @@ -23,7 +23,7 @@ Workers can also be found on Docker and OCI-compatible registries. worker's first boot, and managed through the [configuration worker](./configuration) afterwards. ```bash -iii worker add iii-state # Downloads and adds a worker from iii registry +iii worker add state # Downloads and adds a worker from iii registry iii worker add ./workers/my_worker # Adds a local worker created with `iii worker init` iii worker add ghcr.io/org/worker:tag # Adds a local worker from a Docker or OCI image registry ``` diff --git a/docs/next/using-iii/workers-registry.mdx.skill.md b/docs/next/using-iii/workers-registry.mdx.skill.md index 8f08d99494..c2cd690a42 100644 --- a/docs/next/using-iii/workers-registry.mdx.skill.md +++ b/docs/next/using-iii/workers-registry.mdx.skill.md @@ -21,7 +21,7 @@ Workers can also be found on Docker and OCI-compatible registries. worker's first boot, and managed through the [configuration worker](./configuration) afterwards. ```bash -iii worker add iii-state # Downloads and adds a worker from iii registry +iii worker add state # Downloads and adds a worker from iii registry iii worker add ./workers/my_worker # Adds a local worker created with `iii worker init` iii worker add ghcr.io/org/worker:tag # Adds a local worker from a Docker or OCI image registry ``` diff --git a/docs/next/using-iii/workers.mdx b/docs/next/using-iii/workers.mdx index 7613f79899..fb5110d1e6 100644 --- a/docs/next/using-iii/workers.mdx +++ b/docs/next/using-iii/workers.mdx @@ -78,7 +78,7 @@ workers which you can learn more about in `iii worker add ` installs a worker into your project: ```bash -iii worker add iii-state # Downloads and adds a worker from iii registry +iii worker add state # Downloads and adds a worker from iii registry iii worker add ./workers/my_worker # Adds a local worker created with `iii worker init` iii worker add ghcr.io/org/worker:tag # Pulls and adds a worker from a Docker or OCI image registry ``` @@ -191,7 +191,7 @@ and its workers. ## Available functions and triggers Functions and triggers come from connected workers. To use a trigger of a given type, you need the -worker that provides it to be connected. For example if you add `http` triggers via the iii-http +worker that provides it to be connected. For example if you add `http` triggers via the http worker then you can now expose endpoints for your function as you would in a web framework like Express or FastAPI. @@ -206,7 +206,7 @@ Installing without a version specifier picks the latest release. Append `@` installs a worker into your project: ```bash -iii worker add iii-state # Downloads and adds a worker from iii registry +iii worker add state # Downloads and adds a worker from iii registry iii worker add ./workers/my_worker # Adds a local worker created with `iii worker init` iii worker add ghcr.io/org/worker:tag # Pulls and adds a worker from a Docker or OCI image registry ``` @@ -176,7 +176,7 @@ and its workers. ## Available functions and triggers Functions and triggers come from connected workers. To use a trigger of a given type, you need the -worker that provides it to be connected. For example if you add `http` triggers via the iii-http +worker that provides it to be connected. For example if you add `http` triggers via the http worker then you can now expose endpoints for your function as you would in a web framework like Express or FastAPI. @@ -191,7 +191,7 @@ Installing without a version specifier picks the latest release. Append `@