Skip to main content
A publication is a complete set of related tables that Bijection computes from your own tables and makes visible in a single commit. You write the computation as ordinary TypeScript. Bijection captures its inputs at one consistent point, runs it, checks the output, and switches every output table to the new result at once. Use a publication when several derived tables must agree with each other: a list of open orders and the per-customer totals computed from it, for example. A reader never sees the new list next to the old totals. Your queries read published tables like any other table:
bijection/orders.ts

How it fits together

A publication has three parts:
  • Published tables, declared in your schema with definePublished. Their rows are written only by publication; no mutation can insert, patch, replace or delete them.
  • A pipeline, declared with defineEtl from the @bijection/pipelines component, which you install from npm and add to your app with app.use. It names the input tables, the output tables and the transform function that turns one into the other.
  • A publisher, declared with definePublisher. It names the internal queries Bijection reads to find a ready result and verify it. defineEtl generates these queries and the declaration for you.
When an input table changes, the pipeline runs again:
1

Capture

Bijection reads every input at one retained snapshot. A large input is read in pages, and every page comes from that same snapshot.
2

Transform

Your transform runs in a bounded action with no network access. Its result is sealed together with the exact input it received.
3

Check

The pipeline checks every output row against its table’s validator, refuses duplicate keys, and evaluates any expectations you declared over the complete result.
4

Publish

Bijection recomputes the output digests from the rows it is about to write, and switches every output table to the new result in one commit.

What publication guarantees

All output tables of a pipeline switch together. A query reads every one of them from the same publication.
A failed run publishes nothing. The previous publication stays readable until a complete, checked replacement is ready.
The published rows are the rows your transform produced from the captured input. Bijection verifies this itself; it does not trust the pipeline’s own records.
Withdrawing a publication, or revoking the authority it was published under, makes its tables unreadable immediately.
Publication is asynchronous. Right after an input changes, published tables still hold the previous result. They describe the inputs they were computed from, not necessarily the latest state of those inputs. Reading publications shows how to observe which result is serving, and how a query or mutation can require the result it depends on.
Publications are bounded. A run reads at most 64 input rows, or 8,192 rows when one input is streamed in pages, and produces at most 65,536 output rows. See limits for the complete list.

Next steps

Published tables

Declare tables whose rows only publication can write

Pipelines

Capture inputs, transform them and publish the result

Reading publications

Query published tables and require a specific result