Alchemy Async

The Cloudflare Livestore implementation is split into two main runtimes: the Livestore Runtime (handling data synchronization and persistence) and the SvelteKit Runtime (handling the UI).

Livestore Runtime Components

• worker.ts: The client-side worker responsible for syncing data to and from the server.
• server.ts: The server-side Cloudflare worker that manages data synchronization and WebSocket connections.
• events.ts: Definitions for the events used within the livestore.
• tables.ts: SQLite table definitions.
• queries.ts: SQLite query definitions.
• materializers.ts: Event-sourced materializers for the livestore.

SvelteKit Runtime Components

• src/app/routes/index.svelte: The main entry point for the SvelteKit application UI.

Alchemy provides programmatic access to the following Prisma Postgres resources:

• Database: Create and manage Prisma Postgres databases with specific configuration options.
• Connection: Create and manage Prisma Postgres database connections.
• Project: Create and manage Prisma Postgres projects.
• WorkspaceRef: Reference Prisma Postgres workspaces using either their name or ID.

Alchemy provides several advantages for modern TypeScript development:

• JS-native: No secondary languages or complex toolchains required.
• Async-native: Resources are standard async functions.
• ESM-native: Built exclusively on ESM, optimized for runtimes like Bun.
• Embeddable: Can run in any JS/TS environment, including the browser.
• Extensible: You can implement custom resources by writing simple functions.
• AI-first: Designed to be easily manipulated by LLMs to create or modify resources.
• No service: State files are stored locally in your project for easy inspection and version control.
• No strong opinions: Flexible codebase structure and state storage.

Alchemy is an embeddable, TypeScript-native Infrastructure-as-Code (IaC) library. It allows you to model Resources that are automatically Created, Updated, and Deleted.

Unlike traditional IaC tools (Terraform, Pulumi, CloudFormation), Alchemy is implemented in pure ESM-native TypeScript. Resources are defined as simple memoized async functions that can run in any JavaScript runtime, including browsers, serverless functions, and durable workflows.

An AiSearchNamespace is a resource used to create and manage Cloudflare AI Search namespaces. Namespaces provide logical isolation and scoped access control by grouping AI Search instances together. Instance names are unique within their specific namespace.

When used as a Worker binding, it provides dynamic access to all instances within that namespace, allowing your Worker to perform runtime operations like creating, deleting, searching, and chatting with instances without requiring a redeployment.

import { AiSearchNamespace } from "alchemy/cloudflare";

const ns = await AiSearchNamespace("production", {
  name: "production",
});

An APIGatewayOperation resource in Cloudflare's API Gateway manages individual API endpoints. An operation is defined by a specific combination of an HTTP method, an endpoint path, and a host. These operations allow you to monitor, secure, and configure specific API traffic through API Shield.

:::caution For most use cases, you should use APIShield instead of APIGatewayOperation. APIShield automatically manages both APISchema and APIGatewayOperation resources for you. :::

Alchemy uses a transparent, pluggable state management system to track resource lifecycles and enable idempotent operations. State consists of resource data that tracks the current status, properties, and outputs of each resource.

By default, state is stored in JSON files within a .alchemy directory in your project root, organized by app and stage:

.alchemy/
  my-app/
    dev/
      my-resource.json
      my-other-resource.json

Alchemy uses this state to determine actions:

• No state file: The resource is created.
• State exists + props unchanged: The resource is skipped.
• State exists + props changed: The resource is updated.
• Resource removed from code: The resource is deleted.

When working with RouteTableAssociation, keep the following networking rules in mind:

• Single Association Limit: Each subnet can only be associated with one route table at a time. If you change an association, the subnet is automatically disassociated from its previous route table.
• Default Behavior: If you do not explicitly associate a subnet with a route table, it will automatically be associated with the VPC's main route table.
• Connectivity Risk: Route table associations are critical for network connectivity. Incorrect configurations can lead to loss of access to resources within a subnet.