diff --git a/src/content/apps/index.yaml b/src/content/apps/index.yaml index d2b31c02269c81..9288021e2dde9b 100644 --- a/src/content/apps/index.yaml +++ b/src/content/apps/index.yaml @@ -70,9 +70,9 @@ entries: updated: 2024-06-17 - link: https://github.com/craigsdennis/shorty-dot-dev name: shrty.dev - description: A URL shortener that makes use of KV and Workers Analytics Engine. The admin interface uses Function Calling. Go Shorty! + description: A URL shortener that makes use of Workers KV and Workers Analytics Engine. The admin interface uses Function Calling. Go Shorty! tags: [AI, Hono] - products: [Workers AI, KV, Workers] + products: [Workers AI, Workers KV, Workers] languages: [TypeScript] cloudflare: true updated: 2024-07-02 @@ -200,7 +200,7 @@ entries: name: Queues Web Crawler description: An example use-case for Queues, a web crawler built on Browser Rendering and Puppeteer. The crawler finds the number of links to Cloudflare.com on the site, and archives a screenshot to Workers KV. tags: [] - products: [KV, Browser Rendering, Workers, Pages, Queues] + products: [Workers KV, Browser Rendering, Workers, Pages, Queues] languages: [TypeScript] cloudflare: true updated: 2023-06-15 @@ -303,9 +303,9 @@ entries: updated: 2024-08-12 - link: https://github.com/atinux/atinotes name: Atinotes - description: Store Markdown notes in Cloudflare KV with this full-stack application made with Nuxt & deployed on Cloudflare Pages. + description: Store Markdown notes in Cloudflare Workers KV with this full-stack application made with Nuxt & deployed on Cloudflare Pages. tags: [Nuxt] - products: [Pages, KV] + products: [Pages, Workers KV] languages: [TypeScript] cloudflare: false updated: 2024-08-12 diff --git a/src/content/changelogs/kv.yaml b/src/content/changelogs/kv.yaml index 6ff47e6cad508c..25236b91185786 100644 --- a/src/content/changelogs/kv.yaml +++ b/src/content/changelogs/kv.yaml @@ -21,7 +21,7 @@ entries: The unsuccessful keys are an array of keys that were not written successfully to all storage backends and therefore should be retried. - publish_date: "2024-08-08" - title: New KV Analytics API + title: New Workers KV Analytics API description: |- Workers KV now has a new [metrics dashboard](/kv/observability/metrics-analytics/#view-metrics-in-the-dashboard) and [analytics API](/kv/observability/metrics-analytics/#query-via-the-graphql-api) that leverages the [GraphQL Analytics API](/analytics/graphql-api/) used by many other Cloudflare products. The new analytics API provides per-account and per-namespace metrics for both operations and storage, including latency metrics for read and write operations to Workers KV. diff --git a/src/content/docs/browser-rendering/get-started/screenshots.mdx b/src/content/docs/browser-rendering/get-started/screenshots.mdx index 3144643e97565f..2fc599a9ee54ba 100644 --- a/src/content/docs/browser-rendering/get-started/screenshots.mdx +++ b/src/content/docs/browser-rendering/get-started/screenshots.mdx @@ -41,11 +41,11 @@ In your `browser-worker` directory, install Cloudflare’s [fork of Puppeteer](/ npm install @cloudflare/puppeteer --save-dev ``` -## 3. Create a KV namespace +## 3. Create a Workers KV namespace Browser Rendering can be used with other developer products. You might need a [relational database](/d1/), an [R2 bucket](/r2/) to archive your crawled pages and assets, a [Durable Object](/durable-objects/) to keep your browser instance alive and share it with multiple requests, or [Queues](/queues/) to handle your jobs asynchronous. -For the purpose of this guide, you are going to use a [KV store](/kv/concepts/kv-namespaces/) to cache your screenshots. +For the purpose of this guide, you are going to use [Workers KV](/kv/concepts/kv-namespaces/) to cache your screenshots. Create two namespaces, one for production, and one for development. @@ -60,7 +60,7 @@ Take note of the IDs for the next step. Configure your `browser-worker` project's [`wrangler.toml`](/workers/wrangler/configuration/) file by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). Bindings allow your Workers to interact with resources on the Cloudflare developer platform. Your browser `binding` name is set by you, this guide uses the name `MYBROWSER`. Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more. -Update your `wrangler.toml` configuration file with the Browser Rendering API binding and the KV namespaces you created: +Update your `wrangler.toml` configuration file with the Browser Rendering API binding and the Workers KV namespaces you created: ```toml name = "browser-worker" @@ -157,9 +157,9 @@ export default { This Worker instantiates a browser using Puppeteer, opens a new page, navigates to what you put in the `"url"` parameter, takes a screenshot of the page, stores the screenshot in KV, closes the browser, and responds with the JPEG image of the screenshot. -If your Worker is running in production, it will store the screenshot to the production KV namespace. If you are running `wrangler dev`, it will store the screenshot to the dev KV namespace. +If your Worker is running in production, it will store the screenshot to the production Workers KV namespace. If you are running `wrangler dev`, it will store the screenshot to the dev Workers KV namespace. -If the same `"url"` is requested again, it will use the cached version in KV instead, unless it expired. +If the same `"url"` is requested again, it will use the cached version in Workers KV instead, unless it expired. ## 6. Test diff --git a/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx b/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx index ebdf8c6d533552..48d2d6f26e7075 100644 --- a/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx +++ b/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx @@ -45,7 +45,7 @@ You can set up External Evaluation rules using any API service, but to get start npx wrangler kv namespace create "KV" ``` - The command will output the binding name and KV namespace ID, for example + The command will output the binding name and Workers KV namespace ID, for example ```txt [[kv_namespaces]] diff --git a/src/content/docs/d1/platform/limits.mdx b/src/content/docs/d1/platform/limits.mdx index 4590bd26b78f1e..876d1957045ae9 100644 --- a/src/content/docs/d1/platform/limits.mdx +++ b/src/content/docs/d1/platform/limits.mdx @@ -33,7 +33,7 @@ Limits for individual queries (listed above) apply to each individual statement [^1]: The maximum storage per account can be increased by request on Workers Paid and Enterprise plans. See the guidance on limit increases on this page to request an increase. -[^2]: A single Worker script can have up to 1 MB of script metadata. A binding is defined as a binding to a resource, such as a D1 database, KV namespace, environmental variable or secret. Each resource binding is approximately 150-bytes, however environmental variables and secrets are controlled by the size of the value you provide. Excluding environmental variables, you can bind up to \~5,000 D1 databases to a single Worker script. +[^2]: A single Worker script can have up to 1 MB of script metadata. A binding is defined as a binding to a resource, such as a D1 database, Workers KV namespace, environmental variable or secret. Each resource binding is approximately 150-bytes, however environmental variables and secrets are controlled by the size of the value you provide. Excluding environmental variables, you can bind up to \~5,000 D1 databases to a single Worker script. [^3]: Requests to Cloudflare API must resolve in 30 seconds. Therefore, this duration limit also applies to the entire batch call. diff --git a/src/content/docs/d1/reference/community-projects.mdx b/src/content/docs/d1/reference/community-projects.mdx index 10bb8c4bee855b..3bd85a8c2c0c52 100644 --- a/src/content/docs/d1/reference/community-projects.mdx +++ b/src/content/docs/d1/reference/community-projects.mdx @@ -88,7 +88,7 @@ Instead of running the `wrangler d1 execute` command in your terminal every time ### L1 -`L1` is a package that brings some Cloudflare Worker ecosystem bindings into PHP and Laravel via the Cloudflare API. It provides interaction with D1 via PDO, KV and Queues, with more services to add in the future, making PHP integration with Cloudflare a real breeze. +`L1` is a package that brings some Cloudflare Worker ecosystem bindings into PHP and Laravel via the Cloudflare API. It provides interaction with D1 via PDO, Workers KV and Queues, with more services to add in the future, making PHP integration with Cloudflare a real breeze. * [GitHub](https://github.com/renoki-co/l1) * [Packagist](https://packagist.org/packages/renoki-co/l1) @@ -102,7 +102,7 @@ Staff Directory is a demo project using D1, [HonoX](https://github.com/honojs/ho ### NuxtHub -`NuxtHub` is a Nuxt module that brings Cloudflare Worker bindings into your Nuxt application with no configuration. It leverages the [Wrangler Platform Proxy](/workers/wrangler/api/#getplatformproxy) in development and direct binding in production to interact with [D1](/d1/), [KV](/kv/) and [R2](/r2/) with server composables (`hubDatabase()`, `hubKV()` and `hubBlob()`). +`NuxtHub` is a Nuxt module that brings Cloudflare Worker bindings into your Nuxt application with no configuration. It leverages the [Wrangler Platform Proxy](/workers/wrangler/api/#getplatformproxy) in development and direct binding in production to interact with [D1](/d1/), [Workers KV](/kv/) and [R2](/r2/) with server composables (`hubDatabase()`, `hubKV()` and `hubBlob()`). `NuxtHub` also provides a way to use your remote D1 database in development using the `npx nuxt dev --remote` command. diff --git a/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx b/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx index 113e93918017b1..5abd55ecdd686f 100644 --- a/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx +++ b/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx @@ -88,7 +88,7 @@ You will now create a D1 database. In Wrangler v2, there is support for the `wra npx wrangler d1 create d1-example ``` -Reference your created database in your Worker code by creating a [binding](/workers/runtime-apis/bindings/) inside of your `wrangler.toml` file, Wrangler's configuration file. Bindings allow us to access Cloudflare resources, like D1 databases, KV namespaces, and R2 buckets, using a variable name in code. In `wrangler.toml`, set up the binding `DB` and connect it to the `database_name` and `database_id`: +Reference your created database in your Worker code by creating a [binding](/workers/runtime-apis/bindings/) inside of your `wrangler.toml` file, Wrangler's configuration file. Bindings allow us to access Cloudflare resources, like D1 databases, Workers KV namespaces, and R2 buckets, using a variable name in code. In `wrangler.toml`, set up the binding `DB` and connect it to the `database_name` and `database_id`: ```toml [[ d1_databases ]] diff --git a/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx b/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx index 9b3c7de7c0daed..712aadb4a68fc6 100644 --- a/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx +++ b/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx @@ -70,7 +70,7 @@ npx wrangler d1 create staff-directory After creating your database, you will need to set up a [binding](/workers/runtime-apis/bindings/) in the Wrangler configuration file to integrate your database with your application. -This binding enables your application to interact with Cloudflare resources such as D1 databases, KV namespaces, and R2 buckets. To configure this, create a `wrangler.toml` file in your project's root directory and input the basic setup information: +This binding enables your application to interact with Cloudflare resources such as D1 databases, Workers KV namespaces, and R2 buckets. To configure this, create a `wrangler.toml` file in your project's root directory and input the basic setup information: ```toml name = "staff-directory" diff --git a/src/content/docs/data-localization/compatibility.mdx b/src/content/docs/data-localization/compatibility.mdx index c238945185342e..9ce01981b0ab47 100644 --- a/src/content/docs/data-localization/compatibility.mdx +++ b/src/content/docs/data-localization/compatibility.mdx @@ -139,6 +139,6 @@ The table below provides a summary of the Data Localization Suite product's beha [^31]: DLP is part of Gateway HTTP, however, [DLP datasets](/cloudflare-one/policies/data-loss-prevention/datasets/#use-dlp-datasets) are not available outside US region when using Customer Metadata Boundary. [^32]: Dashboard Analytics are empty when using CMB outside the US region. Use Logpush instead. [^33]: [Outgoing zone transfers](/dns/zone-setups/zone-transfers/cloudflare-as-primary/) will carry Earth region proxy IPs, thus making regional service dysfunctional when non-Cloudflare nameservers respond to the DNS queries. -[^34]: Jurisdictional Restrictions (storage) for Workers KV pairs is not supported today. +[^34]: Jurisdictional Restrictions (storage) for Workers KV is not supported today. [^35]: Logs / Analytics not available outside US region when using Customer Metadata Boundary. Jurisdictional Restrictions (storage) options are not supported today. [^36]: Only when using a [Custom Domain](/images/manage-images/serve-images/serve-from-custom-domains/) set to a region. diff --git a/src/content/docs/dns/manage-dns-records/how-to/batch-record-changes.mdx b/src/content/docs/dns/manage-dns-records/how-to/batch-record-changes.mdx index 47f73cddfd61bf..74a98bf52f77d4 100644 --- a/src/content/docs/dns/manage-dns-records/how-to/batch-record-changes.mdx +++ b/src/content/docs/dns/manage-dns-records/how-to/batch-record-changes.mdx @@ -10,7 +10,7 @@ import { GlossaryTooltip, Example, Render } from "~/components"; Cloudflare allows you to apply several changes to your zone records in just one action. You can [use the dashboard](#use-the-dashboard) to delete DNS records or update their proxy status in bulk, or [use the API](#use-the-api) to perform further batched operations. :::caution[Propagation through the Cloudflare network] -Although Cloudflare will execute the batched operations in a single [database transaction](https://en.wikipedia.org/wiki/Database_transaction), Cloudflare's distributed KV store must treat each record change as a single key-value pair. This means that the propagation of changes is not atomic. Refer to our [blog post](https://blog.cloudflare.com/batched-dns-changes/) for details. +Although Cloudflare will execute the batched operations in a single [database transaction](https://en.wikipedia.org/wiki/Database_transaction), Cloudflare's distributed key-value store must treat each record change as a single key-value pair. This means that the propagation of changes is not atomic. Refer to our [blog post](https://blog.cloudflare.com/batched-dns-changes/) for details. ::: ## Availability and limits @@ -91,7 +91,7 @@ Within each of these four lists, each individual action is executed following th ### Aspects to consider :::caution[Propagation through the Cloudflare network] -Although Cloudflare will execute the batched operations in a single [database transaction](https://en.wikipedia.org/wiki/Database_transaction), Cloudflare's distributed KV store must treat each record change as a single key-value pair. This means that the propagation of changes is not atomic. Refer to our [blog post](https://blog.cloudflare.com/batched-dns-changes/) for details. +Although Cloudflare will execute the batched operations in a single [database transaction](https://en.wikipedia.org/wiki/Database_transaction), Cloudflare's distributed key-value store must treat each record change as a single key-value pair. This means that the propagation of changes is not atomic. Refer to our [blog post](https://blog.cloudflare.com/batched-dns-changes/) for details. ::: For each operation that you list in the `/batch` request body, consider the required information and how unspecified fields will behave: diff --git a/src/content/docs/durable-objects/api/sql-storage.mdx b/src/content/docs/durable-objects/api/sql-storage.mdx index 293ea6c05e81dd..81085063c7a370 100644 --- a/src/content/docs/durable-objects/api/sql-storage.mdx +++ b/src/content/docs/durable-objects/api/sql-storage.mdx @@ -37,7 +37,7 @@ export class MyDurableObject extends DurableObject { SQL API methods accessed with `ctx.storage.sql` are only allowed on [Durable Object classes with SQLite storage backend](/durable-objects/reference/durable-objects-migrations/#enable-sqlite-storage-backend-on-new-durable-object-class-migration) and will return an error if called on Durable Object classes with a key-value storage backend. ::: -Specifically for Durable Object classes with SQLite storage backend, KV operations which were previously asynchronous (for example, [`get`](/durable-objects/api/storage-api/#get), [`put`](/durable-objects/api/storage-api/#put), [`delete`](/durable-objects/api/storage-api/#delete), [`deleteAll`](/durable-objects/api/storage-api/#deleteall), [`list`](/durable-objects/api/storage-api/#list)) are synchronous, even though they return promises. These methods will have completed their operations before they return the promise. +Specifically for Durable Object classes with SQLite storage backend, key-value operations which were previously asynchronous (for example, [`get`](/durable-objects/api/storage-api/#get), [`put`](/durable-objects/api/storage-api/#put), [`delete`](/durable-objects/api/storage-api/#delete), [`deleteAll`](/durable-objects/api/storage-api/#deleteall), [`list`](/durable-objects/api/storage-api/#list)) are synchronous, even though they return promises. These methods will have completed their operations before they return the promise. ## Methods diff --git a/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx b/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx index 9206ffdc327f81..32974688b5a208 100644 --- a/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx +++ b/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx @@ -6,8 +6,8 @@ sidebar: order: 20 head: - tag: title - content: Durable Objects - Use KV within Durable Objects -description: Read and write to/from KV within a Durable Object + content: Durable Objects - Use Workers KV within Durable Objects +description: Read and write to/from Workers KV within a Durable Object --- @@ -17,7 +17,7 @@ The following Worker script shows you how to configure a ` - - The value for the requested KV pair. The response type will depend on the `type` parameter provided for the `get()` command as follows: + - The value for the requested key-value pair. The response type will depend on the `type` parameter provided for the `get()` command as follows: - `text`: A `string` (default). - `json`: An object decoded from a JSON string. - `arrayBuffer`: An [`ArrayBuffer`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer) instance. @@ -78,7 +78,7 @@ The `get()` method may return stale values. If a given key has recently been rea ### `getWithMetadata()` method -To get the value for a given key along with its metadata, call the `getWithMetadata()` method on any KV namespace you have bound to your Worker code: +To get the value for a given key along with its metadata, call the `getWithMetadata()` method on any Workers KV namespace you have bound to your Worker code: ```js env.NAMESPACE.getWithMetadata(key, type?); @@ -91,7 +91,7 @@ Metadata is a serializable value you append to each KV entry. #### Parameters - `key`: `string` - - The key of the KV pair. + - The key of the key-value pair. - `type`: `"text" | "json" | "arrayBuffer" | "stream"` - Optional. The type of the value to be returned. `text` is the default. - `options`: `{ @@ -107,7 +107,7 @@ value: string | Object | ArrayBuffer | ReadableStream | null, metadata: string | null }>` - - An object containing the value and the metadata for the requested KV pair. The type of the value attribute will depend on the `type` parameter provided for the `getWithMetadata()` command as follows: + - An object containing the value and the metadata for the requested key-value pair. The type of the value attribute will depend on the `type` parameter provided for the `getWithMetadata()` command as follows: - `text`: A `string` (default). - `json`: An object decoded from a JSON string. - `arrayBuffer`: An [`ArrayBuffer`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer) instance. @@ -164,7 +164,7 @@ The `cacheTtl` parameter must be an integer greater than or equal to `60`, which The effective `cacheTtl` of an already cached item can be reduced by getting it again with a lower `cacheTtl`. For example, if you did `NAMESPACE.get(key, {cacheTtl: 86400})` but later realized that caching for 24 hours was too long, you could `NAMESPACE.get(key, {cacheTtl: 300})` or even `NAMESPACE.get(key)` and it would check for newer data to respect the provided `cacheTtl`, which defaults to 60 seconds. -## Other methods to access KV +## Other methods to access Workers KV You can [read key-value pairs from the command line with Wrangler](/kv/reference/kv-commands/#get) and [from the REST API](/api/operations/workers-kv-namespace-read-key-value-pair). diff --git a/src/content/docs/kv/api/write-key-value-pairs.mdx b/src/content/docs/kv/api/write-key-value-pairs.mdx index 753441be27353a..f47955b7936e1c 100644 --- a/src/content/docs/kv/api/write-key-value-pairs.mdx +++ b/src/content/docs/kv/api/write-key-value-pairs.mdx @@ -5,7 +5,7 @@ sidebar: order: 5 --- -To create a new key-value pair, or to update the value for a particular key, call the `put()` method of the [KV binding](/kv/concepts/kv-bindings/) on any [KV namespace](/kv/concepts/kv-namespaces/) you have bound to your Worker code: +To create a new key-value pair, or to update the value for a particular key, call the `put()` method of the [Workers KV binding](/kv/concepts/kv-bindings/) on any [Workers KV namespace](/kv/concepts/kv-namespaces/) you have bound to your Worker code: ```js env.NAMESPACE.put(key, value); @@ -33,13 +33,13 @@ export default { ## Reference -The following method is provided to write to KV: +The following method is provided to write to Workers KV: - [put()](#put-method) ### `put()` method -To create a new key-value pair, or to update the value for a particular key, call the `put()` method on any KV namespace you have bound to your Worker code: +To create a new key-value pair, or to update the value for a particular key, call the `put()` method on any Workers KV namespace you have bound to your Worker code: ```js env.NAMESPACE.put(key, value, options?); @@ -74,27 +74,27 @@ The put() method returns a Promise that you should `await` on to verify a succes ### Concurrent writes to the same key -Due to the eventually consistent nature of KV, concurrent writes to the same key can end up overwriting one another. It is a common pattern to write data from a single process with Wrangler or the API. This avoids competing concurrent writes because of the single stream. All data is still readily available within all Workers bound to the namespace. +Due to the eventually consistent nature of Workers KV, concurrent writes to the same key can end up overwriting one another. It is a common pattern to write data from a single process with Wrangler or the API. This avoids competing concurrent writes because of the single stream. All data is still readily available within all Workers bound to the namespace. If concurrent writes are made to the same key, the last write will take precedence. Writes are immediately visible to other requests in the same global network location, but can take up to 60 seconds (or the value of the `cacheTtl` parameter of the `get()` or `getWithMetadata()` methods) to be visible in other parts of the world. -Refer to [How KV works](/kv/concepts/how-kv-works/) for more information on this topic. +Refer to [How Workers KV works](/kv/concepts/how-kv-works/) for more information on this topic. ### Write data in bulk Write more than one key-value pair at a time with Wrangler or [via the REST API](/api/operations/workers-kv-namespace-write-multiple-key-value-pairs). -The bulk API can accept up to 10,000 KV pairs at once. +The bulk API can accept up to 10,000 key-value pairs at once. -A `key` and a `value` are required for each KV pair. The entire request size must be less than 100 megabytes. Bulk writes are not supported using the [KV binding](/kv/concepts/kv-bindings/). +A `key` and a `value` are required for each key-value pair. The entire request size must be less than 100 megabytes. Bulk writes are not supported using the [Workers KV binding](/kv/concepts/kv-bindings/). ### Expiring keys KV offers the ability to create keys that automatically expire. You may configure expiration to occur either at a particular point in time, or after a certain amount of time has passed since the key was last modified. -Once the expiration time of an expiring key is reached, it will be deleted from the system. After its deletion, attempts to read the key will behave as if the key does not exist. The deleted key will not count against the KV namespace’s storage usage for billing purposes. +Once the expiration time of an expiring key is reached, it will be deleted from the system. After its deletion, attempts to read the key will behave as if the key does not exist. The deleted key will not count against the Workers KV namespace’s storage usage for billing purposes. :::note @@ -268,6 +268,6 @@ async function retryWithBackoff( } ``` -## Other methods to access KV +## Other methods to access Workers KV You can also [write key-value pairs from the command line with Wrangler](/kv/reference/kv-commands/#create) and [write data via the REST API](/api/operations/workers-kv-namespace-write-key-value-pair-with-metadata). diff --git a/src/content/docs/kv/concepts/how-kv-works.mdx b/src/content/docs/kv/concepts/how-kv-works.mdx index 6b2611b8f76f40..38eaadaadc3100 100644 --- a/src/content/docs/kv/concepts/how-kv-works.mdx +++ b/src/content/docs/kv/concepts/how-kv-works.mdx @@ -1,21 +1,21 @@ --- pcx_content_type: concept -title: How KV works +title: How Workers KV works sidebar: order: 6 --- -KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflare's data centers after access. +Workers KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflare's data centers after access. -KV supports exceptionally high read volumes with low latency, making it possible to build highly dynamic APIs. +Workers KV supports exceptionally high read volumes with low latency, making it possible to build highly dynamic APIs. While reads are periodically revalidated in the background, requests which are not in cache and need to hit the centralized back end can experience high latencies. -## Write data to KV and read data from KV +## Write data to Workers KV and read data from Workers KV -When you write to KV, your data is written to central data stores. Your data is not sent automatically to every location’s cache. +When you write to Workers KV, your data is written to central data stores. Your data is not sent automatically to every location’s cache. -![Your data is written to central data stores when you write to KV.](~/assets/images/kv/kv-write.svg) +![Your data is written to central data stores when you write to Workers KV.](~/assets/images/kv/kv-write.svg) Initial reads from a location do not have a cached value. Data must be read from the nearest regional tier, followed by a central tier, degrading finally to the central stores for a truly cold global read. While the first access is slow globally, subsequent requests are faster, especially if requests are concentrated in a single region. @@ -26,39 +26,38 @@ A hot read means that the data is cached on Cloudflare's edge network using the ![Initial reads will miss the cache and go to the nearest central data store first.](~/assets/images/kv/kv-slow-read.svg) -Frequent reads from the same location return the cached value without reading from anywhere else, resulting in the fastest response times. KV operates diligently to keep the latest value in the cache by refreshing from upper tiers and the central data stores in the background. +Frequent reads from the same location return the cached value without reading from anywhere else, resulting in the fastest response times. Workers KV operates diligently to keep the latest value in the cache by refreshing from upper tiers and the central data stores in the background. Refreshing from upper tiers and the central data stores in the background is done carefully so that assets that are being accessed continue to be kept served from the cache without any stalls. ![As mentioned above, frequent reads will return a cached value.](~/assets/images/kv/kv-fast-read.svg) -KV is optimized for high-read applications. It stores data centrally and uses a hybrid push/pull-based replication to store data in cache. KV is suitable for use cases where you need to write relatively infrequently, but read quickly and frequently. Infrequently read values are pulled from other data centers or the central stores, while more popular values are cached in the data centers they are requested from. +Workers KV is optimized for high-read applications. It stores data centrally and uses a hybrid push/pull-based replication to store data in cache. Workers KV is suitable for use cases where you need to write relatively infrequently, but read quickly and frequently. Infrequently read values are pulled from other data centers or the central stores, while more popular values are cached in the data centers they are requested from. ## Performance -To improve KV performance, increase the [`cacheTtl` parameter](/kv/api/read-key-value-pairs/#cachettl-parameter) up from its default 60 seconds. +To improve Workers KV performance, increase the [`cacheTtl` parameter](/kv/api/read-key-value-pairs/#cachettl-parameter) up from its default 60 seconds. -KV achieves high performance by [caching](https://www.cloudflare.com/en-gb/learning/cdn/what-is-caching/) which makes reads eventually-consistent with writes. +Workers KV achieves high performance by [caching](https://www.cloudflare.com/en-gb/learning/cdn/what-is-caching/) which makes reads eventually-consistent with writes. Changes are usually immediately visible in the Cloudflare global network location at which they are made. Changes may take up to 60 seconds or more to be visible in other global network locations as their cached versions of the data time out. Negative lookups indicating that the key does not exist are also cached, so the same delay exists noticing a value is created as when a value is changed. -KV does not perform like an in-memory datastore, such as [Redis](https://redis.io). Accessing KV values, even when locally cached, has significantly more latency than reading a value from memory within a Worker script. +Workers KV does not perform like an in-memory datastore, such as [Redis](https://redis.io). Accessing key-value values, even when locally cached, has significantly more latency than reading a value from memory within a Worker script. ## Consistency -KV achieves high performance by being eventually-consistent. At the Cloudflare global network location at which changes are made, these changes are usually immediately visible. However, this is not guaranteed and therefore it is not advised to rely on this behaviour. In other global network locations changes may take up to 60 seconds or more to be visible as their cached versions of the data time-out. +Workers KV achieves high performance by being eventually-consistent. At the Cloudflare global network location at which changes are made, these changes are usually immediately visible. However, this is not guaranteed and therefore it is not advised to rely on this behaviour. In other global network locations changes may take up to 60 seconds or more to be visible as their cached versions of the data time-out. Visibility of changes takes longer in locations which have recently read a previous version of a given key (including reads that indicated the key did not exist, which are also cached locally). :::note -KV is not ideal for applications where you need support for atomic operations or where values must be read and written in a single transaction. -If you need stronger consistency guarantees, consider using [Durable Objects](/durable-objects/). +Workers KV is not ideal for applications where you need support for atomic operations or where values must be read and written in a single transaction. If you need stronger consistency guarantees, consider using [Durable Objects](/durable-objects/). ::: -An approach to achieve write-after-write consistency is to send all of your writes for a given KV key through a corresponding instance of a Durable Object, and then read that value from KV in other Workers. This is useful if you need more control over writes, but are satisfied with KV's read characteristics described above. +An approach to achieve write-after-write consistency is to send all of your writes for a given key-value key through a corresponding instance of a Durable Object, and then read that value from Workers KV in other Workers. This is useful if you need more control over writes, but are satisfied with Workers KV's read characteristics described above. ## Security diff --git a/src/content/docs/kv/concepts/kv-bindings.mdx b/src/content/docs/kv/concepts/kv-bindings.mdx index 8d83ffddf2cb88..5a64174a7d9940 100644 --- a/src/content/docs/kv/concepts/kv-bindings.mdx +++ b/src/content/docs/kv/concepts/kv-bindings.mdx @@ -1,23 +1,23 @@ --- pcx_content_type: concept -title: KV bindings +title: Workers KV bindings sidebar: order: 7 --- KV [bindings](/workers/runtime-apis/bindings/) allow for communication between a Worker and a KV namespace. -Configure KV bindings in the [wrangler.toml file](/workers/wrangler/configuration/). +Configure Workers KV bindings in the [wrangler.toml file](/workers/wrangler/configuration/). -## Access KV from Workers +## Access Workers KV from Workers -A [KV namespace](/kv/concepts/kv-namespaces/) is a key-value database replicated to Cloudflare's global network. +A [Workers KV namespace](/kv/concepts/kv-namespaces/) is a key-value database replicated to Cloudflare's global network. -To connect to a KV namespace from within a Worker, you must define a binding that points to the namespace's ID. +To connect to a Workers KV namespace from within a Worker, you must define a binding that points to the namespace's ID. -The name of your binding does not need to match the KV namespace's name. Instead, the binding should be a valid JavaScript identifier, because the identifier will exist as a global variable within your Worker. +The name of your binding does not need to match the Workers KV namespace's name. Instead, the binding should be a valid JavaScript identifier, because the identifier will exist as a global variable within your Worker. -A KV namespace will have a name you choose (for example, `My tasks`), and an assigned ID (for example, `06779da6940b431db6e566b4846d64db`). +A Workers KV namespace will have a name you choose (for example, `My tasks`), and an assigned ID (for example, `06779da6940b431db6e566b4846d64db`). To execute your Worker, define the binding. @@ -48,11 +48,11 @@ export default { }; ``` -## Use KV bindings when developing locally +## Use Workers KV bindings when developing locally -When you use Wrangler to develop locally with the `wrangler dev` command, Wrangler will default to using a local version of KV to avoid interfering with any of your live production data in KV. This means that reading keys that you have not written locally will return `null`. +When you use Wrangler to develop locally with the `wrangler dev` command, Wrangler will default to using a local version of Workers KV to avoid interfering with any of your live production data in Workers KV. This means that reading keys that you have not written locally will return `null`. -To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This will use the `preview_id` of the KV binding configuration in the `wrangler.toml` file. This is how a `wrangler.toml` file looks with the `preview_id` specified. +To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This will use the `preview_id` of the Workers KV binding configuration in the `wrangler.toml` file. This is how a `wrangler.toml` file looks with the `preview_id` specified. ```toml title="wrangler.toml" name = "worker" @@ -64,7 +64,7 @@ kv_namespaces = [ ] ``` -## Access KV from Durable Objects and Workers using ES modules format +## Access Workers KV from Durable Objects and Workers using ES modules format [Durable Objects](/durable-objects/) use ES modules format. Instead of a global variable, bindings are available as properties of the `env` parameter [passed to the constructor](/durable-objects/get-started/#3-write-a-class-to-define-a-durable-object). diff --git a/src/content/docs/kv/concepts/kv-namespaces.mdx b/src/content/docs/kv/concepts/kv-namespaces.mdx index 2c4f5aa005f35f..abad1d57175a93 100644 --- a/src/content/docs/kv/concepts/kv-namespaces.mdx +++ b/src/content/docs/kv/concepts/kv-namespaces.mdx @@ -1,15 +1,15 @@ --- pcx_content_type: concept -title: KV namespaces +title: Workers KV namespaces sidebar: order: 7 --- import { Type, MetaInfo } from "~/components"; -A KV namespace is a key-value database replicated to Cloudflare’s global network. +A Workers KV namespace is a key-value database replicated to Cloudflare’s global network. -Bind your KV namespaces through Wrangler or via the Cloudflare dashboard. +Bind your Workers KV namespaces through Wrangler or via the Cloudflare dashboard. :::note @@ -17,21 +17,21 @@ KV namespace IDs are public and bound to your account. ::: -## Bind your KV namespace through Wrangler +## Bind your Workers KV namespace through Wrangler -To bind KV namespaces to your Worker, assign an array of the below object to the `kv_namespaces` key. +To bind Workers KV namespaces to your Worker, assign an array of the below object to the `kv_namespaces` key. * `binding` - * The binding name used to refer to the KV namespace. + * The binding name used to refer to the Workers KV namespace. * `id` - * The ID of the KV namespace. + * The ID of the Workers KV namespace. * `preview_id` - * The ID of the KV namespace used during `wrangler dev`. + * The ID of the Workers KV namespace used during `wrangler dev`. Example: @@ -41,7 +41,7 @@ kv_namespaces = [ ] ``` -## Bind your KV namespace via the dashboard +## Bind your Workers KV namespace via the dashboard To bind the namespace to your Worker in the Cloudflare dashboard: diff --git a/src/content/docs/kv/demos.mdx b/src/content/docs/kv/demos.mdx index d9218868cc49d5..4688a55c320751 100644 --- a/src/content/docs/kv/demos.mdx +++ b/src/content/docs/kv/demos.mdx @@ -8,16 +8,16 @@ sidebar: import { ExternalResources, GlossaryTooltip, ResourcesBySelector } from "~/components" -Learn how you can use KV within your existing application and architecture. +Learn how you can use Workers KV within your existing application and architecture. ## Demo applications -Explore the following demo applications for KV. +Explore the following demo applications for Workers KV. ## Reference architectures -Explore the following reference architectures that use KV: +Explore the following reference architectures that use Workers KV: diff --git a/src/content/docs/kv/examples/index.mdx b/src/content/docs/kv/examples/index.mdx index e310442b84c800..3c06bf931925d5 100644 --- a/src/content/docs/kv/examples/index.mdx +++ b/src/content/docs/kv/examples/index.mdx @@ -11,6 +11,6 @@ sidebar: import { GlossaryTooltip, ListExamples } from "~/components"; -Explore the following examples for KV. +Explore the following examples for Workers KV. diff --git a/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx b/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx index 7fa1702a33f362..6d8a7580bb8ec9 100644 --- a/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx +++ b/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx @@ -2,7 +2,7 @@ type: example summary: Store and retrieve static assets with Workers KV tags: - - KV + - Workers KV pcx_content_type: configuration title: Store and retrieve static assets with Workers KV sidebar: @@ -53,11 +53,11 @@ npm install mimes accept-language-parser npm install --save-dev @types/accept-language-parser ``` -## 2. Create a new KV namespace +## 2. Create a new Workers KV namespace -Next, we will create a KV store. This can be done through the Cloudflare dashboard or the Wrangler CLI. For this example, we will use the Wrangler CLI. +Next, we will create a key-value store. This can be done through the Cloudflare dashboard or the Wrangler CLI. For this example, we will use the Wrangler CLI. -To create a KV store via Wrangler: +To create a key-value store via Wrangler: 1. Open your terminal and run the following command: @@ -65,7 +65,7 @@ To create a KV store via Wrangler: npx wrangler kv namespace create assets ``` - The `wrangler kv namespace create assets` subcommand creates a KV namespace by concatenating your Worker's name and the value provided for `assets`. An `id` will be randomly generated for the KV namespace. + The `wrangler kv namespace create assets` subcommand creates a Workers KV namespace by concatenating your Worker's name and the value provided for `assets`. An `id` will be randomly generated for the Workers KV namespace. ```sh npx wrangler kv namespace create assets @@ -88,9 +88,9 @@ To create a KV store via Wrangler: id = "" ``` - The [KV binding](/kv/concepts/kv-bindings/) `assets` is how your Worker will interact with the [KV namespace](/kv/concepts/kv-namespaces/). This binding will be provided as a runtime variable within your Workers code by the Workers runtime. + The [Workers KV binding](/kv/concepts/kv-bindings/) `assets` is how your Worker will interact with the [Workers KV namespace](/kv/concepts/kv-namespaces/). This binding will be provided as a runtime variable within your Workers code by the Workers runtime. - We'll also create a preview KV namespace. It is recommended to create a separate KV namespace when developing locally to avoid making changes to the production namespace. When developing locally against remote resources, the Wrangler CLI will only use the namespace specified by `preview_id` in the KV namespace configuration of the `wrangler.toml` file. + We'll also create a preview Workers KV namespace. It is recommended to create a separate Workers KV namespace when developing locally to avoid making changes to the production namespace. When developing locally against remote resources, the Wrangler CLI will only use the namespace specified by `preview_id` in the Workers KV namespace configuration of the `wrangler.toml` file. 3. In your terminal, run the following command: @@ -98,7 +98,7 @@ To create a KV store via Wrangler: npx wrangler kv namespace create assets --preview ``` - This command will create a special KV namespace that will be used only when developing with Wrangler against remote resources using `wrangler dev --remote`. + This command will create a special Workers KV namespace that will be used only when developing with Wrangler against remote resources using `wrangler dev --remote`. ```sh npx wrangler kv namespace create assets --preview @@ -122,28 +122,28 @@ To create a KV store via Wrangler: preview_id = "" ``` -We now have one KV binding that will use the production KV namespace when deployed and the preview KV namespace when developing locally against remote resources with `wrangler dev --remote`. +We now have one Workers KV binding that will use the production Workers KV namespace when deployed and the preview Workers KV namespace when developing locally against remote resources with `wrangler dev --remote`. -## 3. Store static assets in KV using Wrangler +## 3. Store static assets in Workers KV using Wrangler -To store static assets in KV, you can use the Wrangler CLI, the KV binding from a Worker application, or the KV REST API. We'll demonstrate how to use the Wrangler CLI. +To store static assets in Workers KV, you can use the Wrangler CLI, the Workers KV binding from a Worker application, or the Workers KV REST API. We will demonstrate how to use the Wrangler CLI. -For this scenario, we'll be storing a sample HTML file within our KV store. Create a new file `index.html` in the root of project with the following content: +For this scenario, we'll be storing a sample HTML file within our key-value store. Create a new file `index.html` in the root of project with the following content: ```html title="index.html" Hello World! ``` -We can then use the following Wrangler commands to create a KV pair for this file within our production and preview namespaces: +We can then use the following Wrangler commands to create a key-value pair for this file within our production and preview namespaces: ```sh npx wrangler kv key put index.html --path index.html --binding assets --preview false npx wrangler kv key put index.html --path index.html --binding assets --preview ``` -This will create a KV pair with the filename as key and the file content as value, within the our production and preview namespaces specified by your binding in your `wrangler.toml` file. +This will create a key-value pair with the filename as key and the file content as value, within the our production and preview namespaces specified by your binding in your `wrangler.toml` file. -## 4. Serve static assets from KV from your Worker application +## 4. Serve static assets from Workers KV from your Worker application Within the `index.ts` file of our Worker project, replace the contents with the following: @@ -180,7 +180,7 @@ export default { mimeType += "; charset=utf-8"; } - //get the value from the KV store and return it if found + //get the value from the key-value store and return it if found const value = await env.assets.get(key, 'arrayBuffer') if(!value){ return new Response("Not found", { @@ -197,7 +197,7 @@ export default { } satisfies ExportedHandler; ``` -This code will use the path within the URL and find the file associated to the path within the KV store. It also sets the proper MIME type in the response to indicate to the browser how to handle the response. To retrieve the value from the KV store, this code uses `arrayBuffer` to properly handle binary data such as images, documents, and video/audio files. +This code will use the path within the URL and find the file associated to the path within the key-value store. It also sets the proper MIME type in the response to indicate to the browser how to handle the response. To retrieve the value from the key-value store, this code uses `arrayBuffer` to properly handle binary data such as images, documents, and video/audio files. To start the Worker, run the following within a terminal: @@ -205,7 +205,7 @@ To start the Worker, run the following within a terminal: npx wrangler dev --remote ``` -This will run you Worker code against your remote resources, specifically using the preview KV namespace as configured. +This will run you Worker code against your remote resources, specifically using the preview Workers KV namespace as configured. ```sh npx wrangler dev --remote @@ -213,12 +213,12 @@ npx wrangler dev --remote ```sh output Your worker has access to the following bindings: -- KV Namespaces: +- Workers KV Namespaces: - assets: [wrangler:inf] Ready on http://localhost: ``` -Access the URL provided by the Wrangler command as such `http://localhost:/index.html`. You will be able to see the returned HTML file containing the file contents of our `index.html` file that was added to our KV store. Try it out with an image or a document and you will see that this Worker is also properly serving those assets from KV. +Access the URL provided by the Wrangler command as such `http://localhost:/index.html`. You will be able to see the returned HTML file containing the file contents of our `index.html` file that was added to our key-value store. Try it out with an image or a document and you will see that this Worker is also properly serving those assets from Workers KV. ## 5. Create an endpoint to generate dynamic responses from your key-value pairs @@ -263,7 +263,7 @@ Start by creating this file in the root of your project: ] ``` -Open a terminal and enter the following KV command to create a KV entry for the translations file: +Open a terminal and enter the following Workers KV command to create a KV entry for the translations file: ```sh npx wrangler kv key put hello-world.json --path hello-world.json --binding assets --preview false @@ -344,7 +344,7 @@ export default { mimeType += "; charset=utf-8"; } - //get the value from the KV store and return it if found + //get the value from the key-value store and return it if found const value = await env.assets.get(key, 'arrayBuffer') if(!value){ return new Response("Not found", { @@ -361,7 +361,7 @@ export default { } satisfies ExportedHandler; ``` -This new code provides a specific endpoint, `/hello-world`, which will provide translated responses. When this URL is accessed, our Worker code will first retrieve the language that is requested by the client in the `Accept-Language` request header and the translations from our KV store for the `hello-world.json` key. It then gets the translated message and returns the generated HTML. +This new code provides a specific endpoint, `/hello-world`, which will provide translated responses. When this URL is accessed, our Worker code will first retrieve the language that is requested by the client in the `Accept-Language` request header and the translations from our key-value store for the `hello-world.json` key. It then gets the translated message and returns the generated HTML. ```sh npx wrangler dev --remote @@ -371,17 +371,17 @@ With the Worker code running, we can notice that our application is now returnin ## 6. Deploy your project -Run `wrangler deploy` to deploy your Workers project to Cloudflare with the binding to the KV namespace. +Run `wrangler deploy` to deploy your Workers project to Cloudflare with the binding to the Workers KV namespace. ```sh npx wrangler deploy ``` -Wrangler will automatically set your KV binding to use the production KV namespace set in our `wrangler.toml` file with the KV namespace id. Throughout this example, we uploaded our assets to both the preview and the production KV namespaces. +Wrangler will automatically set your Workers KV binding to use the production Workers KV namespace set in our `wrangler.toml` file with the Workers KV namespace id. Throughout this example, we uploaded our assets to both the preview and the production Workers KV namespaces. -We can now verify that our project is properly working by accessing our Workers default hostname and accessing `..dev/index.html` or `..dev/hello-world` to see our deployed Worker in action, generating responses from the values in our KV store. +We can now verify that our project is properly working by accessing our Workers default hostname and accessing `..dev/index.html` or `..dev/hello-world` to see our deployed Worker in action, generating responses from the values in our key-value store. ## Related resources - [Rust support in Workers](/workers/languages/rust/). -- [Using KV in Workers](/kv/get-started/). +- [Using Workers KV in Workers](/kv/get-started/). diff --git a/src/content/docs/kv/get-started.mdx b/src/content/docs/kv/get-started.mdx index f422542d26b5b8..db0c151065a214 100644 --- a/src/content/docs/kv/get-started.mdx +++ b/src/content/docs/kv/get-started.mdx @@ -11,9 +11,9 @@ Workers KV provides low-latency, high-throughput global storage to your [Cloudfl This guide instructs you through: -- Creating a KV namespace. -- Writing key-value pairs to your KV namespace from a Cloudflare Worker. -- Reading key-value pairs from a KV namespace. +- Creating a Workers KV namespace. +- Writing key-value pairs to your Workers KV namespace from a Cloudflare Worker. +- Reading key-value pairs from a Workers KV namespace. You can perform these tasks through the CLI or through the Cloudflare dashboard. @@ -31,7 +31,7 @@ Refer to [How Workers works](/workers/reference/how-workers-works/) to learn abo -Create a new Worker to read and write to your KV namespace. +Create a new Worker to read and write to your Workers KV namespace. 1. Create a new project named `kv-tutorial` by running: @@ -97,20 +97,20 @@ Create a new Worker to read and write to your KV namespace. -## 2. Create a KV namespace +## 2. Create a Workers KV namespace -A [KV namespace](/kv/concepts/kv-namespaces/) is a key-value database replicated to Cloudflare’s global network. +A [Workers KV namespace](/kv/concepts/kv-namespaces/) is a key-value database replicated to Cloudflare’s global network. -[Wrangler](/workers/wrangler/) allows you to put, list, get, and delete entries within your KV namespace. +[Wrangler](/workers/wrangler/) allows you to put, list, get, and delete entries within your Workers KV namespace. :::note -KV operations are scoped to your account. +Key-value operations are scoped to your account. ::: -To create a KV namespace via Wrangler: +To create a Workers KV namespace via Wrangler: 1. Open your terminal and run the following command: @@ -119,7 +119,7 @@ To create a KV namespace via Wrangler: npx wrangler kv namespace create ``` - The `npx wrangler kv namespace create ` subcommand takes a new binding name as its argument. A KV namespace is created using a concatenation of your Worker’s name (from your `wrangler.toml` file) and the binding name you provide. A `BINDING_ID` is randomly generated for you. + The `npx wrangler kv namespace create ` subcommand takes a new binding name as its argument. A Workers KV namespace is created using a concatenation of your Worker’s name (from your `wrangler.toml` file) and the binding name you provide. A `BINDING_ID` is randomly generated for you. For this tutorial, use the binding name `BINDING_NAME`. @@ -153,11 +153,11 @@ To create a KV namespace via Wrangler: -## 3. Bind your Worker to your KV namespace +## 3. Bind your Worker to your Workers KV namespace -You must create a binding to connect your Worker with your KV namespace. [Bindings](/workers/runtime-apis/bindings/) allow your Workers to access resources, like KV, on the Cloudflare developer platform. +You must create a binding to connect your Worker with your Workers KV namespace. [Bindings](/workers/runtime-apis/bindings/) allow your Workers to access resources, like Workers KV, on the Cloudflare developer platform. -To bind your KV namespace to your Worker: +To bind your Workers KV namespace to your Worker: @@ -172,14 +172,14 @@ To bind your KV namespace to your Worker: Binding names do not need to correspond to the namespace you created. Binding names are only a reference. Specifically: - - The value (string) you set for `` is used to reference this KV namespace in your Worker. For this tutorial, this should be `BINDING_NAME`. + - The value (string) you set for `` is used to reference this Workers KV namespace in your Worker. For this tutorial, this should be `BINDING_NAME`. - The binding must be [a valid JavaScript variable name](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#variables). For example, `binding = "MY_KV"` or `binding = "routingConfig"` would both be valid names for the binding. - Your binding is available in your Worker at `env.` from within your Worker. :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV namespaces](/kv/concepts/kv-namespaces/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that binds to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. +A binding is how your Worker interacts with external resources such as [Workers KV namespaces](/kv/concepts/kv-namespaces/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that binds to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment](/kv/reference/environments/) for more information. @@ -193,20 +193,20 @@ Refer to [Environment](/kv/reference/environments/) for more information. 3. Select **Settings**. 4. Scroll to **Bindings**, then select **Add**. 5. Select **KV namespace**. -6. Name your binding (`BINDING_NAME`) in **Variable name**, then select the KV namespace (`kv_tutorial_namespace`) you created in [step 2](/kv/get-started/#2-create-a-kv-namespace) from the dropdown menu. +6. Name your binding (`BINDING_NAME`) in **Variable name**, then select the Workers KV namespace (`kv_tutorial_namespace`) you created in [step 2](/kv/get-started/#2-create-a-kv-namespace) from the dropdown menu. 7. Select **Deploy** to deploy your binding. -## 4. Interact with your KV namespace +## 4. Interact with your Workers KV namespace -You can interact with your KV namespace via [Wrangler](/workers/wrangler/install-and-update/) or directly from your [Workers](/workers/) application. +You can interact with your Workers KV namespace via [Wrangler](/workers/wrangler/install-and-update/) or directly from your [Workers](/workers/) application. ### Write a value -To write a value to your empty KV namespace using Wrangler: +To write a value to your empty Workers KV namespace using Wrangler: 1. Run the `wrangler kv key put` subcommand in your terminal, and input your key and value respectively. `` and `` are values of your choice. @@ -239,7 +239,7 @@ npx wrangler kv key put --namespace-id=xxxxxxxxxxxxxxxx "" "" --loca 1. Go to [**Storage & Databases** > **KV**](https://dash.cloudflare.com/?to=/:account/workers/kv/namespaces). -2. Select the KV namespace you created (`kv_tutorial_namespace`), then select **View**. +2. Select the Workers KV namespace you created (`kv_tutorial_namespace`), then select **View**. 3. Select **KV Pairs**. 4. Enter a `` of your choice. 5. Enter a `` of your choice. @@ -262,7 +262,7 @@ To access the value using Wrangler: npx wrangler kv key get [OPTIONS] "" ``` - A KV namespace can be specified in two ways: + A Workers KV namespace can be specified in two ways:
@@ -304,20 +304,20 @@ You can view key-value pairs directly from the dashboard. -## 5. Access your KV namespace from your Worker +## 5. Access your Workers KV namespace from your Worker :::note -When using [`wrangler dev`](/workers/wrangler/commands/#dev) to develop locally, Wrangler defaults to using a local version of KV to avoid interfering with any of your live production data in KV. This means that reading keys that you have not written locally returns null. +When using [`wrangler dev`](/workers/wrangler/commands/#dev) to develop locally, Wrangler defaults to using a local version of Workers KV to avoid interfering with any of your live production data in Workers KV. This means that reading keys that you have not written locally returns null. -To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This uses the `preview_id` of the KV binding configuration in the `wrangler.toml` file. See the [KV binding docs](/kv/concepts/kv-bindings/#using-the-kv-binding-when-developing-locally) for more information. +To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This uses the `preview_id` of the Workers KV binding configuration in the `wrangler.toml` file. See the [Workers KV binding docs](/kv/concepts/kv-bindings/#using-the-kv-binding-when-developing-locally) for more information. ::: -1. In your Worker script, add your KV binding in the `Env` interface: +1. In your Worker script, add your Workers KV binding in the `Env` interface: ```ts interface Env { @@ -332,7 +332,7 @@ To have `wrangler dev` connect to your Workers KV namespace running on Cloudflar let value = await env.BINDING_NAME.put(key, value); ``` -3. Use the KV `get()` method to fetch the data you stored in your KV database: +3. Use the KV `get()` method to fetch the data you stored in your Workers KV database: ```ts let value = await env.BINDING_NAME.get("KEY"); @@ -367,8 +367,8 @@ export default { The code above: -1. Writes a key to `BINDING_NAME` using KV's `put()` method. -2. Reads the same key using KV's `get()` method, and returns an error if the key is null (or in case the key is not set, or does not exist). +1. Writes a key to `BINDING_NAME` using Workers KV's `put()` method. +2. Reads the same key using Workers KV's `get()` method, and returns an error if the key is null (or in case the key is not set, or does not exist). 3. Uses JavaScript's [`try...catch`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch) exception handling to catch potential errors. When writing or reading from any service, such as Workers KV or external APIs using `fetch()`, you should expect to handle exceptions explicitly. To run your project locally, enter the following command within your project directory: @@ -411,8 +411,8 @@ The browser should simply return the `VALUE` corresponding to the `KEY` you have The code above: - 1. Writes a key to `BINDING_NAME` using KV's `put()` method. - 2. Reads the same key using KV's `get()` method, and returns an error if the key is null (or in case the key is not set, or does not exist). + 1. Writes a key to `BINDING_NAME` using Workers KV's `put()` method. + 2. Reads the same key using Workers KV's `get()` method, and returns an error if the key is null (or in case the key is not set, or does not exist). 3. Uses JavaScript's [`try...catch`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch) exception handling to catch potential errors. When writing or reading from any service, such as Workers KV or external APIs using `fetch()`, you should expect to handle exceptions explicitly. The browser should simply return the `VALUE` corresponding to the `KEY` you have specified with the `get()` method. @@ -422,12 +422,12 @@ The browser should simply return the `VALUE` corresponding to the `KEY` you have -## 6. Deploy your KV +## 6. Deploy your Workers KV -1. Run the following command to deploy KV to Cloudflare's global network: +1. Run the following command to deploy Workers KV to Cloudflare's global network: ```sh npx wrangler deploy @@ -457,7 +457,7 @@ The browser should simply return the `VALUE` corresponding to the `KEY` you have By finishing this tutorial, you have: -1. Created a KV namespace +1. Created a Workers KV namespace 2. Created a Worker that writes and reads from that namespace 3. Deployed your project globally. @@ -465,6 +465,6 @@ By finishing this tutorial, you have: If you have any feature requests or notice any bugs, share your feedback directly with the Cloudflare team by joining the [Cloudflare Developers community on Discord](https://discord.cloudflare.com). -- Learn more about the [KV API](/kv/api/). +- Learn more about the [Workers KV API](/kv/api/). - Understand how to use [Environments](/kv/reference/environments/) with Workers KV. - Read the Wrangler [`kv` command documentation](/kv/reference/kv-commands/). diff --git a/src/content/docs/kv/glossary.mdx b/src/content/docs/kv/glossary.mdx index 43a464f80e7363..e32ffce4dc7290 100644 --- a/src/content/docs/kv/glossary.mdx +++ b/src/content/docs/kv/glossary.mdx @@ -8,6 +8,6 @@ sidebar: import { Glossary } from "~/components" -Review the definitions for terms used across Cloudflare's KV documentation. +Review the definitions for terms used across Cloudflare's Workers KV documentation. diff --git a/src/content/docs/kv/index.mdx b/src/content/docs/kv/index.mdx index 0b173cb65b9491..72ee61f9bb9c1c 100644 --- a/src/content/docs/kv/index.mdx +++ b/src/content/docs/kv/index.mdx @@ -73,11 +73,11 @@ Built on SQLite, D1 is Cloudflare’s first queryable relational database. Creat - Learn about KV limits. + Learn about Workers KV limits. - Learn about KV pricing. + Learn about Workers KV pricing. **KV**](https://dash.cloudflare.com/?to=/:account/workers/kv/namespaces). @@ -34,18 +34,18 @@ You can optionally select a time window to query. This defaults to the last 24 h ## Query via the GraphQL API -You can programmatically query analytics for your KV namespaces via the [GraphQL Analytics API](/analytics/graphql-api/). This API queries the same datasets as the Cloudflare dashboard, and supports GraphQL [introspection](/analytics/graphql-api/features/discovery/introspection/). +You can programmatically query analytics for your Workers KV namespaces via the [GraphQL Analytics API](/analytics/graphql-api/). This API queries the same datasets as the Cloudflare dashboard, and supports GraphQL [introspection](/analytics/graphql-api/features/discovery/introspection/). To get started using the [GraphQL Analytics API](/analytics/graphql-api/), follow the documentation to setup [Authentication for the GraphQL Analytics API](/analytics/graphql-api/getting-started/authentication/). -To use the GraphQL API to retrieve KV's datasets, you must provide the `accountTag` filter with your Cloudflare Account ID. The GraphQL datasets for KV include: +To use the GraphQL API to retrieve Workers KV's datasets, you must provide the `accountTag` filter with your Cloudflare Account ID. The GraphQL datasets for Workers KV include: - `kvOperationsAdaptiveGroups` - `kvStorageAdaptiveGroups` ### Examples -The following are common GraphQL queries that you can use to retrieve information about KV analytics. These queries make use of variables `$accountTag`, `$date_geq`, `$date_leq`, and `$namespaceId`, which should be set as GraphQL variables or replaced in line. These variables should look similar to these: +The following are common GraphQL queries that you can use to retrieve information about Workers KV analytics. These queries make use of variables `$accountTag`, `$date_geq`, `$date_leq`, and `$namespaceId`, which should be set as GraphQL variables or replaced in line. These variables should look similar to these: ```json { @@ -113,7 +113,7 @@ query { } ``` -To query your account-wide read, write, delete, and list operations across all KV namespaces: +To query your account-wide read, write, delete, and list operations across all Workers KV namespaces: ```graphql query { @@ -134,7 +134,7 @@ query { #### Storage -To query the storage details (`keyCount` and `byteCount`) of a KV namespace for every day of a given date range: +To query the storage details (`keyCount` and `byteCount`) of a Workers KV namespace for every day of a given date range: ```graphql query Viewer { diff --git a/src/content/docs/kv/platform/limits.mdx b/src/content/docs/kv/platform/limits.mdx index 38166ad8b87608..16dda94fedacea 100644 --- a/src/content/docs/kv/platform/limits.mdx +++ b/src/content/docs/kv/platform/limits.mdx @@ -32,7 +32,7 @@ import { Render } from "~/components" :::note[Free versus Paid plan pricing] -Refer to [KV pricing](/kv/platform/pricing/) to review the specific KV operations you are allowed under each plan with their pricing. +Refer to [Workers KV pricing](/kv/platform/pricing/) to review the specific key-value operations you are allowed under each plan with their pricing. ::: diff --git a/src/content/docs/kv/platform/pricing.mdx b/src/content/docs/kv/platform/pricing.mdx index 4afa72a15be874..f112ae0e7efcaf 100644 --- a/src/content/docs/kv/platform/pricing.mdx +++ b/src/content/docs/kv/platform/pricing.mdx @@ -12,15 +12,15 @@ import { Render } from "~/components" ## Frequently Asked Questions -Frequently asked questions related to KV pricing: +Frequently asked questions related to Workers KV pricing: -* When writing via KV's [REST API](/api/operations/workers-kv-namespace-write-multiple-key-value-pairs), how are writes charged? +* When writing via Workers KV [REST API](/api/operations/workers-kv-namespace-write-multiple-key-value-pairs), how are writes charged? Each key-value pair in the `PUT` request is counted as a single write, identical to how each call to `PUT` in the Workers API counts as a write. Writing 5,000 keys via the REST API incurs the same write costs as making 5,000 `PUT` calls in a Worker. * Do queries I issue from the dashboard or wrangler (the CLI) count as billable usage? -Yes, any operations via the Cloudflare dashboard or wrangler, including updating (writing) keys, deleting keys, and listing the keys in a namespace count as billable KV usage. +Yes, any operations via the Cloudflare dashboard or wrangler, including updating (writing) keys, deleting keys, and listing the keys in a namespace count as billable Workers KV usage. * Does Workers KV charge for data transfer / egress? diff --git a/src/content/docs/kv/reference/data-security.mdx b/src/content/docs/kv/reference/data-security.mdx index 372f334e5a338b..cbbc274b01aa1a 100644 --- a/src/content/docs/kv/reference/data-security.mdx +++ b/src/content/docs/kv/reference/data-security.mdx @@ -6,7 +6,7 @@ sidebar: --- -This page details the data security properties of KV, including: +This page details the data security properties of Workers KV, including: * Encryption-at-rest (EAR). * Encryption-in-transit (EIT). @@ -14,17 +14,17 @@ This page details the data security properties of KV, including: ## Encryption at Rest -All values stored in KV are encrypted at rest. Encryption and decryption are automatic, do not require user configuration to enable, and do not impact the effective performance of KV. +All values stored in Workers KV are encrypted at rest. Encryption and decryption are automatic, do not require user configuration to enable, and do not impact the effective performance of Workers KV. Values are only decrypted by the process executing your Worker code or responding to your API requests. Encryption keys are managed by Cloudflare and securely stored in the same key management systems we use for managing encrypted data across Cloudflare internally. -Objects are encrypted using [AES-256](https://www.cloudflare.com/learning/ssl/what-is-encryption/), a widely tested, highly performant and industry-standard encryption algorithm. KV uses GCM (Galois/Counter Mode) as its preferred mode. +Objects are encrypted using [AES-256](https://www.cloudflare.com/learning/ssl/what-is-encryption/), a widely tested, highly performant and industry-standard encryption algorithm. Workers KV uses GCM (Galois/Counter Mode) as its preferred mode. ## Encryption in Transit -Data transfer between a Cloudflare Worker, and/or between nodes within the Cloudflare network and KV is secured using the same [Transport Layer Security](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/) (TLS/SSL). +Data transfer between a Cloudflare Worker, and/or between nodes within the Cloudflare network and Workers KV is secured using the same [Transport Layer Security](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/) (TLS/SSL). API access via the HTTP API or using the [wrangler](/workers/wrangler/install-and-update/) command-line interface is also over TLS/SSL (HTTPS). diff --git a/src/content/docs/kv/reference/environments.mdx b/src/content/docs/kv/reference/environments.mdx index 780990cc4aa8a5..896134d3935882 100644 --- a/src/content/docs/kv/reference/environments.mdx +++ b/src/content/docs/kv/reference/environments.mdx @@ -5,9 +5,9 @@ sidebar: order: 3 --- -KV namespaces can be used with [environments](/workers/wrangler/environments/). This is useful when you have code in your Worker that refers to a KV binding like `MY_KV`, and you want to have these bindings point to different KV namespaces (for example, one for staging and one for production). +Workers KV namespaces can be used with [environments](/workers/wrangler/environments/). This is useful when you have code in your Worker that refers to a Workers KV binding like `MY_KV`, and you want to have these bindings point to different Workers KV namespaces (for example, one for staging and one for production). -The following code in the `wrangler.toml` file shows you how to have two environments that have two different KV namespaces but the same binding name: +The following code in the `wrangler.toml` file shows you how to have two environments that have two different Workers KV namespaces but the same binding name: ```toml [env.staging] @@ -21,11 +21,11 @@ kv_namespaces = [ ] ``` -Using the same binding name for two different KV namespaces keeps your Worker code more readable. +Using the same binding name for two different Workers KV namespaces keeps your Worker code more readable. In the `staging` environment, `MY_KV.get("KEY")` will read from the namespace ID `e29b263ab50e42ce9b637fa8370175e8`. In the `production` environment, `MY_KV.get("KEY")` will read from the namespace ID `a825455ce00f4f7282403da85269f8ea`. -To insert a value into a `staging` KV namespace, run: +To insert a value into a `staging` Workers KV namespace, run: ```sh wrangler kv key put --env=staging --binding= "" "" @@ -39,14 +39,14 @@ wrangler kv key put --namespace-id= "" "" :::caution -Since version 3.60.0, Wrangler KV commands support the `kv ...` syntax. If you are using versions of Wrangler below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/) for KV page. +Since version 3.60.0, Wrangler Workers KV commands support the `kv ...` syntax. If you are using versions of Wrangler below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/) for Workers KV page. ::: Most `kv` subcommands also allow you to specify an environment with the optional `--env` flag. -Specifying an environment with the optional `--env` flag allows you to publish Workers running the same code but with different KV namespaces. +Specifying an environment with the optional `--env` flag allows you to publish Workers running the same code but with different Workers KV namespaces. -For example, you could use separate staging and production KV namespaces for KV data in your `wrangler.toml` file: +For example, you could use separate staging and production Workers KV namespaces for KV data in your `wrangler.toml` file: ```toml type = "webpack" @@ -66,9 +66,9 @@ kv_namespaces = [ ] ``` -With the `wrangler.toml` file above, you can specify `--env production` when you want to perform a KV action on the KV namespace `MY_KV` under `env.production`. +With the `wrangler.toml` file above, you can specify `--env production` when you want to perform a KV action on the Workers KV namespace `MY_KV` under `env.production`. -For example, with the `wrangler.toml` file above, you can get a value out of a production KV instance with: +For example, with the `wrangler.toml` file above, you can get a value out of a production Workers KV instance with: ```sh wrangler kv key get --binding "MY_KV" --env=production "" diff --git a/src/content/docs/kv/reference/kv-commands.mdx b/src/content/docs/kv/reference/kv-commands.mdx index 0cbd0cc3f3805e..b84bfdc5804e9d 100644 --- a/src/content/docs/kv/reference/kv-commands.mdx +++ b/src/content/docs/kv/reference/kv-commands.mdx @@ -1,6 +1,6 @@ --- pcx_content_type: reference -title: Wrangler KV commands +title: Wrangler Workers KV commands sidebar: order: 2 --- diff --git a/src/content/docs/kv/tutorials/index.mdx b/src/content/docs/kv/tutorials/index.mdx index 8c6d1ad13cc7c5..9d5cacb475b0d7 100644 --- a/src/content/docs/kv/tutorials/index.mdx +++ b/src/content/docs/kv/tutorials/index.mdx @@ -9,6 +9,6 @@ sidebar: import { GlossaryTooltip, ListTutorials } from "~/components" -View tutorials to help you get started with KV. +View tutorials to help you get started with Workers KV. diff --git a/src/content/docs/kv/workers-kv-api.mdx b/src/content/docs/kv/workers-kv-api.mdx index fb7bee6e30ca23..5059a24ac5ab07 100644 --- a/src/content/docs/kv/workers-kv-api.mdx +++ b/src/content/docs/kv/workers-kv-api.mdx @@ -1,6 +1,6 @@ --- pcx_content_type: navigation -title: KV REST API +title: Workers KV REST API external_link: /api/operations/workers-kv-namespace-list-namespaces sidebar: order: 8 diff --git a/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx b/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx index d115ebd1ec5a91..e39cc3f5be0220 100644 --- a/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx @@ -88,7 +88,7 @@ Additionally, you will have access to [preview deployments](/pages/configuration ## Use bindings in your Nuxt application -A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [KV](/kv/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). +A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [Workers KV](/kv/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). If you intend to use bindings in your project, you must first set up your bindings for local and remote development. @@ -146,7 +146,7 @@ declare module "h3" { In Nuxt, add server-side code via [Server Routes and Middleware](https://nuxt.com/docs/guide/directory-structure/server#server-directory). The `defineEventHandler()` method is used to define your API endpoints in which you can access Cloudflare's context via the provided `context` field. The `context` field allows you to access any bindings set for your application. -The following code block shows an example of accessing a KV namespace in Nuxt. +The following code block shows an example of accessing a Workers KV namespace in Nuxt. diff --git a/src/content/docs/pages/framework-guides/deploy-a-qwik-site.mdx b/src/content/docs/pages/framework-guides/deploy-a-qwik-site.mdx index 6f88615e4ea005..1a110bb6d9ac26 100644 --- a/src/content/docs/pages/framework-guides/deploy-a-qwik-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-a-qwik-site.mdx @@ -60,11 +60,11 @@ Every time you commit new code to your Qwik site, Cloudflare Pages will automati ## Use bindings in your Qwik application -A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [KV](/kv/concepts/how-kv-works/), [Durable Object](/durable-objects/), [R2](/r2/), and [D1](https://blog.cloudflare.com/introducing-d1/). +A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [Workers KV](/kv/concepts/how-kv-works/), [Durable Object](/durable-objects/), [R2](/r2/), and [D1](https://blog.cloudflare.com/introducing-d1/). In QwikCity, add server-side code via [routeLoaders](https://qwik.builder.io/qwikcity/route-loader/) and [actions](https://qwik.builder.io/qwikcity/action/). Then access bindings set for your application via the `platform` object provided by the framework. -The following code block shows an example of accessing a KV namespace in QwikCity. +The following code block shows an example of accessing a Workers KV namespace in QwikCity. ```typescript null {4,5} // ... diff --git a/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx b/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx index b20d18e72bc6fe..b97e1ef48c8558 100644 --- a/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx @@ -76,7 +76,7 @@ npm run deploy ## Create and add a binding to your Remix application To add a binding to your Remix application, refer to [Bindings](/pages/functions/bindings/). -A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [KV namespaces](/kv/concepts/how-kv-works/), [Durable Objects](/durable-objects/), [R2 storage buckets](/r2/), and [D1 databases](/d1/). +A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [Workers KV namespaces](/kv/concepts/how-kv-works/), [Durable Objects](/durable-objects/), [R2 storage buckets](/r2/), and [D1 databases](/d1/). ### Binding resources in local development diff --git a/src/content/docs/pages/framework-guides/deploy-a-svelte-site.mdx b/src/content/docs/pages/framework-guides/deploy-a-svelte-site.mdx index f2cea8632e056b..b9c0d5ebd608fe 100644 --- a/src/content/docs/pages/framework-guides/deploy-a-svelte-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-a-svelte-site.mdx @@ -61,7 +61,7 @@ const config = { export default config; ``` -3. (Needed if you are using TypeScript) Include support for environment variables. The `env` object, containing KV namespaces and other storage objects, is passed to SvelteKit via the platform property along with context and caches, meaning you can access it in hooks and endpoints. For example: +3. (Needed if you are using TypeScript) Include support for environment variables. The `env` object, containing Workers KV namespaces and other storage objects, is passed to SvelteKit via the platform property along with context and caches, meaning you can access it in hooks and endpoints. For example: ```diff declare namespace App { @@ -84,7 +84,7 @@ declare namespace App { ``` -4. Access the added KV or Durable objects (or generally any [binding](/pages/functions/bindings/)) in your endpoint with `env`: +4. Access the added Workers KV or Durable Objects (or generally any [binding](/pages/functions/bindings/)) in your endpoint with `env`: ```js export async function post(context) { diff --git a/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx b/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx index bf19694e41f427..a296f6b7ba892f 100644 --- a/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx @@ -37,13 +37,13 @@ The final step of the C3 workflow will offer to deploy your application to Cloud ## Bindings -A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [KV](/kv/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). +A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [Workers KV](/kv/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). If you intend to use bindings in your project, you must first set up your bindings for local and remote development. In Analog, server-side code can be added via [API Routes](https://analogjs.org/docs/features/api/overview). The `defineEventHandler()` method is used to define your API endpoints in which you can access Cloudflare's context via the provided `context` field. The `context` field allows you to access any bindings set for your application. -The following code block shows an example of accessing a KV namespace in Analog. +The following code block shows an example of accessing a Workers KV namespace in Analog. ```typescript null {2} export default defineEventHandler(async ({ context }) => { diff --git a/src/content/docs/pages/framework-guides/deploy-an-astro-site.mdx b/src/content/docs/pages/framework-guides/deploy-an-astro-site.mdx index 7cf3f113c1b777..516f6540edc162 100644 --- a/src/content/docs/pages/framework-guides/deploy-an-astro-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-an-astro-site.mdx @@ -103,13 +103,13 @@ export default defineConfig({ ## Use bindings in your Astro application -A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [KV](/kv/concepts/how-kv-works/), [Durable Object](/durable-objects/), [R2](/r2/), and [D1](https://blog.cloudflare.com/introducing-d1/). +A [binding](/pages/functions/bindings/) allows your application to interact with Cloudflare developer products, such as [Workers KV](/kv/concepts/how-kv-works/), [Durable Object](/durable-objects/), [R2](/r2/), and [D1](https://blog.cloudflare.com/introducing-d1/). Use bindings in Astro components and API routes by using `context.locals` from [Astro Middleware](https://docs.astro.build/en/guides/middleware/) to access the Cloudflare runtime which amongst other fields contains the Cloudflare's environment and consecutively any bindings set for your application. -Refer to the following example of how to access a KV namespace with TypeScript. +Refer to the following example of how to access a Workers KV namespace with TypeScript. -First, you need to define Cloudflare runtime and KV type by updating the `env.d.ts`: +First, you need to define Cloudflare runtime and Workers KV type by updating the `env.d.ts`: ```typescript /// @@ -127,7 +127,7 @@ declare namespace App { } ``` -You can then access your KV from an API endpoint in the following way: +You can then access your Workers KV from an API endpoint in the following way: ```typescript null {3,4,5} import type { APIContext } from "astro"; diff --git a/src/content/docs/pages/framework-guides/nextjs/ssr/caching.mdx b/src/content/docs/pages/framework-guides/nextjs/ssr/caching.mdx index bfce53019e5680..9945a5ac3e44d3 100644 --- a/src/content/docs/pages/framework-guides/nextjs/ssr/caching.mdx +++ b/src/content/docs/pages/framework-guides/nextjs/ssr/caching.mdx @@ -21,7 +21,7 @@ You can configure your Next.js app to write cache entries to and read from eithe It takes an extra step to enable, but Cloudflare recommends caching data using [Workers KV](/kv/). -When you write cached data to Workers KV, you write to storage that can be read by any Cloudflare location. This means your app can fetch data, cache it in KV, and then subsequent requests anywhere around the world can read from this cache. +When you write cached data to Workers KV, you write to storage that can be read by any Cloudflare location. This means your app can fetch data, cache it in Workers KV, and then subsequent requests anywhere around the world can read from this cache. :::note @@ -31,7 +31,7 @@ Workers KV is eventually consistent, which means that it can take up to 60 secon ::: -To use Workers KV as the cache for your Next.js app, [add a KV binding](/pages/functions/bindings/#kv-namespaces) to your Pages project, and set the name of the binding to `__NEXT_ON_PAGES__KV_SUSPENSE_CACHE`. +To use Workers KV as the cache for your Next.js app, [add a Workers KV binding](/pages/functions/bindings/#kv-namespaces) to your Pages project, and set the name of the binding to `__NEXT_ON_PAGES__KV_SUSPENSE_CACHE`. ### Cache API (default) diff --git a/src/content/docs/pages/functions/bindings.mdx b/src/content/docs/pages/functions/bindings.mdx index 833d69aae99c0e..fd0b3f92cd02df 100644 --- a/src/content/docs/pages/functions/bindings.mdx +++ b/src/content/docs/pages/functions/bindings.mdx @@ -7,7 +7,7 @@ sidebar: import { Render, TabItem, Tabs } from "~/components"; -A [binding](/workers/runtime-apis/bindings/) enables your Pages Functions to interact with resources on the Cloudflare developer platform. Use bindings to integrate your Pages Functions with Cloudflare resources like [KV](/kv/concepts/how-kv-works/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). You can set bindings for both production and preview environments. +A [binding](/workers/runtime-apis/bindings/) enables your Pages Functions to interact with resources on the Cloudflare developer platform. Use bindings to integrate your Pages Functions with Cloudflare resources like [Workers KV](/kv/concepts/how-kv-works/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). You can set bindings for both production and preview environments. This guide will instruct you on configuring a binding for your Pages Function. You must already have a Cloudflare Developer Platform resource set up to continue. @@ -17,13 +17,13 @@ Pages Functions only support a subset of all [bindings](/workers/runtime-apis/bi ::: -## KV namespaces +## Workers KV namespaces [Workers KV](/kv/concepts/kv-namespaces/) is Cloudflare's key-value storage solution. -To bind your KV namespace to your Pages Function, you can configure a KV namespace binding in [`wrangler.toml`](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. +To bind your Workers KV namespace to your Pages Function, you can configure a Workers KV namespace binding in [`wrangler.toml`](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. -To configure a KV namespace binding via the Cloudflare dashboard: +To configure a Workers KV namespace binding via the Cloudflare dashboard: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account. 2. In **Account Home**, select **Workers & Pages**. @@ -33,7 +33,7 @@ To configure a KV namespace binding via the Cloudflare dashboard: 6. Under **KV namespace**, select your desired namespace. 7. Redeploy your project for the binding to take effect. -Below is an example of how to use KV in your Function. In the following example, your KV namespace binding is called `TODO_LIST` and you can access the binding in your Function code on `context.env`: +Below is an example of how to use Workers KV in your Function. In the following example, your Workers KV namespace binding is called `TODO_LIST` and you can access the binding in your Function code on `context.env`: @@ -59,14 +59,14 @@ export const onRequest: PagesFunction = async (context) => { -### Interact with your KV namespaces locally +### Interact with your Workers KV namespaces locally -You can interact with your KV namespace bindings locally in one of two ways: +You can interact with your Workers KV namespace bindings locally in one of two ways: - Configure your Pages project's `wrangler.toml` file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). - Pass arguments to `wrangler pages dev` directly. -To interact with your KV namespace binding locally by passing arguments to the Wrangler CLI, add `-k ` or `--kv=` to the `wrangler pages dev` command. For example, if your KV namespace is bound your Function via the `TODO_LIST` binding, access the KV namespace in local development by running: +To interact with your Workers KV namespace binding locally by passing arguments to the Wrangler CLI, add `-k ` or `--kv=` to the `wrangler pages dev` command. For example, if your Workers KV namespace is bound your Function via the `TODO_LIST` binding, access the Workers KV namespace in local development by running: ```sh npx wrangler pages dev --kv=TODO_LIST @@ -683,7 +683,7 @@ export const onRequest: PagesFunction = async (context) => { }; ``` - + ### Interact with your Hyperdrive binding locally diff --git a/src/content/docs/pages/functions/plugins/index.mdx b/src/content/docs/pages/functions/plugins/index.mdx index 1c3e961427b3b2..6ebd791dcf6fc9 100644 --- a/src/content/docs/pages/functions/plugins/index.mdx +++ b/src/content/docs/pages/functions/plugins/index.mdx @@ -24,7 +24,7 @@ For example, a Pages Plugin could: * Proxy a third-party service's API. * Validate authorization headers. * Provide a full admin web app experience. -* Store data in KV or Durable Objects. +* Store data in Workers KV or Durable Objects. * Server-side render (SSR) webpages with data from a CMS. * Report errors and track performance. @@ -43,7 +43,7 @@ In this example, you will build a Pages Plugin and then include it in a project. The first Plugin should: * intercept HTML forms. -* store the form submission in [KV](/kv/api/). +* store the form submission in [Workers KV](/kv/api/). * respond to submissions with a developer's custom response. ### 1. Create a new Pages Plugin @@ -94,7 +94,7 @@ Your Plugin should not use the mounted path anywhere in the file structure (for ::: -You are free to use as many different files as you need. The structure of a Plugin is exactly the same as Functions in a Pages project today, except that the handlers receive a new property of their parameter object, `pluginArgs`. This property is the initialization parameter that a developer passes when mounting a Plugin. You can use this to receive API tokens, KV/Durable Object namespaces, or anything else that your Plugin needs to work. +You are free to use as many different files as you need. The structure of a Plugin is exactly the same as Functions in a Pages project today, except that the handlers receive a new property of their parameter object, `pluginArgs`. This property is the initialization parameter that a developer passes when mounting a Plugin. You can use this to receive API tokens, Workers KV/Durable Object namespaces, or anything else that your Plugin needs to work. Returning to your static form example, if you want to intercept requests and override the behavior of an HTML form, you need to create a `functions/_middleware.ts`. Developers could then mount your Plugin on a single route, or on their entire project. @@ -140,7 +140,7 @@ export const onRequestPost = async (context) => { To create a good developer experience, you should consider adding TypeScript typings to your Plugin. This allows developers to use their IDE features for autocompletion, and also ensure that they include all the parameters you are expecting. -In the `index.d.ts`, export a function which takes your `pluginArgs` and returns a `PagesFunction`. For your static form example, you take two properties, `kv`, a KV namespace, and `respondWith`, a function which takes an object with a `formData` property (`FormData`) and returns a `Promise` of a `Response`: +In the `index.d.ts`, export a function which takes your `pluginArgs` and returns a `PagesFunction`. For your static form example, you take two properties, `kv`, a Workers KV namespace, and `respondWith`, a function which takes an object with a `formData` property (`FormData`) and returns a `Promise` of a `Response`: ```typescript export type PluginArgs = { @@ -198,7 +198,7 @@ export const onRequest = (context) => { ### 7. Test your Pages Plugin -You can use `wrangler pages dev` to test a Pages project, including any Plugins you have installed. Remember to include any KV bindings and environment variables that the Plugin is expecting. +You can use `wrangler pages dev` to test a Pages project, including any Plugins you have installed. Remember to include any Workers KV bindings and environment variables that the Plugin is expecting. With your Plugin mounted on the `/contact` route, a corresponding HTML file might look like this: diff --git a/src/content/docs/pages/functions/plugins/sentry.mdx b/src/content/docs/pages/functions/plugins/sentry.mdx index deb70780fb34bb..c7041d81500ef6 100644 --- a/src/content/docs/pages/functions/plugins/sentry.mdx +++ b/src/content/docs/pages/functions/plugins/sentry.mdx @@ -31,7 +31,7 @@ export const onRequest: PagesFunction = sentryPlugin({ The Plugin uses [Toucan](https://github.com/robertcepa/toucan-js). Refer to the Toucan README to [review the options it can take](https://github.com/robertcepa/toucan-js#other-options). `context`, `request`, and `event` are automatically populated and should not be manually configured. -If your [DSN](https://docs.sentry.io/product/sentry-basics/dsn-explainer/) is held as an environment variable or in KV, you can access it like so: +If your [DSN](https://docs.sentry.io/product/sentry-basics/dsn-explainer/) is held as an environment variable or in Workers KV, you can access it like so: ```typescript import sentryPlugin from "@cloudflare/pages-plugin-sentry"; diff --git a/src/content/docs/pages/functions/plugins/static-forms.mdx b/src/content/docs/pages/functions/plugins/static-forms.mdx index 25428eb24e92c5..e2e9e8b97dbd0b 100644 --- a/src/content/docs/pages/functions/plugins/static-forms.mdx +++ b/src/content/docs/pages/functions/plugins/static-forms.mdx @@ -39,6 +39,6 @@ export const onRequest: PagesFunction = staticFormsPlugin({ ``` -The Plugin takes a single argument, an object with a `respondWith` property. This function takes an object with a `formData` property (the [`FormData`](https://developer.mozilla.org/en-US/docs/Web/API/FormData) instance) and `name` property (the name value of your `data-static-form-name` attribute). It should return a `Response` or `Promise` of a `Response`. It is in this `respondWith` function that you can take action such as serializing the `formData` and saving it to a KV namespace. +The Plugin takes a single argument, an object with a `respondWith` property. This function takes an object with a `formData` property (the [`FormData`](https://developer.mozilla.org/en-US/docs/Web/API/FormData) instance) and `name` property (the name value of your `data-static-form-name` attribute). It should return a `Response` or `Promise` of a `Response`. It is in this `respondWith` function that you can take action such as serializing the `formData` and saving it to a Workers KV namespace. The `method` and `action` attributes of the HTML form do not need to be set. The Plugin will automatically override them to allow it to intercept the submission. diff --git a/src/content/docs/pages/functions/pricing.mdx b/src/content/docs/pages/functions/pricing.mdx index 4f52838a02fbe3..e3161d558e9aba 100644 --- a/src/content/docs/pages/functions/pricing.mdx +++ b/src/content/docs/pages/functions/pricing.mdx @@ -10,7 +10,7 @@ Requests to your Functions are billed as Cloudflare Workers requests. Workers pl ## Paid Plans -Requests to your Pages functions count towards your quota for Workers Paid plans, including requests from your Function to KV or Durable Object bindings. +Requests to your Pages functions count towards your quota for Workers Paid plans, including requests from your Function to Workers KV or Durable Object bindings. Pages supports the [Standard usage model](/workers/platform/pricing/#example-pricing-standard-usage-model). diff --git a/src/content/docs/pages/functions/wrangler-configuration.mdx b/src/content/docs/pages/functions/wrangler-configuration.mdx index 63ea6b910290d8..e6b38f7723f59d 100644 --- a/src/content/docs/pages/functions/wrangler-configuration.mdx +++ b/src/content/docs/pages/functions/wrangler-configuration.mdx @@ -154,7 +154,7 @@ binding = "KV" id = "" ``` -This `wrangler.toml` configuration file adds the `nodejs_compat` compatibility flag and a KV namespace binding to your Pages project. Running `wrangler pages dev` in a Pages project directory with this `wrangler.toml` configuration file will apply the `nodejs_compat` compatibility flag locally, and expose the `KV` binding in your Pages Function code at `context.env.KV`. +This `wrangler.toml` configuration file adds the `nodejs_compat` compatibility flag and a Workers KV namespace binding to your Pages project. Running `wrangler pages dev` in a Pages project directory with this `wrangler.toml` configuration file will apply the `nodejs_compat` compatibility flag locally, and expose the `KV` binding in your Pages Function code at `context.env.KV`. :::note @@ -353,7 +353,7 @@ This will work for local development, but will fail to validate when you try to - `kv_namespaces` - - A list of KV namespaces that your Function should be bound to. Refer to [KV namespaces](/pages/functions/bindings/#kv-namespaces). + - A list of Workers KV namespaces that your Function should be bound to. Refer to [Workers KV namespaces](/pages/functions/bindings/#kv-namespaces). - `queues.producers` @@ -385,7 +385,7 @@ You can configure limits for your Pages project in the same way you can for Work ## Bindings -A [binding](/pages/functions/bindings/) enables your Pages Functions to interact with resources on the Cloudflare Developer Platform. Use bindings to integrate your Pages Functions with Cloudflare resources like [KV](/kv/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). You can set bindings for both production and preview environments. +A [binding](/pages/functions/bindings/) enables your Pages Functions to interact with resources on the Cloudflare Developer Platform. Use bindings to integrate your Pages Functions with Cloudflare resources like [Workers KV](/kv/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). You can set bindings for both production and preview environments. ### D1 databases @@ -429,7 +429,7 @@ the `script_name` key is optional. - Configure Hyperdrive bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#hyperdrive) the same way they are configured with Cloudflare Workers. -### KV namespaces +### Workers KV namespaces [Workers KV](/kv/api/) is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflare’s data centers after access. @@ -439,8 +439,8 @@ When using Wrangler in the default local development mode, files will be written ::: -- Configure KV namespace bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#kv-namespaces) the same way they are configured with Cloudflare Workers. -- Interact with your [KV namespace binding](/pages/functions/bindings/#kv-namespaces). +- Configure Workers KV namespace bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#kv-namespaces) the same way they are configured with Cloudflare Workers. +- Interact with your [Workers KV namespace binding](/pages/functions/bindings/#kv-namespaces). ### Queues Producers diff --git a/src/content/docs/pub-sub/learning/integrate-workers.mdx b/src/content/docs/pub-sub/learning/integrate-workers.mdx index c17534198f1395..5beb70a6ba3366 100644 --- a/src/content/docs/pub-sub/learning/integrate-workers.mdx +++ b/src/content/docs/pub-sub/learning/integrate-workers.mdx @@ -9,7 +9,7 @@ Once of the most powerful features of Pub/Sub is the ability to connect [Cloudfl There are three ways to integrate a Worker with Pub/Sub: -1. **As an “On Publish” hook that receives all messages published to a Broker**. This allows the Worker to modify, copy to other destinations (such as [R2](/r2/) or [KV](/kv/concepts/how-kv-works/)), filter and/or drop messages before they are delivered to subscribers. +1. **As an “On Publish” hook that receives all messages published to a Broker**. This allows the Worker to modify, copy to other destinations (such as [R2](/r2/) or [Workers KV](/kv/concepts/how-kv-works/)), filter and/or drop messages before they are delivered to subscribers. 2. (Not yet available in beta) **Publishing directly to a Pub/Sub topic from a Worker.** You can publish telemetry and events to Pub/Sub topics from your Worker code. 3. (Not yet available in beta) **Subscribing to a Pub/Sub topic (or topics) from within a Worker**. This allows the Worker to act as any other subscriber and consume messages published either from external clients (over MQTT) or from other Workers. diff --git a/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx b/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx index ff350ddfc6ed2d..a648e649cf6da3 100644 --- a/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx +++ b/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx @@ -8,7 +8,7 @@ pcx_content_type: tutorial products: - Workers - Browser Rendering - - KV + - Workers KV languages: - TypeScript sidebar: @@ -57,9 +57,9 @@ Then, move into your newly created directory: cd queues-web-crawler ``` -## 2. Create KV namespace +## 2. Create Workers KV namespace -We need to create a KV store. This can be done through the Cloudflare dashboard or the Wrangler CLI. For this tutorial, we will use the Wrangler CLI. +We need to create a key-value store. This can be done through the Cloudflare dashboard or the Wrangler CLI. For this tutorial, we will use the Wrangler CLI. ```sh npx wrangler kv namespace create crawler_links @@ -82,7 +82,7 @@ binding = "crawler_screenshots" id = "" ``` -### Add KV bindings to wrangler.toml +### Add Workers KV bindings to wrangler.toml Then, in your `wrangler.toml` file, add the following with the values generated in the terminal: @@ -288,7 +288,7 @@ const crawlPage = async (url: string): Promise => { This helper function opens a new page in Puppeteer and navigates to the provided URL. `numCloudflareLinks` uses Puppeteer's `$$eval` (equivalent to `document.querySelectorAll`) to find the number of links to a `cloudflare.com` page. Checking if the link's `href` is to a `cloudflare.com` page is wrapped in a `try...catch` to handle cases where `href`s may not be URLs. -Then, the function sets the browser viewport size and takes a screenshot of the full page. The screenshot is returned as a `Buffer` so it can be converted to an `ArrayBuffer` and written to KV. +Then, the function sets the browser viewport size and takes a screenshot of the full page. The screenshot is returned as a `Buffer` so it can be converted to an `ArrayBuffer` and written to Workers KV. To enable recursively crawling links, add a snippet after checking the number of Cloudflare links to send messages recursively from the queue consumer to the queue itself. Recursing too deep, as is possible with crawling, will cause a Durable Object `Subrequest depth limit exceeded.` error. If one occurs, it is caught, but the links are not retried. @@ -339,11 +339,11 @@ try { // ... ``` -This snippet saves the results from `crawlPage` into the appropriate KV namespaces. If an unexpected error occurred, the URL will be retried and resent to the queue again. +This snippet saves the results from `crawlPage` into the appropriate Workers KV namespaces. If an unexpected error occurred, the URL will be retried and resent to the queue again. -Saving the timestamp of the crawl in KV helps you avoid crawling too frequently. +Saving the timestamp of the crawl in Workers KV helps you avoid crawling too frequently. -Add a snippet before checking `robots.txt` to check KV for a crawl within the last hour. This lists all KV keys beginning with the same URL (crawls of the same page), and check if any crawls have been done within the last hour. If any crawls have been done within the last hour, the message is `ack`'ed and not retried. +Add a snippet before checking `robots.txt` to check Workers KV for a crawl within the last hour. This lists all key-value keys beginning with the same URL (crawls of the same page), and check if any crawls have been done within the last hour. If any crawls have been done within the last hour, the message is `ack`'ed and not retried. ```ts null {12-23} type KeyMetadata = { diff --git a/src/content/docs/r2/api/s3/presigned-urls.mdx b/src/content/docs/r2/api/s3/presigned-urls.mdx index 99fd02874e46a2..e0f43af99bddf9 100644 --- a/src/content/docs/r2/api/s3/presigned-urls.mdx +++ b/src/content/docs/r2/api/s3/presigned-urls.mdx @@ -68,7 +68,7 @@ A valid alternative design to presigned URLs is to use a Worker with a [binding] :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. +A binding is how your Worker interacts with external resources such as [Workers KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. A binding is defined in the `wrangler.toml` file of your Worker project's directory. diff --git a/src/content/docs/r2/api/workers/workers-api-reference.mdx b/src/content/docs/r2/api/workers/workers-api-reference.mdx index bce54fcc9041bd..c8a60095242bd9 100644 --- a/src/content/docs/r2/api/workers/workers-api-reference.mdx +++ b/src/content/docs/r2/api/workers/workers-api-reference.mdx @@ -18,7 +18,7 @@ R2 organizes the data you store, called objects, into containers, called buckets :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. +A binding is how your Worker interacts with external resources such as [Workers KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. A binding is defined in the `wrangler.toml` file of your Worker project's directory. @@ -87,9 +87,9 @@ export default { * `list` * Returns an R2Objects containing a list of R2Object contained within the bucket. - * The returned list of objects is ordered lexicographically. + * The returned list of objects is ordered lexicographically. * Returns up to 1000 entries, but may return less in order to minimize memory pressure within the Worker. - * To explicitly set the number of objects to list, provide an [R2ListOptions](/r2/api/workers/workers-api-reference/#r2listoptions) object with the `limit` property set. + * To explicitly set the number of objects to list, provide an [R2ListOptions](/r2/api/workers/workers-api-reference/#r2listoptions) object with the `limit` property set. * `createMultipartUpload` @@ -125,7 +125,7 @@ export default { :::note -Cloudflare recommends using the `httpEtag` field when returning an etag in a response header. This ensures the etag is quoted and conforms to [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#section-8.8.3). +Cloudflare recommends using the `httpEtag` field when returning an etag in a response header. This ensures the etag is quoted and conforms to [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#section-8.8.3). ::: * The etag associated with the object upload. diff --git a/src/content/docs/r2/api/workers/workers-api-usage.mdx b/src/content/docs/r2/api/workers/workers-api-usage.mdx index c0397e320b600e..16922b356b73bd 100644 --- a/src/content/docs/r2/api/workers/workers-api-usage.mdx +++ b/src/content/docs/r2/api/workers/workers-api-usage.mdx @@ -56,7 +56,7 @@ You will need to bind your bucket to a Worker. :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to the [Environment Variables](/workers/configuration/environment-variables/) documentation for more information. +A binding is how your Worker interacts with external resources such as [Workers KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to the [Environment Variables](/workers/configuration/environment-variables/) documentation for more information. A binding is defined in the `wrangler.toml` file of your Worker project's directory. diff --git a/src/content/docs/radar/investigate/bgp-anomalies.mdx b/src/content/docs/radar/investigate/bgp-anomalies.mdx index b58bfd98ecf3f1..210ce091c6a6ad 100644 --- a/src/content/docs/radar/investigate/bgp-anomalies.mdx +++ b/src/content/docs/radar/investigate/bgp-anomalies.mdx @@ -171,7 +171,7 @@ We will use Cloudflare Workers as the platform and use its Cron Triggers to peri For the app, we would like it to do the following things: - Fetch from Cloudflare API with a given API token. -- Check against Cloudflare KV to know what events are new. +- Check against Cloudflare Workers KV to know what events are new. - Construct messages for new hijacks and send out alerts via webhook triggers. ### Worker app setup @@ -210,7 +210,7 @@ compatibility_date = "2023-04-27" crons = [ "*/5 * * * *" ] ``` -In this example, we will also need to use Cloudflare KV to save the latest checked event IDs which allows us to know what events are new. Once you have created a KV, you can head back to the `wranglers.toml` file and add the following sections: +In this example, we will also need to use Cloudflare Workers KV to save the latest checked event IDs which allows us to know what events are new. Once you have created a Workers KV, you can head back to the `wranglers.toml` file and add the following sections: ```toml [[kv_namespaces]] @@ -261,11 +261,11 @@ export default { } ``` -In our example, we use the `env` variables to get the runtime variables like the TOKEN and ASN of interest, and Cloudflare +In our example, we use the `env` variables to get the runtime variables like the TOKEN and ASN of interest, and Cloudflare Workers KV bindings. We do not use the `controller` and `ctx` variables in this example. First, we will need to learn about what are the new events. We define new events as the events the app has not yet processed. -We use the Cloudflare KV bucket previously created and defined (`HIJACKS_KV`) to save and retrieve the most recent +We use the Cloudflare Workers KV bucket previously created and defined (`HIJACKS_KV`) to save and retrieve the most recent processed event ID. ```javascript @@ -283,7 +283,7 @@ while (true) { const query_params = `per_page=10&page=${page}&involvedAsn=${env.TARGET_ASN}&sortBy=ID&sortOrder=DESC`; const data = await apiFetch(env, query_params); - // first batch, save KV value only + // first batch, save key-value value only if (first_batch) { await env.HIJACKS_KV.put("latest_id", events[0].id.toString()); return; @@ -318,7 +318,7 @@ const kv_latest_id = new_events[new_events.length - 1].id; for (const event of new_events) { await send_alert(env, event); } -// update latest_id KV value +// update latest_id key-value value await env.HIJACKS_KV.put("latest_id", kv_latest_id.toString()); ``` diff --git a/src/content/docs/reference-architecture/architectures/security.mdx b/src/content/docs/reference-architecture/architectures/security.mdx index a6c7f806f6e835..d6d4af47f27f4d 100644 --- a/src/content/docs/reference-architecture/architectures/security.mdx +++ b/src/content/docs/reference-architecture/architectures/security.mdx @@ -607,7 +607,7 @@ In summary, the following diagram details how Cloudflare's SASE services can con ## Developer platform -Many of Cloudflare's security services are built on a highly optimized serverless compute platform based on [V8 Isolates](https://blog.cloudflare.com/cloud-computing-without-containers) which powers our developer platform. Like all our services, serverless compute workloads run on all servers in our global network. While our security services offer a wide range of features, customers always want the ultimate flexibility of writing their own custom solution. Customers therefore can use Cloudflare Workers and its accompanying services (R2, D1, KV, Queues) to interact with network traffic as it flows to and from their resources, as well as implementing complex security logic. +Many of Cloudflare's security services are built on a highly optimized serverless compute platform based on [V8 Isolates](https://blog.cloudflare.com/cloud-computing-without-containers) which powers our developer platform. Like all our services, serverless compute workloads run on all servers in our global network. While our security services offer a wide range of features, customers always want the ultimate flexibility of writing their own custom solution. Customers therefore can use Cloudflare Workers and its accompanying services (R2, D1, Workers KV, Queues) to interact with network traffic as it flows to and from their resources, as well as implementing complex security logic. The following use cases show how our customers’ security teams have used our [developer platform](https://workers.cloudflare.com/): diff --git a/src/content/docs/reference-architecture/diagrams/serverless/a-b-testing-using-workers.mdx b/src/content/docs/reference-architecture/diagrams/serverless/a-b-testing-using-workers.mdx index 503fb21b445cca..5f28f45e36a42c 100644 --- a/src/content/docs/reference-architecture/diagrams/serverless/a-b-testing-using-workers.mdx +++ b/src/content/docs/reference-architecture/diagrams/serverless/a-b-testing-using-workers.mdx @@ -3,7 +3,7 @@ title: A/B-testing using Workers pcx_content_type: reference-architecture-diagram products: - Workers - - KV + - Workers KV sidebar: order: 1 label: A/B-testing using Workers @@ -31,12 +31,12 @@ Cloudflare's low-latency, fully serverless compute platform, [Workers](/workers/ This architecture shows a same-URL A/B testing endpoint. The A/B testing logic and configuration is deployed on the server side, so that clients do not have to implement any changes to make use of A/B testing. 1. **Client**: Sends requests to server. This could be through a desktop or mobile browser, or native or mobile app. -2. **Configuration**: Process incoming request using Workers. Read current configuration by reading from [KV](/kv/) using the [`get()`](/kv/api/read-key-value-pairs/) method. This allows for flexible updates to the A/B services configuration fully decoupled from code-deployment. +2. **Configuration**: Process incoming request using Workers. Read current configuration by reading from [Workers KV](/kv/) using the [`get()`](/kv/api/read-key-value-pairs/) method. This allows for flexible updates to the A/B services configuration fully decoupled from code-deployment. 3. **Origin requests**: Check for already existing cookies in the request headers. If no cookie for group assignment is set, randomly assign a group. If a cookie is set, extract assigned group from the cookie header. Send request to either the control endpoint (A) or variant endpoints (B) depending on the configuration and the assigned group. 4. **Response**: Return the response from the origin. Additionally, if no cookie was previously set, set a cookie with the respective assigned group for session affinity. ## Related resources - [Workers: Get started](/workers/get-started/guide/) -- [KV: Get started](/kv/get-started/) +- [Workers KV: Get started](/kv/get-started/) - [Code Example: A/B testing with same-URL direct access](/workers/examples/ab-testing/) diff --git a/src/content/docs/reference-architecture/diagrams/serverless/fullstack-application.mdx b/src/content/docs/reference-architecture/diagrams/serverless/fullstack-application.mdx index 75f38de6b90fad..99da81a0a9d241 100644 --- a/src/content/docs/reference-architecture/diagrams/serverless/fullstack-application.mdx +++ b/src/content/docs/reference-architecture/diagrams/serverless/fullstack-application.mdx @@ -3,7 +3,7 @@ title: Fullstack applications pcx_content_type: reference-architecture-diagram products: - Workers - - KV + - Workers KV - D1 - Durable Objects - Workers AI @@ -49,7 +49,7 @@ Cloudflare offers all building blocks to build, deploy and operate modern fullst 3. **Performance**: Serve static requests from [global cache (CDN)](/cache/). This reduces latency and lowers resource utilization as the requests are being served from cache instead of requiring a request to storage & media services or compute services. 4. **Static & Media**: Serve static files from [R2](/r2/), optimized images from [Images](/images/) and on-demand videos as well as live streams from [Stream](/stream/). 5. **Compute**: Process dynamic requests using serverless compute with [Workers](/workers/). This could include authentication, routing, middleware, database interactions, and serving APIs. Moreover, use [Pages](/pages/) to serve client side or server side rendering web frameworks such as React, Vue or Angular. Integrate AI services using serverless inference with [Workers AI](/workers-ai/). Both Workers and Pages Functions allow for simple interaction with other resources using [Bindings](/workers/runtime-apis/bindings/). -6. **Data & storage**: Introduce state to applications by persisting and retrieving data. This includes [R2](/r2/) for object storage, [D1](/d1/) for relational data, [KV](/kv/) for data with high read requirements and [Durable Objects](/durable-objects/) for strongly consistent data storage. The [storage options guide](/workers/platform/storage-options/) can help to assess which storage option is the most suitable for a given use case. +6. **Data & storage**: Introduce state to applications by persisting and retrieving data. This includes [R2](/r2/) for object storage, [D1](/d1/) for relational data, [Workers KV](/kv/) for data with high read requirements and [Durable Objects](/durable-objects/) for strongly consistent data storage. The [storage options guide](/workers/platform/storage-options/) can help to assess which storage option is the most suitable for a given use case. 7. **Internal observability**: Send logs from all services with [Logpush](/logs/about/), gather insights with [Analytics](/analytics/) from all services, or collect custom metrics from Workers using [Workers Analytics Engine](/analytics/analytics-engine/). 8. **External integrations**: Integrate Cloudflare's observability solutions with your existing third-party solutions. Logpush has support for many [destinations](/logs/get-started/enable-destinations/) to push logs to for storage and further analysis. Also, Cloudflare analytics can be [integrated with analytics solutions](/analytics/analytics-integrations/). The [GraphQL Analytics API](/analytics/graphql-api/) allows for flexible queries and integrations. 9. **Management & provisioning**: Define and manage resources and configuration using third-party tools and frameworks such as [Terraform](/terraform/) and [Pulumi](/pulumi/), Cloudflare's Developer Platform command-line interface (CLI) [wrangler](/workers/wrangler/), or the [Cloudflare API](/api/). All of these tools can be used either for manual provisioning, or automated as part of CI/CD pipelines. diff --git a/src/content/docs/reference-architecture/diagrams/serverless/serverless-global-apis.mdx b/src/content/docs/reference-architecture/diagrams/serverless/serverless-global-apis.mdx index 14251cccba3881..ed338eb995b406 100644 --- a/src/content/docs/reference-architecture/diagrams/serverless/serverless-global-apis.mdx +++ b/src/content/docs/reference-architecture/diagrams/serverless/serverless-global-apis.mdx @@ -3,7 +3,7 @@ title: Serverless global APIs pcx_content_type: reference-architecture-diagram products: - Workers - - KV + - Workers KV - D1 - Hyperdrive sidebar: @@ -40,7 +40,7 @@ This is an example architecture of a serverless API on Cloudflare and aims to il 1. **Client request**: Send request to API endpoint. 2. **API Gateway/Router**: Process incoming request using [Workers](/workers/), check for validity, and perform authentication logic, if needed. Then, forward the (potentially transformed and/or enriched) API call to individual [Workers](/workers) using [Service Bindings](/workers/runtime-apis/bindings/service-bindings/). This allows for a separation of concerns. -3. **Read-heavy data**: Read from [KV](/kv/) to serve read-heavy, non-dynamic data. This could include configuration data or product information. Perform writes as needed keeping [limits](/kv/platform/limits/) in mind. +3. **Read-heavy data**: Read from [Workers KV](/kv/) to serve read-heavy, non-dynamic data. This could include configuration data or product information. Perform writes as needed keeping [limits](/kv/platform/limits/) in mind. 4. **Relational data**: Query [D1](/d1/) to handle relational-data. This could include user data, product data or other data. 5. **External data**: Query external databases using [Hyperdrive](/hyperdrive/). Leverage caching to improve performance where applicable. This can be especially helpful when a data migration is out of scope of the implementation. diff --git a/src/content/docs/reference-architecture/diagrams/serverless/serverless-image-content-management.mdx b/src/content/docs/reference-architecture/diagrams/serverless/serverless-image-content-management.mdx index e8c802fc5111c4..a57d6e701559b7 100644 --- a/src/content/docs/reference-architecture/diagrams/serverless/serverless-image-content-management.mdx +++ b/src/content/docs/reference-architecture/diagrams/serverless/serverless-image-content-management.mdx @@ -2,7 +2,7 @@ title: Serverless image content management pcx_content_type: reference-architecture-diagram products: - - KV + - Workers KV - R2 - Workers AI - WAF @@ -35,7 +35,7 @@ The servicing of images to requesting clients is secured by link signature, resi | [Workers](https://workers.cloudflare.com/) | Compute of the several serverless micro services | | [AI](https://ai.cloudflare.com/) | Image classification | | [R2](https://www.cloudflare.com/developer-platform/r2/) | S3-type object-storage platform | -| [KV](/kv/) | Image metadata storage | +| [Workers KV](/kv/) | Image metadata storage | ## Getting started diff --git a/src/content/docs/vectorize/reference/what-is-a-vector-database.mdx b/src/content/docs/vectorize/reference/what-is-a-vector-database.mdx index 0602a8484c6cd0..89cbcebdbeb8cc 100644 --- a/src/content/docs/vectorize/reference/what-is-a-vector-database.mdx +++ b/src/content/docs/vectorize/reference/what-is-a-vector-database.mdx @@ -31,7 +31,7 @@ The step-by-step workflow resembles the below: 2. The output embeddings are inserted into a Vectorize database index. 3. A search query, classification request or anomaly detection query is also passed through the same ML model, returning a vector embedding representation of the query. 4. Vectorize is queried with this embedding, and returns a set of the most similar vector embeddings to the provided query. -5. The returned embeddings are used to retrieve the original source objects from dedicated storage (for example, R2, KV, and D1) and returned back to the user. +5. The returned embeddings are used to retrieve the original source objects from dedicated storage (for example, R2, Workers KV, and D1) and returned back to the user. In a workflow without a vector database, you would need to pass your entire dataset alongside your query each time, which is neither practical (models have limits on input size) and would consume significant resources and time. diff --git a/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx b/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx index 894102287d8fbe..a334b06475960a 100644 --- a/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx +++ b/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx @@ -1,8 +1,8 @@ --- pcx_content_type: navigation -title: Use KV API +title: Use Workers KV API products: - - KV + - Workers KV tags: - AI sidebar: @@ -15,13 +15,13 @@ In this example we show how embedded function calling can interact with other re ## Pre-Requisites -For this example to work, you need to provision a [KV](/kv/) namespace first. To do so, follow the [KV - Get started ](/kv/get-started/) guide. +For this example to work, you need to provision a [Workers KV](/kv/) namespace first. To do so, follow the [Workers KV - Get started ](/kv/get-started/) guide. Importantly, your `wrangler.toml` file must be updated to include the `KV` binding definition to your respective namespace. ## Worker code -```ts title="Embedded function calling example with KV API" +```ts title="Embedded function calling example with Workers KV API" import { runWithTools } from "@cloudflare/ai-utils"; type Env = { diff --git a/src/content/docs/workers-ai/privacy.mdx b/src/content/docs/workers-ai/privacy.mdx index 5f591334458b59..81478b0fe4e5a9 100644 --- a/src/content/docs/workers-ai/privacy.mdx +++ b/src/content/docs/workers-ai/privacy.mdx @@ -20,4 +20,4 @@ For Workers AI: * You own, and are responsible for, all of your Customer Content. * Cloudflare does not make your Customer Content available to any other Cloudflare customer. * Cloudflare does not use your Customer Content to (1) train any AI models made available on Workers AI or (2) improve any Cloudflare or third-party services, and would not do so unless we received your explicit consent. -* Your Customer Content for Workers AI may be stored by Cloudflare if you specifically use a storage service (e.g., R2, KV, DO, Vectorize, etc.) in conjunction with Workers AI. +* Your Customer Content for Workers AI may be stored by Cloudflare if you specifically use a storage service (e.g., R2, Workers KV, DO, Vectorize, etc.) in conjunction with Workers AI. diff --git a/src/content/docs/workers/configuration/versions-and-deployments/index.mdx b/src/content/docs/workers/configuration/versions-and-deployments/index.mdx index cf835f30578db9..14e53ca1e0cb43 100644 --- a/src/content/docs/workers/configuration/versions-and-deployments/index.mdx +++ b/src/content/docs/workers/configuration/versions-and-deployments/index.mdx @@ -32,7 +32,7 @@ A version is defined by the state of code as well as the state of configuration Versions also track metadata associated with a version, including: the version ID, the user that created the version, deploy source, and timestamp. Optionally, a version message and version tag can be configured on version upload. :::note -State changes for associated Workers [storage resources](/workers/platform/storage-options/) such as [KV](/kv/), [R2](/r2/), [Durable Objects](/durable-objects/) and [D1](/d1/) are not tracked with versions. +State changes for associated Workers [storage resources](/workers/platform/storage-options/) such as [Workers KV](/kv/), [R2](/r2/), [Durable Objects](/durable-objects/) and [D1](/d1/) are not tracked with versions. ::: ## Deployments diff --git a/src/content/docs/workers/configuration/versions-and-deployments/rollbacks.mdx b/src/content/docs/workers/configuration/versions-and-deployments/rollbacks.mdx index d5545da72fef2d..d85b2df4761e93 100644 --- a/src/content/docs/workers/configuration/versions-and-deployments/rollbacks.mdx +++ b/src/content/docs/workers/configuration/versions-and-deployments/rollbacks.mdx @@ -35,7 +35,7 @@ You can only roll back to the 10 most recently published versions. ### Bindings -You cannot roll back to a previous version of your Worker if the [Cloudflare Developer Platform resources](/workers/runtime-apis/bindings/) (such as [KV](/kv/) and [D1](/d1/)) have been deleted or modified between the version selected to roll back to and the version in the active deployment. Specifically, rollbacks will not be allowed if: +You cannot roll back to a previous version of your Worker if the [Cloudflare Developer Platform resources](/workers/runtime-apis/bindings/) (such as [Workers KV](/kv/) and [D1](/d1/)) have been deleted or modified between the version selected to roll back to and the version in the active deployment. Specifically, rollbacks will not be allowed if: * A [Durable Object migration](/durable-objects/reference/durable-objects-migrations/) has occurred between the version in the active deployment and the version selected to roll back to. -* If the target deployment has a [binding](/workers/runtime-apis/bindings/) to an R2 bucket, KV namespace, or queue that no longer exists. +* If the target deployment has a [binding](/workers/runtime-apis/bindings/) to an R2 bucket, Workers KV namespace, or queue that no longer exists. diff --git a/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx b/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx index 327076f37162a3..494dbb82843a81 100644 --- a/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx +++ b/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx @@ -97,13 +97,13 @@ Add the following to the scripts field of your `package.json` file: To enable caching, you must: -#### Create a KV namespace +#### Create a Workers KV namespace ```sh npx wrangler@latest kv namespace create NEXT_CACHE_WORKERS_KV ``` -#### Add the KV namespace to your Worker +#### Add the Workers KV namespace to your Worker ```toml [[kv_namespaces]] @@ -113,7 +113,7 @@ id = "" #### Set the name of the binding to `NEXT_CACHE_WORKERS_KV` -As shown above, the name of the binding that you configure for the KV namespace must be set to `NEXT_CACHE_WORKERS_KV`. +As shown above, the name of the binding that you configure for the Workers KV namespace must be set to `NEXT_CACHE_WORKERS_KV`. ### 5. Develop locally diff --git a/src/content/docs/workers/index.mdx b/src/content/docs/workers/index.mdx index ffdd315019619b..ade4442d844842 100644 --- a/src/content/docs/workers/index.mdx +++ b/src/content/docs/workers/index.mdx @@ -53,7 +53,7 @@ The Workers command-line interface, Wrangler, allows you to [create](/workers/wr -Bindings allow your Workers to interact with resources on the Cloudflare developer platform, including [R2](/r2/), [KV](/kv/concepts/how-kv-works/), [Durable Objects](/durable-objects/), and [D1](/d1/). +Bindings allow your Workers to interact with resources on the Cloudflare developer platform, including [R2](/r2/), [Workers KV](/kv/concepts/how-kv-works/), [Durable Objects](/durable-objects/), and [D1](/d1/). diff --git a/src/content/docs/workers/languages/python/ffi.mdx b/src/content/docs/workers/languages/python/ffi.mdx index 7b4ef05772b722..088fce64d5e039 100644 --- a/src/content/docs/workers/languages/python/ffi.mdx +++ b/src/content/docs/workers/languages/python/ffi.mdx @@ -10,7 +10,7 @@ head: Via [Pyodide](https://pyodide.org/en/stable/), Python Workers provide a [Foreign Function Interface (FFI)](https://en.wikipedia.org/wiki/Foreign_function_interface) to JavaScript. This allows you to: -* Use [bindings](/workers/runtime-apis/bindings/) to resources on Cloudflare, including [Workers AI](/workers-ai/), [Vectorize](/vectorize/), [R2](/r2/), [KV](/kv/), [D1](/d1/), [Queues](/queues/), [Durable Objects](/durable-objects/), [Service Bindings](/workers/runtime-apis/bindings/service-bindings/) and more. +* Use [bindings](/workers/runtime-apis/bindings/) to resources on Cloudflare, including [Workers AI](/workers-ai/), [Vectorize](/vectorize/), [R2](/r2/), [Workers KV](/kv/), [D1](/d1/), [Queues](/queues/), [Durable Objects](/durable-objects/), [Service Bindings](/workers/runtime-apis/bindings/service-bindings/) and more. * Use JavaScript globals, like [`Request`](/workers/runtime-apis/request/), [`Response`](/workers/runtime-apis/response/), and [`fetch()`](/workers/runtime-apis/fetch/). * Use the full feature set of Cloudflare Workers — if an API is accessible in JavaScript, you can also access it in a Python Worker, writing exclusively Python code. @@ -20,7 +20,7 @@ The details of Pyodide's Foreign Function Interface are documented [here](https: Bindings allow your Worker to interact with resources on the Cloudflare Developer Platform. When you declare a binding on your Worker, you grant it a specific capability, such as being able to read and write files to an [R2](/r2/) bucket. -For example, to access a [KV](/kv) namespace from a Python Worker, you would declare the following in your Worker's [`wrangler.toml`](/workers/wrangler/configuration/): +For example, to access a [Workers KV](/kv) namespace from a Python Worker, you would declare the following in your Worker's [`wrangler.toml`](/workers/wrangler/configuration/): ```toml main = "./src/index.py" diff --git a/src/content/docs/workers/languages/python/index.mdx b/src/content/docs/workers/languages/python/index.mdx index 0a428ebeb13f7f..8c03ee877957fd 100644 --- a/src/content/docs/workers/languages/python/index.mdx +++ b/src/content/docs/workers/languages/python/index.mdx @@ -14,7 +14,7 @@ description: Write Workers in 100% Python Cloudflare Workers provides first-class support for Python, including support for: - The majority of Python's [Standard library](/workers/languages/python/stdlib/) -- All [bindings](/workers/runtime-apis/bindings/), including [Workers AI](/workers-ai/), [Vectorize](/vectorize), [R2](/r2), [KV](/kv), [D1](/d1), [Queues](/queues/), [Durable Objects](/durable-objects/), [Service Bindings](/workers/runtime-apis/bindings/service-bindings/) and more. +- All [bindings](/workers/runtime-apis/bindings/), including [Workers AI](/workers-ai/), [Vectorize](/vectorize), [R2](/r2), [Workers KV](/kv), [D1](/d1), [Queues](/queues/), [Durable Objects](/durable-objects/), [Service Bindings](/workers/runtime-apis/bindings/service-bindings/) and more. - [Environment Variables](/workers/configuration/environment-variables/), and [Secrets](/workers/configuration/secrets/) - A robust [foreign function interface (FFI)](/workers/languages/python/ffi) that lets you use JavaScript objects and functions directly from Python — including all [Runtime APIs](/workers/runtime-apis/) - [Built-in packages](/workers/languages/python/packages), including [FastAPI](https://fastapi.tiangolo.com/), [Langchain](https://pypi.org/project/langchain/), [httpx](https://www.python-httpx.org/) and more. diff --git a/src/content/docs/workers/languages/rust/index.mdx b/src/content/docs/workers/languages/rust/index.mdx index 0d6160ac3ab0a6..dea580395ce82e 100644 --- a/src/content/docs/workers/languages/rust/index.mdx +++ b/src/content/docs/workers/languages/rust/index.mdx @@ -111,7 +111,7 @@ Provides access to Worker [bindings](/workers/runtime-apis/bindings/). - [`Secret`](https://github.com/cloudflare/workers-rs/blob/e15f88110d814c2d7759b2368df688433f807694/worker/src/env.rs#L92) - Secret value configured in Cloudflare dashboard or using `wrangler secret put`. - [`Var`](https://github.com/cloudflare/workers-rs/blob/e15f88110d814c2d7759b2368df688433f807694/worker/src/env.rs#L92) - Environment variable defined in `wrangler.toml`. -- [`KvStore`](https://docs.rs/worker-kv/latest/worker_kv/struct.KvStore.html) - Workers [KV](/kv/api/) namespace binding. +- [`KvStore`](https://docs.rs/worker-kv/latest/worker_kv/struct.KvStore.html) - [Workers KV](/kv/api/) namespace binding. - [`ObjectNamespace`](https://docs.rs/worker/latest/worker/durable/struct.ObjectNamespace.html) - [Durable Object](/durable-objects/) binding. - [`Fetcher`](https://docs.rs/worker/latest/worker/struct.Fetcher.html) - [Service binding](/workers/runtime-apis/bindings/service-bindings/) to another Worker. - [`Bucket`](https://docs.rs/worker/latest/worker/struct.Bucket.html) - [R2](/r2/) Bucket binding. diff --git a/src/content/docs/workers/observability/logs/tail-workers.mdx b/src/content/docs/workers/observability/logs/tail-workers.mdx index 70a20fa15d5ab9..56cd417a27acff 100644 --- a/src/content/docs/workers/observability/logs/tail-workers.mdx +++ b/src/content/docs/workers/observability/logs/tail-workers.mdx @@ -17,7 +17,7 @@ Tail Workers are available to all customers on the Workers Paid and Enterprise t ![Tail Worker diagram](~/assets/images/workers/platform/tail-workers.png) -A Tail Worker is automatically invoked after the invocation of a producer Worker (the Worker the Tail Worker will track) that contains the application logic. It captures events after the producer has finished executing. You can filter, change the format of the data and send events to any HTTP endpoint. For quick debugging, Tail Workers can be used to send logs to [KV](/kv/api/) or any database. +A Tail Worker is automatically invoked after the invocation of a producer Worker (the Worker the Tail Worker will track) that contains the application logic. It captures events after the producer has finished executing. You can filter, change the format of the data and send events to any HTTP endpoint. For quick debugging, Tail Workers can be used to send logs to [Workers KV](/kv/api/) or any database. ## Configure Tail Workers diff --git a/src/content/docs/workers/platform/changelog/historical-changelog.mdx b/src/content/docs/workers/platform/changelog/historical-changelog.mdx index 278da58f5bf9d2..82c2ef3c178a8f 100644 --- a/src/content/docs/workers/platform/changelog/historical-changelog.mdx +++ b/src/content/docs/workers/platform/changelog/historical-changelog.mdx @@ -471,7 +471,7 @@ We chose the limit of 6 concurrent connections based on the fact that Chrome enf Changes this week: * Durable Objects storage API now supports listing keys by prefix. -* Improved error message when a single request performs more than 1000 KV operations to make clear that a per-request limit was reached, not a global rate limit. +* Improved error message when a single request performs more than 1000 key-value operations to make clear that a per-request limit was reached, not a global rate limit. * `wrangler dev` previews should now honor non-default resource limits, for example, longer CPU limits for those in the Workers Unbound beta. * Fixed off-by-one line numbers in Worker exceptions. * Exceptions thrown in a Durable Object’s `fetch()` method are now tunneled to its caller. diff --git a/src/content/docs/workers/platform/limits.mdx b/src/content/docs/workers/platform/limits.mdx index c56c798ad16f59..0578191805715c 100644 --- a/src/content/docs/workers/platform/limits.mdx +++ b/src/content/docs/workers/platform/limits.mdx @@ -164,7 +164,7 @@ Using DevTools locally can help identify memory leaks in your code. See the [mem ## Subrequests -A subrequest is any request that a Worker makes to either Internet resources using the [Fetch API](/workers/runtime-apis/fetch/) or requests to other Cloudflare services like [R2](/r2/), [KV](/kv/), or [D1](/d1/). +A subrequest is any request that a Worker makes to either Internet resources using the [Fetch API](/workers/runtime-apis/fetch/) or requests to other Cloudflare services like [R2](/r2/), [Workers KV](/kv/), or [D1](/d1/). ### Worker-to-Worker subrequests @@ -332,6 +332,6 @@ If your Worker is on a Bundled plan, your limits are the same as the Workers Pai Review other developer platform resource limits. -- [KV limits](/kv/platform/limits/) +- [Workers KV limits](/kv/platform/limits/) - [Durable Object limits](/durable-objects/platform/limits/) - [Queues limits](/queues/platform/limits/) diff --git a/src/content/docs/workers/platform/pricing.mdx b/src/content/docs/workers/platform/pricing.mdx index 605f8d31417ec2..e617836d0c54db 100644 --- a/src/content/docs/workers/platform/pricing.mdx +++ b/src/content/docs/workers/platform/pricing.mdx @@ -101,7 +101,7 @@ If you had a Worker on the Bundled usage model prior to the migration to Standar :::note -Some Workers Enterprise customers maintain the ability to change usage models. +Some Workers Enterprise customers maintain the ability to change usage models. Usage models may be changed at the individual Worker level: @@ -144,9 +144,9 @@ destination after applying filtering or sampling. -:::note[KV documentation] +:::note[Workers KV documentation] -To learn more about KV, refer to the [KV documentation](/kv/). +To learn more about Workers KV, refer to the [Workers KV documentation](/kv/). ::: diff --git a/src/content/docs/workers/platform/storage-options.mdx b/src/content/docs/workers/platform/storage-options.mdx index 181a7209b77cc3..3594101cb1a9e6 100644 --- a/src/content/docs/workers/platform/storage-options.mdx +++ b/src/content/docs/workers/platform/storage-options.mdx @@ -75,12 +75,12 @@ It is ideal for projects that require: - Per-object time-to-live (TTL). - Distributed configuration. -To get started with KV: +To get started with Workers KV: -- Read how [KV works](/kv/concepts/how-kv-works/). -- Create a [KV namespace](/kv/concepts/kv-namespaces/). -- Review the [KV Runtime API](/kv/api/). -- Learn about KV [Limits](/kv/platform/limits/). +- Read how [Workers KV works](/kv/concepts/how-kv-works/). +- Create a [Workers KV namespace](/kv/concepts/kv-namespaces/). +- Review the [Workers KV Runtime API](/kv/api/). +- Learn about Workers KV [Limits](/kv/platform/limits/). ## R2 diff --git a/src/content/docs/workers/reference/migrate-to-module-workers.mdx b/src/content/docs/workers/reference/migrate-to-module-workers.mdx index 80b67b008ee68a..04d99560a595d9 100644 --- a/src/content/docs/workers/reference/migrate-to-module-workers.mdx +++ b/src/content/docs/workers/reference/migrate-to-module-workers.mdx @@ -59,11 +59,11 @@ export default { Workers using ES modules format do not rely on any global bindings. However, Service Worker syntax accesses bindings on the global scope. -To understand bindings, refer the following `TODO` KV namespace binding example. To create a `TODO` KV namespace binding, you will: +To understand bindings, refer the following `TODO` Workers KV namespace binding example. To create a `TODO` Workers KV namespace binding, you will: -1. Create a KV namespace named `My Tasks` and receive an ID that you will use in your binding. +1. Create a Workers KV namespace named `My Tasks` and receive an ID that you will use in your binding. 2. Create a Worker. -3. Find your Worker's `wrangler.toml` configuration file and add a KV namespace binding: +3. Find your Worker's `wrangler.toml` configuration file and add a Workers KV namespace binding: ```toml kv_namespaces = [ @@ -73,17 +73,17 @@ kv_namespaces = [ In the following sections, you will use your binding in Service Worker and ES modules format. -:::note[Reference KV from Durable Objects and Workers] +:::note[Reference Workers KV from Durable Objects and Workers] -To learn more about how to reference KV from Workers, refer to the [KV bindings documentation](/kv/concepts/kv-bindings/). +To learn more about how to reference Workers KV from Workers, refer to the [Workers KV bindings documentation](/kv/concepts/kv-bindings/). ::: ### Bindings in Service Worker format -In Service Worker syntax, your `TODO` KV namespace binding is defined in the global scope of your Worker. Your `TODO` KV namespace binding is available to use anywhere in your Worker application's code. +In Service Worker syntax, your `TODO` Workers KV namespace binding is defined in the global scope of your Worker. Your `TODO` Workers KV namespace binding is available to use anywhere in your Worker application's code. ```js addEventListener("fetch", async (event) => { @@ -104,7 +104,7 @@ async function getTodos() { In ES modules format, bindings are only available inside the `env` parameter that is provided at the entry point to your Worker. -To access the `TODO` KV namespace binding in your Worker code, the `env` parameter must be passed from the `fetch` handler in your Worker to the `getTodos` function. +To access the `TODO` Workers KV namespace binding in your Worker code, the `env` parameter must be passed from the `fetch` handler in your Worker to the `getTodos` function. ```js import { getTodos } from './todos' @@ -118,7 +118,7 @@ export default { }; ``` -The following code represents a `getTodos` function that calls the `get` function on the `TODO` KV binding. +The following code represents a `getTodos` function that calls the `get` function on the `TODO` Workers KV binding. ```js async function getTodos(env) { diff --git a/src/content/docs/workers/runtime-apis/bindings/kv.mdx b/src/content/docs/workers/runtime-apis/bindings/kv.mdx index bb867bf3a8cb63..8092c926cc183e 100644 --- a/src/content/docs/workers/runtime-apis/bindings/kv.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/kv.mdx @@ -1,6 +1,6 @@ --- pcx_content_type: navigation -title: KV +title: Workers KV external_link: /kv/api/ head: [] description: Global, low-latency, key-value data storage. diff --git a/src/content/docs/workers/runtime-apis/handlers/scheduled.mdx b/src/content/docs/workers/runtime-apis/handlers/scheduled.mdx index 8ad8e0bfb6ec83..171abbdd072694 100644 --- a/src/content/docs/workers/runtime-apis/handlers/scheduled.mdx +++ b/src/content/docs/workers/runtime-apis/handlers/scheduled.mdx @@ -49,7 +49,7 @@ export default { - `env` object - - An object containing the bindings associated with your Worker using ES modules format, such as KV namespaces and Durable Objects. + - An object containing the bindings associated with your Worker using ES modules format, such as Workers KV namespaces and Durable Objects. - `ctx` object - An object containing the context associated with your Worker using ES modules format. Currently, this object just contains the `waitUntil` function. diff --git a/src/content/docs/workers/runtime-apis/handlers/tail.mdx b/src/content/docs/workers/runtime-apis/handlers/tail.mdx index 8f400ea6f11d60..bee7f7b4e0087b 100644 --- a/src/content/docs/workers/runtime-apis/handlers/tail.mdx +++ b/src/content/docs/workers/runtime-apis/handlers/tail.mdx @@ -35,7 +35,7 @@ export default { * `env` object - * An object containing the bindings associated with your Worker using [ES modules format](/workers/reference/migrate-to-module-workers/), such as KV namespaces and Durable Objects. + * An object containing the bindings associated with your Worker using [ES modules format](/workers/reference/migrate-to-module-workers/), such as Workers KV namespaces and Durable Objects. * `ctx` object * An object containing the context associated with your Worker using [ES modules format](/workers/reference/migrate-to-module-workers/). Currently, this object just contains the `waitUntil` function. @@ -109,7 +109,7 @@ export default { Outcome is equivalent to the exit status of a script and an indicator of whether it has fully run to completion. A Worker outcome may differ from a response code if, for example: * a script successfully processes a request but is logically designed to return a `4xx`/`5xx` response. -* a script sends a successful `200` response but an asynchronous task registered via `waitUntil()` later exceeds CPU or memory limits. +* a script sends a successful `200` response but an asynchronous task registered via `waitUntil()` later exceeds CPU or memory limits. ::: ### `FetchEventInfo` diff --git a/src/content/docs/workers/static-assets/compatibility-matrix.mdx b/src/content/docs/workers/static-assets/compatibility-matrix.mdx index 4415e1e3997a94..296da02b7095fc 100644 --- a/src/content/docs/workers/static-assets/compatibility-matrix.mdx +++ b/src/content/docs/workers/static-assets/compatibility-matrix.mdx @@ -60,8 +60,8 @@ We plan to bridge the gaps between Workers and Pages and provide ways to migrate | [D1](/d1/build-with-d1/d1-client-api/) | ✅ | ✅ | | [Email Workers](/email-routing/email-workers/send-email-workers/) | ✅ | ❌ | | [Environment Variables](/workers/configuration/environment-variables/) | ✅ | ✅ | -| [Hyperdrive](/hyperdrive/) | ✅ | ✅ | -| [KV](/kv/) | ✅ | ✅ | +| [Hyperdrive](/hyperdrive/) | ✅ | ❌ | +| [Workers KV](/kv/) | ✅ | ✅ | | [mTLS](/workers/runtime-apis/bindings/mtls/) | ✅ | ✅ | | [Queue Producers](/queues/configuration/configure-queues/#producer) | ✅ | ✅ | | [Queue Consumers](/queues/configuration/configure-queues/#consumer) | ✅ | ❌ | diff --git a/src/content/docs/workers/testing/local-development.mdx b/src/content/docs/workers/testing/local-development.mdx index e19bf6719c02c7..f09e8045d1cc35 100644 --- a/src/content/docs/workers/testing/local-development.mdx +++ b/src/content/docs/workers/testing/local-development.mdx @@ -9,7 +9,7 @@ description: Develop your Workers locally via Wrangler. Cloudflare Workers and most connected resources can be fully developed and tested locally - providing confidence that the applications you build locally will work the same way in production. This allows you to be more efficient and effective by providing a faster feedback loop and removing the need to test against remote resources. Local development runs against the same production runtime used by Cloudflare Workers, [workerd](https://github.com/cloudflare/workerd). -In addition to testing Workers locally with [`wrangler dev`](/workers/wrangler/commands/#dev), the use of Miniflare allows you to test other Developer Platform products locally, such as [R2](/r2/), [KV](/kv/), [D1](/d1/), and [Durable Objects](/durable-objects/). +In addition to testing Workers locally with [`wrangler dev`](/workers/wrangler/commands/#dev), the use of Miniflare allows you to test other Developer Platform products locally, such as [R2](/r2/), [Workers KV](/kv/), [D1](/d1/), and [Durable Objects](/durable-objects/). ## Start a local development server @@ -27,7 +27,7 @@ Wrangler provides a [`dev`](/workers/wrangler/commands/#dev) command that starts npx wrangler dev ``` -`wrangler dev` will run the Worker directly on your local machine. `wrangler dev` uses a combination of `workerd` and [Miniflare](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare), a simulator that allows you to test your Worker against additional resources like KV, Durable Objects, WebSockets, and more. +`wrangler dev` will run the Worker directly on your local machine. `wrangler dev` uses a combination of `workerd` and [Miniflare](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare), a simulator that allows you to test your Worker against additional resources like Workers KV, Durable Objects, WebSockets, and more. ### Supported resource bindings in different environments @@ -41,7 +41,7 @@ npx wrangler dev | Durable Objects | ✅ | ✅ | | Email Bindings | ❌ | ✅ | | Hyperdrive | ✅ | ✅ | -| KV | ✅ | ✅ | +| Workers KV | ✅ | ✅ | | mTLS | ❌ | ✅ | | Queues | ✅ | ❌ | | R2 | ✅ | ✅ | @@ -57,7 +57,7 @@ With any bindings that are not supported locally, you will need to use the `--re ## Work with local data -When running `wrangler dev`, resources such as KV, Durable Objects, D1, and R2 will be stored and persisted locally and not affect the production resources. +When running `wrangler dev`, resources such as Workers KV, Durable Objects, D1, and R2 will be stored and persisted locally and not affect the production resources. ### Use bindings in `wrangler.toml` @@ -90,7 +90,7 @@ The following [Wrangler commands](/workers/wrangler/commands/) have a `--local` | [`kv:bulk`](/workers/wrangler/commands/#kv-bulk) | | [`r2 object`](/workers/wrangler/commands/#r2-object) | -If using `--persist-to` to specify a custom folder with `wrangler dev` you should also add `--persist-to` with the same directory name along with the `--local` flag when running the commands above. For example, to put a custom KV key into a local namespace via the CLI you would run: +If using `--persist-to` to specify a custom folder with `wrangler dev` you should also add `--persist-to` with the same directory name along with the `--local` flag when running the commands above. For example, to put a custom key-value key into a local namespace via the CLI you would run: ```sh npx wrangler kv:key put test 12345 --binding MY_KV_NAMESPACE --local --persist-to worker-local @@ -121,7 +121,7 @@ There may be times you want to develop against remote resources and bindings. To npx wrangler dev --remote ``` -For some products like KV and R2, remote resources used for `wrangler dev --remote` must be specified with preview ID/names in `wrangler.toml` such as `preview_id` for KV or `preview_bucket name` for R2. Resources used for remote mode (preview) can be different from resources used for production to prevent changing production data during development. To use production data in `wrangler dev --remote`, set the preview ID/name of the resource to the ID/name of your production resource. +For some products like Workers KV and R2, remote resources used for `wrangler dev --remote` must be specified with preview ID/names in `wrangler.toml` such as `preview_id` for Workers KV or `preview_bucket name` for R2. Resources used for remote mode (preview) can be different from resources used for production to prevent changing production data during development. To use production data in `wrangler dev --remote`, set the preview ID/name of the resource to the ID/name of your production resource. ## Customize `wrangler dev` diff --git a/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx b/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx index 0c5f2b8360c172..48b189ab23da8a 100644 --- a/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx +++ b/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx @@ -82,7 +82,7 @@ export default defineWorkersConfig({ }); ``` -This configuration would add a KV namespace `TEST_NAMESPACE` that was only accessible in tests. Using this method, you can add or override existing bindings like Durable Objects or service bindings. +This configuration would add a Workers KV namespace `TEST_NAMESPACE` that was only accessible in tests. Using this method, you can add or override existing bindings like Durable Objects or service bindings. :::note diff --git a/src/content/docs/workers/testing/vitest-integration/known-issues.mdx b/src/content/docs/workers/testing/vitest-integration/known-issues.mdx index 3bd3186cafc0a4..672bd229cff19b 100644 --- a/src/content/docs/workers/testing/vitest-integration/known-issues.mdx +++ b/src/content/docs/workers/testing/vitest-integration/known-issues.mdx @@ -16,7 +16,7 @@ Native code coverage via [V8](https://v8.dev/blog/javascript-code-coverage) is n ### Fake timers -Vitest's [fake timers](https://vitest.dev/guide/mocking.html#timers) do not apply to KV, R2 and cache simulators. For example, you cannot expire a KV key by advancing fake time. +Vitest's [fake timers](https://vitest.dev/guide/mocking.html#timers) do not apply to KV, R2 and cache simulators. For example, you cannot expire a key-value key by advancing fake time. ### Dynamic `import()` statements with `SELF` and Durable Objects diff --git a/src/content/docs/workers/testing/vitest-integration/recipes.mdx b/src/content/docs/workers/testing/vitest-integration/recipes.mdx index b35d095c17c808..3ea5fa39433f1c 100644 --- a/src/content/docs/workers/testing/vitest-integration/recipes.mdx +++ b/src/content/docs/workers/testing/vitest-integration/recipes.mdx @@ -12,7 +12,7 @@ Recipes are examples that help demonstrate how to write unit tests and integrati - [Basic unit and integration tests using `SELF`](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/basics-unit-integration-self) - [Basic integration tests using an auxiliary Worker](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/basics-integration-auxiliary) -- [Isolated tests using KV, R2 and the Cache API](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/kv-r2-caches) +- [Isolated tests using Workers KV, R2 and the Cache API](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/kv-r2-caches) - [Isolated tests using D1 with migrations](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/d1) - [Isolated tests using Durable Objects with direct access](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/durable-objects) - [Tests using Queue producers and consumers](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/queues) diff --git a/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx b/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx index 5cb3989db1e892..76018f0b00adb2 100644 --- a/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx +++ b/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx @@ -5,7 +5,7 @@ content_type: 📝 Tutorial pcx_content_type: tutorial title: Build a todo list Jamstack application products: - - KV + - Workers KV languages: - JavaScript --- @@ -67,21 +67,21 @@ When a Worker receives a `request`, the Worker returns the newly constructed res Any project you deploy to Cloudflare Workers can make use of modern JavaScript tooling like [ES modules](/workers/reference/migrate-to-module-workers/), `npm` packages, and [`async`/`await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) functions to build your application. In addition to writing Workers, you can use Workers to [build full applications](/workers/tutorials/build-a-slackbot/) using the same tooling and process as in this tutorial. -In this tutorial, you will build a todo list application running on Workers that allows reading data from a [KV](/kv/) store and using the data to populate an HTML response to send to the client. +In this tutorial, you will build a todo list application running on Workers that allows reading data from a [Workers KV](/kv/) store and using the data to populate an HTML response to send to the client. The work needed to create this application is split into three tasks: -1. Write data to KV. -2. Rendering data from KV. +1. Write data to Workers KV. +2. Rendering data from Workers KV. 3. Adding todos from the application UI. For the remainder of this tutorial you will complete each task, iterating on your application, and then publish it to your own domain. -## 3. Write data to KV +## 3. Write data to Workers KV -To begin, you need to understand how to populate your todo list with actual data. To do this, use [Cloudflare Workers KV](/kv/) — a key-value store that you can access inside of your Worker to read and write data. +To begin, you need to understand how to populate your todo list with actual data. To do this, use [Workers KV](/kv/) — a key-value store that you can access inside of your Worker to read and write data. -To get started with KV, set up a namespace. All of your cached data will be stored inside that namespace and, with configuration, you can access that namespace inside the Worker with a predefined variable. Use Wrangler to create a new namespace called `TODOS` with the [`kv:namespace create` command](/workers/wrangler/commands/#create-3) and get the associated namespace ID by running the following command in your terminal: +To get started with Workers KV, set up a namespace. All of your cached data will be stored inside that namespace and, with configuration, you can access that namespace inside the Worker with a predefined variable. Use Wrangler to create a new namespace called `TODOS` with the [`kv:namespace create` command](/workers/wrangler/commands/#create-3) and get the associated namespace ID by running the following command in your terminal: ```sh title="Create a new KV namespace" npx wrangler kv:namespace create "TODOS" --preview @@ -95,7 +95,7 @@ kv_namespaces = [ ] ``` -The defined namespace, `TODOS`, will now be available inside of your codebase. With that, it is time to understand the [KV API](/kv/api/). A KV namespace has three primary methods you can use to interface with your cache: `get`, `put`, and `delete`. +The defined namespace, `TODOS`, will now be available inside of your codebase. With that, it is time to understand the [Workers KV API](/kv/api/). A Workers KV namespace has three primary methods you can use to interface with your cache: `get`, `put`, and `delete`. Start storing data by defining an initial set of data, which you will put inside of the cache using the `put` method. The following example defines a `defaultData` object instead of an array of todo items. You may want to store metadata and other information inside of this cache object later on. Given that data object, use `JSON.stringify` to add a string into the cache: @@ -151,7 +151,7 @@ export default { }; ``` -## Render data from KV +## Render data from Workers KV Given the presence of data in your code, which is the cached data object for your application, you should take this data and render it in a user interface. @@ -226,7 +226,7 @@ const html = ` `; ``` -Your static page can take in `window.todos` and render HTML based on it, but you have not actually passed in any data from KV. To do this, you will need to make a few changes. +Your static page can take in `window.todos` and render HTML based on it, but you have not actually passed in any data from Workers KV. To do this, you will need to make a few changes. First, your `html` variable will change to a function. The function will take in a `todos` argument, which will populate the `window.todos` variable in the above code sample: @@ -257,9 +257,9 @@ async fetch (request, env, ctx) { ## 4. Add todos from the user interface (UI) -At this point, you have built a Cloudflare Worker that takes data from Cloudflare KV and renders a static page based on that Worker. That static page reads data and generates a todo list based on that data. The remaining task is creating todos from inside the application UI. You can add todos using the KV API — update the cache by running `env.TODOS.put(newData)`. +At this point, you have built a Cloudflare Worker that takes data from Cloudflare Workers KV and renders a static page based on that Worker. That static page reads data and generates a todo list based on that data. The remaining task is creating todos from inside the application UI. You can add todos using the Workers KV API — update the cache by running `env.TODOS.put(newData)`. -To update a todo item, you will add a second handler in your Workers script, designed to watch for `PUT` requests to `/`. When a request body is received at that URL, the Worker will send the new todo data to your KV store. +To update a todo item, you will add a second handler in your Workers script, designed to watch for `PUT` requests to `/`. When a request body is received at that URL, the Worker will send the new todo data to your key-value store. Add this new functionality in `fetch`: if the request method is a PUT, it will take the request body and update the cache. @@ -496,7 +496,7 @@ const html = (todos) => ` `; ``` -The final result of your code is a system that checks the `todos` variable, updates your Cloudflare KV cache with that value, and then does a re-render of the UI based on the data it has locally. +The final result of your code is a system that checks the `todos` variable, updates your Cloudflare Workers KV cache with that value, and then does a re-render of the UI based on the data it has locally. ## 6. Conclusion and next steps diff --git a/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx b/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx index 90718cabc4cf4b..d91d9cfa5a5128 100644 --- a/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx +++ b/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx @@ -5,7 +5,7 @@ content_type: 📝 Tutorial pcx_content_type: tutorial title: Use Workers KV directly from Rust products: - - KV + - Workers KV languages: - Rust --- @@ -42,9 +42,9 @@ Then select `template/hello-world-http` template, give your project a descriptiv In this tutorial, you will use Workers KV from Rust to build an app to store and retrieve cities by a given country name. -## 2. Create a KV namespace +## 2. Create a Workers KV namespace -In the terminal, use Wrangler to create a KV namespace for `cities`. This generates a configuration to be added to the project: +In the terminal, use Wrangler to create a Workers KV namespace for `cities`. This generates a configuration to be added to the project: ```sh npx wrangler kv:namespace create cities @@ -60,9 +60,9 @@ kv_namespaces = [ # build command... ``` -With this configured, you can access the KV namespace with the binding `"cities"` from Rust. +With this configured, you can access the Workers KV namespace with the binding `"cities"` from Rust. -## 3. Write data to KV +## 3. Write data to Workers KV For this app, you will create two routes: A `POST` route to receive and store the city in KV, and a `GET` route to retrieve the city of a given country. For example, a `POST` request to `/France` with a body of `{"city": "Paris"}` should create an entry of Paris as a city in France. A `GET` request to `/France` should retrieve from KV and respond with Paris. @@ -194,4 +194,4 @@ npx wrangler deploy ## Related resources - [Rust support in Workers](/workers/languages/rust/). -- [Using KV in Workers](/kv/get-started/). +- [Using Workers KV in Workers](/kv/get-started/). diff --git a/src/content/docs/workers/wrangler/api.mdx b/src/content/docs/workers/wrangler/api.mdx index ed28c395bc614c..6bfe684afbb9df 100644 --- a/src/content/docs/workers/wrangler/api.mdx +++ b/src/content/docs/workers/wrangler/api.mdx @@ -328,7 +328,7 @@ The bindings supported by `getPlatformProxy` are: - [Service bindings](/workers/runtime-apis/bindings/service-bindings/) -- [KV namespace bindings](/kv/api/) +- [Workers KV namespace bindings](/kv/api/) - [Durable Object bindings](/durable-objects/api/) diff --git a/src/content/docs/workers/wrangler/commands.mdx b/src/content/docs/workers/wrangler/commands.mdx index c0e55b0ead6534..4922813acdb133 100644 --- a/src/content/docs/workers/wrangler/commands.mdx +++ b/src/content/docs/workers/wrangler/commands.mdx @@ -1781,7 +1781,7 @@ wrangler pages dev [] [OPTIONS] - `--binding` - Bind an environment variable or secret (for example, `--binding =`). - `--kv` optional - - Binding name of [KV namespace](/kv/) to bind (for example, `--kv `). + - Binding name of [Workers KV namespace](/kv/) to bind (for example, `--kv `). - `--r2` - Binding name of [R2 bucket](/pages/functions/bindings/#interact-with-your-r2-buckets-locally) to bind (for example, `--r2 `). - `--d1` diff --git a/src/content/docs/workers/wrangler/configuration.mdx b/src/content/docs/workers/wrangler/configuration.mdx index 9e5a14721a763d..05099eeb9ddd45 100644 --- a/src/content/docs/workers/wrangler/configuration.mdx +++ b/src/content/docs/workers/wrangler/configuration.mdx @@ -202,7 +202,7 @@ Non-inheritable keys are configurable at the top-level, but cannot be inherited - `kv_namespaces` - - A list of KV namespaces that your Worker should be bound to. Refer to [KV namespaces](#kv-namespaces). + - A list of Workers KV namespaces that your Worker should be bound to. Refer to [Workers KV namespaces](#kv-namespaces). - `r2_buckets` @@ -610,23 +610,23 @@ binding = "" id = "" ``` -### KV namespaces +### Workers KV namespaces [Workers KV](/kv/api/) is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflare’s data centers after access. -To bind KV namespaces to your Worker, assign an array of the below object to the `kv_namespaces` key. +To bind Workers KV namespaces to your Worker, assign an array of the below object to the `kv_namespaces` key. - `binding` - - The binding name used to refer to the KV namespace. + - The binding name used to refer to the Workers KV namespace. - `id` - - The ID of the KV namespace. + - The ID of the Workers KV namespace. - `preview_id` - - The preview ID of this KV namespace. This option is **required** when using `wrangler dev --remote` to develop against remote resources. If developing locally (without `--remote`), this is an optional field. `wrangler dev` will use this ID for the KV namespace. Otherwise, `wrangler dev` will use `id`. + - The preview ID of this Workers KV namespace. This option is **required** when using `wrangler dev --remote` to develop against remote resources. If developing locally (without `--remote`), this is an optional field. `wrangler dev` will use this ID for the Workers KV namespace. Otherwise, `wrangler dev` will use `id`. :::note diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx index 16eeb3d5a34247..f38546c06f7980 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx @@ -268,7 +268,7 @@ wrangler tail [--format $FORMAT] [--status $STATUS] [OPTIONS] After starting `wrangler tail` in a directory with a project, you will receive a live feed of console and exception logs for each request your Worker receives. -Like all Wrangler commands, run `wrangler tail` from your Worker’s root directory (the directory with your `wrangler.toml` file). +Like all Wrangler commands, run `wrangler tail` from your Worker's root directory (the directory with your `wrangler.toml` file). :::caution[Legacy issues with existing cloudflared configuration] @@ -305,7 +305,7 @@ Default values indicated by =value. ### kv_namespaces -If you are using [kv_namespaces](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration/#kv_namespaces) with `wrangler preview`, you will need to specify a `preview_id` in your `wrangler.toml` file before you can start the session. This is so that you do not accidentally write changes to your production namespace while you are developing. You may make `preview_id` equal to `id` if you would like to preview with your production namespace, but you should ensure that you are not writing values to KV that would break your production Worker. +If you are using [kv_namespaces](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration/#kv_namespaces) with `wrangler preview`, you will need to specify a `preview_id` in your `wrangler.toml` file before you can start the session. This is so that you do not accidentally write changes to your production namespace while you are developing. You may make `preview_id` equal to `id` if you would like to preview with your production namespace, but you should ensure that you are not writing values to Workers KV that would break your production Worker. To create a `preview_id` run: @@ -435,17 +435,17 @@ wrangler secret list --env ENVIRONMENT_NAME ## kv -The `kv` subcommand allows you to store application data in the Cloudflare network to be accessed from Workers using [Workers KV](https://www.cloudflare.com/products/workers-kv/). KV operations are scoped to your account, so in order to use any of these commands, you: +The `kv` subcommand allows you to store application data in the Cloudflare network to be accessed from Workers using [Workers KV](https://www.cloudflare.com/products/workers-kv/). Key-value operations are scoped to your account, so in order to use any of these commands, you: - must configure an `account_id` in your project's `wrangler.toml` file. - run all `wrangler kv:` operations in your terminal from the project's root directory. ### Getting started -To use Workers KV with your Worker, the first thing you must do is create a KV namespace. This is done with +To use Workers KV with your Worker, the first thing you must do is create a Workers KV namespace. This is done with the `kv:namespace` subcommand. -The `kv:namespace` subcommand takes a new binding name as its argument. A Workers KV namespace will be created using a concatenation of your Worker’s name (from your `wrangler.toml` file) and the binding name you provide: +The `kv:namespace` subcommand takes a new binding name as its argument. A Workers KV namespace will be created using a concatenation of your Worker's name (from your `wrangler.toml` file) and the binding name you provide: ```sh wrangler kv:namespace create "MY_KV" @@ -466,7 +466,7 @@ Successful operations will print a new configuration block that should be copied let value = await MY_KV.get("my-key"); ``` -To write a value to your KV namespace using Wrangler, run the `wrangler kv:key put` subcommand. +To write a value to your Workers KV namespace using Wrangler, run the `wrangler kv:key put` subcommand. ```sh wrangler kv:key put --binding=MY_KV "key" "value" @@ -476,7 +476,7 @@ wrangler kv:key put --binding=MY_KV "key" "value" ✨ Success ``` -Instead of `--binding`, you may use `--namespace-id` to specify which KV namespace should receive the operation: +Instead of `--binding`, you may use `--namespace-id` to specify which Workers KV namespace should receive the operation: ```sh wrangler kv:key put --namespace-id=e29b263ab50e42ce9b637fa8370175e8 "key" "value" @@ -486,8 +486,8 @@ wrangler kv:key put --namespace-id=e29b263ab50e42ce9b637fa8370175e8 "key" "value ✨ Success ``` -Additionally, KV namespaces can be used with environments. This is useful for when you have code that refers to -a KV binding like `MY_KV`, and you want to be able to have these bindings point to different namespaces (like +Additionally, Workers KV namespaces can be used with environments. This is useful for when you have code that refers to +a Workers KV binding like `MY_KV`, and you want to be able to have these bindings point to different namespaces (like one for staging and one for production). A `wrangler.toml` file with two environments: @@ -504,7 +504,7 @@ kv_namespaces = [ ] ``` -To insert a value into a specific KV namespace, you can use: +To insert a value into a specific Workers KV namespace, you can use: ```sh wrangler kv:key put --env=staging --binding=MY_MV "key" "value" @@ -534,7 +534,7 @@ Most `kv` commands require you to specify a namespace. A namespace can be specif wrangler kv:key get --namespace-id=06779da6940b431db6e566b4846d64db "my key" ``` -Most `kv` subcommands also allow you to specify an environment with the optional `--env` flag. This allows you to publish Workers running the same code but with different namespaces. For example, you could use separate staging and production namespaces for KV data in your `wrangler.toml` file: +Most `kv` subcommands also allow you to specify an environment with the optional `--env` flag. This allows you to publish Workers running the same code but with different namespaces. For example, you could use separate staging and production namespaces for Workers KV data in your `wrangler.toml` file: ```toml type = "webpack" @@ -554,7 +554,7 @@ kv_namespaces = [ ] ``` -With the `wrangler.toml` file above, you can specify `--env production` when you want to perform a KV action on the namespace `MY_KV` under `env.production`. For example, with the `wrangler.toml` file above, you can get a value out of a production KV instance with: +With the `wrangler.toml` file above, you can specify `--env production` when you want to perform a KV action on the namespace `MY_KV` under `env.production`. For example, with the `wrangler.toml` file above, you can get a value out of a production Workers KV instance with: ```sh wrangler kv:key get --binding "MY_KV" --env=production "my key" @@ -606,7 +606,7 @@ kv_namespaces = [ #### `list` -List all KV namespaces associated with an account ID. +List all Workers KV namespaces associated with an account ID. ```sh wrangler kv:namespace list @@ -704,7 +704,7 @@ wrangler kv:key put --binding= [--namespace-id=] $KEY $VALUE - `--preview` optional - - Interact with a preview namespace instead of production. Pass this to the `wrangler.toml` file’s `kv_namespaces.preview_id` instead of `kv_namespaces.id`. + - Interact with a preview namespace instead of production. Pass this to the `wrangler.toml` file's `kv_namespaces.preview_id` instead of `kv_namespaces.id`. - `--ttl` optional @@ -804,7 +804,7 @@ wrangler kv:key get --binding= [--env=] [--preview] [--namespace-id=] "$KEY" - If defined, the operation will only apply to the specified environment. Refer to [Environments](/workers/wrangler/environments/) for more information. - `--preview` optional - - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml` file’s `kv_namespaces.preview_id` instead of `kv_namespaces.id` + - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml` file's `kv_namespaces.preview_id` instead of `kv_namespaces.id` ##### Usage @@ -838,7 +838,7 @@ wrangler kv:key delete --binding= [--env=] [--preview] [--namespace-id=] "$KEY" - Perform on a specific environment specified as `$ENVIRONMENT_NAME`. - `--preview` optional - - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml`’s `kv_namespaces.preview_id` instead of `kv_namespaces.id` + - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml`'s `kv_namespaces.preview_id` instead of `kv_namespaces.id` ##### Usage @@ -877,7 +877,7 @@ wrangler kv:bulk put --binding= [--env=] [--preview] [--namespace-id=] $FILENAME - If defined, the changes will only apply to the specified environment. Refer to [Environments](/workers/wrangler/environments/) for more information. - `--preview` optional - - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml` file’s `kv_namespaces.preview_id` instead of `kv_namespaces.id` + - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml` file's `kv_namespaces.preview_id` instead of `kv_namespaces.id` This command takes a JSON file as an argument with a list of key-value pairs to upload. An example of JSON input: @@ -907,7 +907,7 @@ The schema below is the full schema for key-value entries uploaded via the bulk - `key` - - The key’s name. The name may be 512 bytes maximum. All printable, non-whitespace characters are valid. + - The key's name. The name may be 512 bytes maximum. All printable, non-whitespace characters are valid. - `value` @@ -959,7 +959,7 @@ wrangler kv:bulk delete --binding= [--env=] [--preview] [--namespace-id=] $FILEN - If defined, the changes will only apply to the specified environment. Refer to [Environments](/workers/wrangler/environments/) for more information. - `--preview` optional - - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml` file’s `kv_namespaces.preview_id` instead of `kv_namespaces.id` + - Interact with a preview namespace instead of production. Pass this to use your `wrangler.toml` file's `kv_namespaces.preview_id` instead of `kv_namespaces.id` This command takes a JSON file as an argument with a list of key-value pairs to delete. An example of JSON input: @@ -974,7 +974,7 @@ This command takes a JSON file as an argument with a list of key-value pairs to - `key` - - The key’s name. The name may be at most 512 bytes. All printable, non-whitespace characters are valid. + - The key's name. The name may be at most 512 bytes. All printable, non-whitespace characters are valid. - `value` diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx index f00cc40a917723..075b75debe9746 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx @@ -212,7 +212,7 @@ Secrets should be handled using the [`wrangler secret`](/workers/wrangler/comman ### kv\_namespaces -`kv_namespaces` defines a list of KV namespace bindings for your Worker. +`kv_namespaces` defines a list of Workers KV namespace bindings for your Worker. Usage: @@ -252,22 +252,22 @@ let value = await FOO.get("keyname"); * `binding` required - * The name of the global variable your code will reference. It will be provided as a [KV runtime instance](/kv/api/). + * The name of the global variable your code will reference. It will be provided as a [Workers KV runtime instance](/kv/api/). * `id` required - * The ID of the KV namespace that your `binding` should represent. Required for `wrangler publish`. + * The ID of the Workers KV namespace that your `binding` should represent. Required for `wrangler publish`. * `preview_id` required - * The ID of the KV namespace that your `binding` should represent during `wrangler dev` or `wrangler preview`. Required for `wrangler dev` and `wrangler preview`. + * The ID of the Workers KV namespace that your `binding` should represent during `wrangler dev` or `wrangler preview`. Required for `wrangler dev` and `wrangler preview`. :::note -Creating your KV namespaces can be handled using Wrangler’s [KV Commands](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands/#kv). +Creating your Workers KV namespaces can be handled using Wrangler's [Workers KV Commands](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands/#kv). You can also define your `kv_namespaces` using an [alternative TOML syntax](https://github.com/toml-lang/toml/blob/master/toml.md#user-content-table). @@ -477,7 +477,7 @@ Workers now supports the ES Modules syntax. This format allows you to export a c Module Workers `export` their event handlers instead of using `addEventListener` calls. -Modules receive all bindings (KV Namespaces, Environment Variables, and Secrets) as arguments to the exported handlers. With the Service Worker format, these bindings are available as global variables. +Modules receive all bindings (Workers KV Namespaces, Environment Variables, and Secrets) as arguments to the exported handlers. With the Service Worker format, these bindings are available as global variables. :::note diff --git a/src/content/docs/workflows/build/events-and-parameters.mdx b/src/content/docs/workflows/build/events-and-parameters.mdx index 50c04d21b15380..61bde264bcba9f 100644 --- a/src/content/docs/workflows/build/events-and-parameters.mdx +++ b/src/content/docs/workflows/build/events-and-parameters.mdx @@ -6,7 +6,7 @@ sidebar: --- -When a Workflow is triggered, it can receive an optional event. This event can include data that your Workflow can act on, including request details, user data fetched from your database (such as D1 or KV) or from a webhook, or messages from a Queue consumer. +When a Workflow is triggered, it can receive an optional event. This event can include data that your Workflow can act on, including request details, user data fetched from your database (such as D1 or Workers KV) or from a webhook, or messages from a Queue consumer. Events are a powerful part of a Workflow, as you often want a Workflow to act on data. Because a given Workflow instance executes durably, events are a useful way to provide a Workflow with data that should be immutable (not changing) and/or represents data the Workflow needs to operate on at that point in time. diff --git a/src/content/glossary/kv.yaml b/src/content/glossary/kv.yaml index ce9b6418aee1d6..c1003d2a279eff 100644 --- a/src/content/glossary/kv.yaml +++ b/src/content/glossary/kv.yaml @@ -1,9 +1,9 @@ --- -productName: KV +productName: Workers KV entries: - - term: KV namespace + - term: Workers KV namespace general_definition: |- - a KV namespace is a key-value database replicated to Cloudflare’s global network. A KV namespace must require a binding and an id. + a Workers KV namespace is a key-value database replicated to Cloudflare’s global network. A Workers KV namespace must require a binding and an id. - term: cacheTtl general_definition: |- diff --git a/src/content/glossary/workers.yaml b/src/content/glossary/workers.yaml index 422d9053830187..c86264e2c3316e 100644 --- a/src/content/glossary/workers.yaml +++ b/src/content/glossary/workers.yaml @@ -57,11 +57,11 @@ entries: general_definition: |- [Isolates](/workers/reference/how-workers-works/#isolates) are lightweight contexts that provide your code with variables it can access and a safe environment to be executed within. - - term: KV + - term: Workers KV general_definition: |- [Workers KV](/kv/) is Cloudflare's key-value data storage. associated_products: - - KV + - Workers KV - term: module Worker general_definition: |- @@ -103,7 +103,7 @@ entries: - term: subrequest general_definition: |- - A subrequest is any request that a Worker makes to either Internet resources using the [Fetch API](/workers/runtime-apis/fetch/) or requests to other Cloudflare services like [R2](/r2/), [KV](/kv/), or [D1](/d1/). + A subrequest is any request that a Worker makes to either Internet resources using the [Fetch API](/workers/runtime-apis/fetch/) or requests to other Cloudflare services like [R2](/r2/), [Workers KV](/kv/), or [D1](/d1/). - term: Tail Worker general_definition: |- diff --git a/src/content/partials/workers/wrangler-commands/kv.mdx b/src/content/partials/workers/wrangler-commands/kv.mdx index 57c116f170f4ad..64d5820715ab3a 100644 --- a/src/content/partials/workers/wrangler-commands/kv.mdx +++ b/src/content/partials/workers/wrangler-commands/kv.mdx @@ -15,7 +15,7 @@ The `kv ...` commands allow you to manage your Workers KV resources in the Cloud :::caution -Since version 3.60.0, Wrangler supports the `kv ...` syntax. If you are using versions below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/#deprecations) for KV page. +Since version 3.60.0, Wrangler supports the `kv ...` syntax. If you are using versions below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/#deprecations) for Workers KV page. ::: @@ -35,7 +35,7 @@ wrangler kv namespace create [OPTIONS] -The following is an example of using the `create` command to create a KV namespace called `MY_KV`. +The following is an example of using the `create` command to create a Workers KV namespace called `MY_KV`. ```sh npx wrangler kv namespace create "MY_KV" @@ -50,7 +50,7 @@ kv_namespaces = [ ] ``` -The following is an example of using the `create` command to create a preview KV namespace called `MY_KV`. +The following is an example of using the `create` command to create a preview Workers KV namespace called `MY_KV`. ```sh npx wrangler kv namespace create "MY_KV" --preview @@ -67,7 +67,7 @@ kv_namespaces = [ -List all KV namespaces associated with the current account ID. +List all Workers KV namespaces associated with the current account ID. ```txt wrangler kv namespace list @@ -118,7 +118,7 @@ This command requires `--binding` or `--namespace-id`. -The following is an example of deleting a KV namespace called `MY_KV.` +The following is an example of deleting a Workers KV namespace called `MY_KV.` ```sh npx wrangler kv namespace delete --binding=MY_KV @@ -131,7 +131,7 @@ Deleting namespace f7b02e7fc70443149ac906dd81ec1791 Deleted namespace f7b02e7fc70443149ac906dd81ec1791 ``` -The following is an example of deleting a preview KV namespace called `MY_KV`. +The following is an example of deleting a preview Workers KV namespace called `MY_KV`. ```sh npx wrangler kv namespace delete --binding=MY_KV --preview @@ -155,7 +155,7 @@ The `kv ...` commands allow you to manage your Workers KV resources in the Cloud :::caution -Since version 3.60.0, Wrangler supports the `kv ...` syntax. If you are using versions below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/) for KV page. +Since version 3.60.0, Wrangler supports the `kv ...` syntax. If you are using versions below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/) for Workers KV page. ::: @@ -319,7 +319,7 @@ Exactly one of `--binding` or `--namespace-id` is required. -The following is an example that gets the value of the `"my-key"` key from the KV namespace with binding name `MY_KV`. +The following is an example that gets the value of the `"my-key"` key from the Workers KV namespace with binding name `MY_KV`. ```sh npx wrangler kv key get --binding=MY_KV "my-key" @@ -359,7 +359,7 @@ Exactly one of `--binding` or `--namespace-id` is required. -The following is an example that deletes the key-value pair with key `"my-key"` from the KV namespace with binding name `MY_KV`. +The following is an example that deletes the key-value pair with key `"my-key"` from the Workers KV namespace with binding name `MY_KV`. ```sh npx wrangler kv key delete --binding=MY_KV "my-key" @@ -380,7 +380,7 @@ The `kv ...` commands allow you to manage your Workers KV resources in the Cloud :::caution -Since version 3.60.0, Wrangler supports the `kv ...` syntax. If you are using versions below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/) for KV page. +Since version 3.60.0, Wrangler supports the `kv ...` syntax. If you are using versions below 3.60.0, the command follows the `kv:...` syntax. Learn more about the deprecation of the `kv:...` syntax in the [Wrangler commands](/kv/reference/kv-commands/) for Workers KV page. ::: @@ -425,7 +425,7 @@ This command takes a JSON file as an argument with a list of key-value pairs to ] ``` -KV namespace values can only store strings. In order to save complex a value, stringify it to JSON: +Workers KV namespace values can only store strings. In order to save complex a value, stringify it to JSON: ```json [ diff --git a/src/content/products/kv.yaml b/src/content/products/kv.yaml index 76496fa2c633c2..3e9f434b59dcf9 100644 --- a/src/content/products/kv.yaml +++ b/src/content/products/kv.yaml @@ -1,7 +1,7 @@ name: KV product: - title: KV + title: Workers KV url: /kv/ group: Developer platform additional_groups: [Storage] diff --git a/src/content/videos/index.yaml b/src/content/videos/index.yaml index 903a5ae0a2c60b..7d6e96aede5d06 100644 --- a/src/content/videos/index.yaml +++ b/src/content/videos/index.yaml @@ -16,7 +16,7 @@ entries: title: Build a URL Shortener with an AI-based admin section description: We are building a URL Shortener, shrty.dev, on Cloudflare. The apps uses Workers KV and Workers Analytics engine. Craig decided to build with Workers AI runWithTools to provide a chat interface for admins. tags: [Workers Analytics Engine, AI] - products: [Workers AI, KV] + products: [Workers AI, Workers KV] languages: [TypeScript] cloudflare: true author: craig @@ -29,7 +29,7 @@ entries: description: In this video, we will show you how to build a global database using workers-rs to keep track of every country and city you’ve visited. tags: [] languages: [Rust] - products: [Workers, KV] + products: [Workers, Workers KV] cloudflare: true author: confidence updated: 2024-06-25 @@ -65,7 +65,7 @@ entries: description: Learn how to access external APIs, cache and retrieve data using Workers KV, and create SQL-driven applications with Cloudflare D1. tags: [] languages: [TypeScript, SQL] - products: [Workers, KV, D1] + products: [Workers, Workers KV, D1] cloudflare: true author: kristian updated: 2024-05-22 @@ -249,10 +249,10 @@ entries: - link: https://youtu.be/slS4RBV0SBk title: Cloudflare Workflows | Introduction (Part 1 of 3) description: In this video, we introduce Cloudflare Workflows, the Newest Developer Platform Primitive at Cloudflare. - tags: [Workflows, Workers, Queues, Workers AI, AI Gateway, KV] + tags: [Workflows, Workers, Queues, Workers AI, AI Gateway, Workers KV] languages: [TypeScript] # stream_id: - products: [Workflows, Workers, Queues, Workers AI, AI Gateway, KV] + products: [Workflows, Workers, Queues, Workers AI, AI Gateway, Workers KV] cloudflare: true author: craig updated: 2024-10-30 @@ -262,10 +262,10 @@ entries: - link: https://youtu.be/y4PPsvHrQGA title: Cloudflare Workflows | Batching and Monitoring Your Durable Execution (Part 2 of 3) description: Workflows exposes metrics such as execution, error rates, steps, and total duration! - tags: [Workflows, Workers, Queues, Workers AI, AI Gateway, KV] + tags: [Workflows, Workers, Queues, Workers AI, AI Gateway, Workers KV] languages: [TypeScript] # stream_id: - products: [Workflows, Workers, Queues, Workers AI, AI Gateway, KV] + products: [Workflows, Workers, Queues, Workers AI, AI Gateway, Workers KV] cloudflare: true author: craig updated: 2024-10-30 @@ -275,10 +275,10 @@ entries: - link: https://youtu.be/L6gR4Yr3UW8 title: Cloudflare Workflows | Schedule and Sleep For Your Apps (Part 3 of 3) description: Cloudflare Workflows allows you to initiate sleep as an explicit step, which can be useful when you want a Workflow to wait, schedule work ahead, or pause until an input or other external state is ready. - tags: [Workflows, Workers, Queues, Workers AI, AI Gateway, KV] + tags: [Workflows, Workers, Queues, Workers AI, AI Gateway, Workers KV] languages: [TypeScript] # stream_id: - products: [Workflows, Workers, Queues, Workers AI, AI Gateway, KV] + products: [Workflows, Workers, Queues, Workers AI, AI Gateway, Workers KV] cloudflare: true author: craig updated: 2024-10-30 @@ -370,7 +370,7 @@ entries: updated: 2024-11-19 difficulty: Beginner content_type: 🎥 Video - pcx_content_type: tutorial + pcx_content_type: tutorial # - link: # title: # description: