Managing Manifests

This guide covers how to create and manage ReJot manifest files using the rejot-cli manifest commands. ReJot uses Manifests as a central configuration file that defines your data synchronization setup. Think of it as a “lockfile” for your data contracts - it specifies what data should be synced, where it should be synced, and in what format.

Manifest Components

A manifest definition contains (a subset of) the following components:

• Data stores: Source databases that ReJot monitors for changes
• Event stores: Where ReJot stores and manages change events
• Public Schemas: Define what data is exposed from your data stores
• Consumer Schemas: Define how data is transformed and stored in target systems
• Workspaces: Group multiple manifests into a single project.

Initializing a Manifest

To create a new empty manifest file in the current directory, use the following command. Each manifest requires a unique slug, which is used to identify where public schemas are exposed and where sync services can locate them on the network.

        rejot-cli manifest init --slug "my-sync-slug"
      

Setting Up Data and Event Stores

Before configuring public and consumer schemas, you need to specify how ReJot should connect to your databases and where the ReJot Event Store is located.

For each data store, ReJot will monitor changes to public schemas defined for that data store and push those changes to the event store. While you can configure the event store to use the same database, it’s generally recommended to use a separate database.

Adding Database Connections

Let’s start by adding the connection details:

        rejot-cli manifest connection add \
            --slug "my-datastore" \
            --type postgres \
            --database postgres \
            --host localhost \
            --password example \
            --port 5432 \
            --user postgres
      

Alternatively, you can provide a connection string:

        rejot-cli manifest connection add \
            --slug "my-datastore" \
            --connection-string "postgres://postgres:postgres@example:5432/postgres"
      

Configuring Data Stores

Next, link a data store to the connection:

        rejot-cli manifest datastore add \
            --connection my-datastore \
            --publication rejot_publication \
            --slot rejot_slot
      

There’s an (implicit) difference between data stores with or without a publication and slot. Data stores without these can only be used as a destination, while data stores with these can be used as either a source or destination.

A data store can be removed from the manifest in the following way:

        rejot-cli manifest datastore remove my-datastore
      

Configuring Event Stores

Event stores are also based on a connection, but they don’t require a publication or slot.

        rejot-cli manifest eventstore add --connection my-eventstore
      

Similar to data stores, an event store can be removed from the manifest in the following way:

        rejot-cli manifest eventstore remove my-eventstore
      

Verifying Your Configuration

You can use the info command to display a parsed version of the manifest. When errors or warnings are detected, they will be printed to the console.

        $ rejot-cli manifest info
      

        Manifest Configuration:

Connections:
  - my-datastore (postgres)
    Host: localhost:5432
    Database: postgres
    User: postgres
    string: postgres://postgres@localhost:5432/postgres

Data Stores (Replication Sources):
  - Connection: my-datastore
    Publication / slot: rejot_publication / rejot_slot

Event Stores (Replication Targets):
  - Connection: my-eventstore
      

Workspaces

A ReJot workspace is a collection of manifests that are managed together. It’s useful for local development use cases where you’re typically only using a single event store and only want to run a single sync service.

A manifest can link to other manifests using the workspaces field. This field should contain the relative path to other manifest files.

        {
  "slug": "my-sync-slug",
  "workspaces": ["./service-one/rejot-manifest.json", "./service-two/rejot-manifest.json"]
}
      

The workspace manifest is typically in a parent directory related to other manifests. An example structure might look like this:

        my-monorepo/
├── service-one/
│   ├── rejot-manifest.json
│   └── ...
├── service-two/
│   ├── rejot-manifest.json
│   └── ...
└── rejot-manifest.json
      

When using the collect command, schemas are collected into the nearest manifest.

Next Steps

Now that you know how to manage your manifest file, you can create public and consumer schemas