Baseflare has six server function constructors. The public trio —Documentation Index
Fetch the complete documentation index at: https://mintlify.com/nickruigrok/baseflare/llms.txt
Use this file to discover all available pages before exploring further.
query, mutation, and action — defines functions callable from client SDKs via the RPC routes. The internal trio — internalQuery, internalMutation, and internalAction — defines server-only functions that are never exposed over HTTP but can be composed together using ctx.runQuery, ctx.runMutation, and ctx.runAction. All six share the same FunctionDefinitionConfig shape and are exported from baseflare/server.
FunctionDefinitionConfig<TArgs, TReturns, TCtx>
Every function constructor accepts a single config object:
A plain object mapping argument names to validators from
v.*. The inferred
object type becomes the args parameter of handler. All arguments are
validated at the RPC boundary before the handler is called.Optional validator for the handler’s return value. When provided, the return
value is validated at runtime before being sent back to the caller. If omitted,
the return value is passed through as-is.
The async function that implements the operation. Receives a typed context object
and the validated
args. May be synchronous or async.query(config)
Defines a public, read-only server function. Queries have access to ctx.db as a DatabaseReader but cannot write. They are invoked by the client via POST /api/query/:name.
mutation(config)
Defines a public, read-write server function. Mutations run inside a serializable transaction and have access to ctx.db as a DatabaseWriter. They are invoked by the client via POST /api/mutation/:name.
action(config)
Defines a public server function that can run arbitrary async logic, call third-party APIs, and orchestrate other functions. Actions do not have direct database access — all DB work must go through ctx.runQuery() or ctx.runMutation(). They are invoked by the client via POST /api/action/:name.
internalQuery, internalMutation, internalAction
The internal variants have identical signatures to their public counterparts but are registered with visibility: "internal". They are never reachable via the /api/query/, /api/mutation/, or /api/action/ RPC routes — they can only be called server-side using ctx.runQuery, ctx.runMutation, or ctx.runAction.
Use internal functions to decompose complex logic, share database access patterns, or expose helper functions that should not be callable by clients.
Context Types
QueryCtx
Available inside query and internalQuery handlers.
Read-only database access. See DatabaseReader below.
Authentication context. Call
ctx.auth.getUserIdentity() to retrieve the
caller’s identity from the incoming request.Read-only file storage. Call
ctx.storage.getUrl(id) to retrieve a presigned
download URL for a stored object.MutationCtx
Available inside mutation and internalMutation handlers. Extends QueryCtx.
Read and write database access. See DatabaseWriter below.
Authentication context.
Run a query within the mutation context. Useful for reading data as part of
a read-modify-write pattern.
Schedule a function to run in the future. Call
ctx.scheduler.runAfter(delayMs, ref, args)
or ctx.scheduler.runAt(timestamp, ref, args). Returns a job ID string. (Planned)Read and write file storage. Extends
StorageReader with generateUploadUrl()
and delete(id). (Planned)ActionCtx
Available inside action and internalAction handlers. Does not include ctx.db.
Run a query (read-only database access) from within an action.
Run a mutation from within an action. Each
runMutation call is its own
serializable transaction.Run another action from within an action.
Authentication context.
Schedule a function to run in the future. (Planned)
Read, write, and directly store blobs. Extends
StorageWriter with
store(blob: Blob). (Planned)DatabaseReader
Returned by ctx.db in a QueryCtx. Provides read-only access to the D1 database.
Fetch a single document by its
_id. Returns null if no document exists
with that ID. Permission rules are applied — a document that fails the read
rule is treated as if it does not exist.Begin a fluent query against the given table. Chain
.filter(), .order(),
.limit(), then terminate with .collect(), .first(), .paginate(), etc.
See the QueryBuilder reference.DatabaseWriter
Returned by ctx.db in a MutationCtx. Extends DatabaseReader with write operations.
Insert a new document. The
doc object must conform to the table’s field
validators. Returns the new document’s _id string.Shallow-merge
partial into the existing document. Fields set to undefined
in the patch are deleted from the document (only allowed if the field is
optional in the schema). Fields not mentioned in partial are unchanged.Fully replace the document. The replacement
doc must pass complete schema
validation — all required fields must be present.Delete the document with the given
_id. The delete permission rule is
evaluated before deletion.FunctionReference
A lightweight branded type used to pass a function definition as a reference to ctx.runQuery, ctx.runMutation, or ctx.runAction. Function definitions created by query(), mutation(), action(), and their internal variants all satisfy this interface automatically.
Document Utilities
The following utilities are exported frombaseflare/server for use in custom tooling, testing, or lower-level integrations.
serialize(doc)
Converts a plain document object into the { _data: string } storage form written to the D1 _data column. Reserved fields (_id, _createdAt) are stripped. Uint8Array values are base64-encoded under a $bytes marker; keys starting with $ are escaped.
deserialize(row)
Reconstructs a full document object from the raw { _id, _data } row returned by D1. Decodes base64 byte arrays, un-escapes $-prefixed keys, and synthesizes _createdAt from the ID.
validateInsertData(table, data)
Validates data against a TableDefinition for an insert operation. Throws a ValidationError if any required field is missing, a field value fails its validator, or a reserved field is present.
validatePatchData(table, current, patch)
Validates a partial patch against the stored document. Only the keys present in patch are re-validated against their individual field validators. Fields absent from patch are preserved unchanged from current. Setting a field to undefined deletes it (only permitted for optional fields).
validateReplaceData(table, data)
Validates data for a full-document replacement. Identical to validateInsertData — all required fields must be present and pass their validators.