Serverless functions that put the database in frontend code
Xata has built its serverless functions product, Xata Workers, on Cloudflare's Workers for Platforms. The functions act as middleware that sits between client-side application code and a Xata database, letting frontend developers write database access logic in what looks like regular client-side JavaScript or TypeScript. Behind the scenes, that code runs on Cloudflare's global network rather than in the browser, keeping credentials out of reach of client-side inspection.
The problem with client-side database access
Modern web architectures have largely moved away from dedicated servers toward functions deployed across many locations. Developers no longer manage servers, and users benefit from lower latency. Databases, however, remain comparatively complex to operate, with replication, failover and high availability requiring significant infrastructure know-how.
Xata's goal is to remove that operational burden. But making a database approachable to frontend engineers exposes a key challenge: how to let client-side code query a database without leaking credentials. Hardcoding database credentials into browser code is a common cause of data leaks, since anyone inspecting the code can extract them and, if they are not scoped to a single operation, modify unrelated parts of the database or read data they shouldn't.
Xata considered row-level access rules but decided they would require an opinionated, proprietary language that users would eventually outgrow and find hard to migrate away from. Instead, the team opted to make serverless functions simpler. Typically, using serverless functions means choosing a full-stack framework or manually handling compilation, deployment and invocation. Xata Workers try to remove that friction.
How a Xata Worker works
A Xata Worker is a function written in JavaScript or TypeScript. To the developer it looks like client-side code, but it executes server-side on Cloudflare's infrastructure. Conceptually it resembles getServerSideProps in Next.js or a loader in Remix. The distinction is that Xata Workers are not tied to any particular framework or hosting provider. They can be used with a static site uploaded to GitHub Pages or S3; no full-stack framework is required.
The Xata command-line tool handles building and deploying each worker. When a worker is invoked, it makes a network request to the serverless function.
import { useQuery } from '@tanstack/react-query';
import { xataWorker } from '~/xata';
const listProducts = xataWorker('listProducts', async ({ xata }) => {
return await xata.db.products.sort('popularity', 'desc').getMany();
});
export const Home = () => {
const { data = [] } = useQuery(['products'], listProducts);
return (
<Grid>
{data.map((product) => (
<ProductCard key={product.id} product={product} />
))}
</Grid>
);
};The example above shows a React component querying an e-commerce database for products on sale. The component uses a popular client-side data-fetching library to retrieve data from the worker and render a product grid. Inside the worker, the developer writes normal function code that receives a Xata SDK instance with access to the database. Since the code never runs in the browser, secrets stay protected.
Workers can receive additional parameters carrying application state, context or user tokens. They can either return an object serialized over the network using a JSON superset that supports dates and other non-primitive types, or return a full response with custom status codes and headers. Authentication and authorization logic are expressed in plain code, which also makes the functions straightforward to unit test alongside the rest of an application.
When a Xata Worker is written in TypeScript, the CLI generates schema-based types, providing type safety on queries and mutations and powering IDE intellisense.
What Cloudflare brings underneath
Xata builds on Cloudflare Workers for Platforms, using isolated execution contexts to run customer code without exposing Xata to the security risks of executing untrusted code in its own infrastructure. The deployment process is handled transparently: for each Xata workspace, Xata creates a Worker Namespace, which groups and routes the various functions that a client or team deploys. When a developer publishes a Xata Worker, Xata uploads a compiled Worker Script to that namespace, assigning it a unique name that includes a compilation identifier so multiple versions of a function can coexist.
During compilation, the Xata CLI injects the database connection details and database name into the worker. This scopes the function's access to the database without exposing secrets, all automatically.
Client-side applications talk to a Dispatcher function when invoking a Xata Worker. The dispatcher routes the request to the correct Worker Script and also handles CORS header configuration and log drain setup for debugging.
The Workers ecosystem gives Xata additional capabilities. Developers can cache query results on Cloudflare's edge by adding a cache parameter to a query, specifying a time-to-live in milliseconds. Read-only queries can then be served from locations near the end user without repeatedly hitting the database. Workers also run locally via an integration with the latest version of miniflare, which emulates the Cloudflare Workers runtime, offering filesystem watchers and hot reloading during development to mirror the production environment.
Availability
Xata is out of beta and generally available with a free tier. Features include branching with zero-downtime migrations, search, analytics and transactions. Xata Workers remain in private beta; interested developers can join a waitlist to provide feedback on the feature.
