# `DdDataStreams.Backend`
[🔗](https://github.com/rockneurotiko/dd_data_streams/blob/main/lib/dd_data_streams/backend.ex#L1)

The seam where checkpoints are recorded.

Production never resolves a test owner: it only asks the configured backend
whether the calling process is recording and, if it is, hands the checkpoint
over. The default backend, `DdDataStreams.Backend.Aggregator`, reads
`DdDataStreams.Config.enabled?/0` and calls
`DdDataStreams.Aggregator.add/1`, so an application that configures nothing
behaves exactly as it did before this behaviour existed.

A test suite can replace it with `DdDataStreams.Testing.Backend`:

    config :dd_data_streams, backend: DdDataStreams.Testing.Backend

That backend answers per process, from `NimbleOwnership`, instead of from the
application environment, so tests that opt in can run concurrently without
seeing each other's checkpoints. An application that configures no backend
never references the testing modules.

# `enabled?`

```elixir
@callback enabled?() :: boolean()
```

Whether the calling process is recording checkpoints.

# `record`

```elixir
@callback record(DdDataStreams.Pathway.checkpoint()) :: :ok
```

Records one checkpoint.

Called only when `enabled?/0` answered `true` for the same process.

# `enabled?`

```elixir
@spec enabled?() :: boolean()
```

Asks the configured backend whether the calling process is recording.

# `impl`

```elixir
@spec impl() :: module()
```

The configured backend, or the default one when `:backend` is not set.

# `record`

```elixir
@spec record(DdDataStreams.Pathway.checkpoint()) :: :ok
```

Hands one checkpoint to the configured backend.

---

*Consult [api-reference.md](api-reference.md) for complete listing*