Workers

2 posts

cloudflare2 min readCurated summary

Deploy Postgres and MySQL databases with PlanetScale + Workers

Cloudflare and PlanetScale are integrating more closely so developers can create and manage PlanetScale Postgres and MySQL databases from the Cloudflare dashboard and API. The integration connects these databases to Workers through Hyperdrive, providing connection pooling, query caching, and simplified configuration. Cloudflare billing for new PlanetScale databases is planned for next month, while existing setups remain billed through PlanetScale. ## Postgres and MySQL for Workers - Developers can use either PlanetScale Postgres or Vitess-based MySQL for Worker applications. - Postgres supports a broad ecosystem of tools and extensions such as `pgvector` for AI-oriented vector search. - After connecting a PlanetScale account, users can create databases from the Cloudflare dashboard. - A Hyperdrive binding in `wrangler.jsonc` connects a Worker to the database: ```json { "hyperdrive": [ { "binding": "DATABASE", "id": "<AUTO_CREATED_ID>" } ] } ``` - Workers can then use standard clients such as the Node.js `pg` package and access the connection string through `env.DATABASE`. ## PlanetScale’s Developer Experience - Cloudflare selected PlanetScale for its performance, reliability, and support for both Postgres and MySQL. - PlanetScale features include: - Query insights - Usage and cost breakdowns - Database branching for safer schema and code changes - Agent-assisted SQL performance improvements - Cloudflare users receive the standard PlanetScale experience and pricing, including all available features. - PlanetScale Postgres starts at $5 per month for a single node. ## Reducing Latency with Workers Placement - Workers normally execute close to the incoming user request, which can increase latency when accessing a centralized database. - Developers can configure explicit placement so the Worker runs near the database’s primary region: ```json { "placement": { "region": "aws:us-east-1" } } ``` - Cloudflare plans to automatically determine placement based on the PlanetScale database location, potentially reducing database access latency to single-digit milliseconds. ## Billing and Availability - PlanetScale databases can already be created or connected through the Cloudflare dashboard. - Until the billing integration launches, databases continue to be billed through PlanetScale. - Starting next month, new databases can be billed directly to a Cloudflare self-serve or enterprise account. - Cloudflare credits, startup-program benefits, and committed spend may also apply toward PlanetScale database costs. The integration is intended to give Workers developers a unified platform for globally deployed applications, with flexible SQL storage, optimized database connectivity, and eventually centralized Cloudflare billing.

Read original(opens in new tab)
cloudflare2 min readCurated summary

How we use Abstract Syntax Trees (ASTs) to turn Workflows code into visual diagrams

Cloudflare uses Abstract Syntax Trees (ASTs) to turn code-based Workflows into visual diagrams. Because Workflows execute dynamically—supporting parallel promises, awaits, loops, and conditionals—the system analyzes code structure and relationships to infer execution order. The resulting diagrams help developers understand workflow shape, especially as coding agents generate more application code. ## Why Code-Based Workflows Are Difficult to Visualize - Unlike declarative workflow builders, Cloudflare Workflows are ordinary code. - Workflows may contain: - `Promise` and `await` relationships - `Promise.all` for parallel execution - Loops and conditionals - Steps nested inside functions or classes - The runtime discovers and executes steps as it encounters them, rather than following a predefined sequence. - Unawaited steps can execute in parallel, while `await` establishes blocking dependencies. ## How Workflow Execution Works - A supervisor Durable Object, called the engine, starts for each workflow instance. - The engine dispatches execution to the user Worker. - When the Worker encounters `step.do`, control returns to the engine. - The engine executes the step, persists its result or error, and invokes the Worker again. - Since the engine does not inherently retain the complete intended order of steps, diagram generation must reconstruct those relationships from the source code. ## Parsing and Building the Workflow Graph - Cloudflare fetches the bundled Worker script at deployment time. - A parser converts the script into an Abstract Syntax Tree. - An internal service: - Identifies `WorkflowEntrypoints` - Finds calls to workflow steps - Builds and traverses an intermediate graph - Produces the final diagram through Cloudflare’s API - AST analysis tracks promises and `await` expressions to determine: - Which steps depend on one another - Which steps block execution - Which steps can run concurrently ## Handling Bundled and Minified JavaScript - Workers are generally bundled with tools such as esbuild and may be minified. - Minified output can obscure the original TypeScript structure and vary between bundlers. - The diagram system therefore has to recognize workflow patterns in dense, transformed JavaScript. - For example, several agent steps—such as summary, correctness, and clarity agents—may be created without awaiting them, indicating parallel execution. - The generated graph makes that concurrency visible even when the deployed code is difficult to read. Cloudflare’s AST-based approach provides a practical way to visualize dynamic, code-defined workflows. Developers can inspect how steps connect, branch, and execute in parallel directly from the dashboard, though the beta diagrams will continue to improve as more workflow patterns are supported.

Read original(opens in new tab)