Files
nym/nym-node-status-api
Jędrzej Stuczyński b3d02e3ba7 feat: NS ticket faucet (#6047)
* ns-api: remove sqlite support

ns-api: add env var to skip migrations for local dev

ns-api: tidy up imports

ns-api: fix deserialisation fo node descriptions

update dockerfile

update README

fix up README and example env

ns-api: bump major version to 4

ns-api: add more geoip data and new performance field in dvpn responses

* ability to import partial ticketbooks

* wip: adding common ecash state to NS API

* buffering ticketbooks

* wip

* distribute tickets when getting testrun assignment

* passing ticketbook data to gateway probe

* wrapped around storage tx

* ticketbook query fixes

* clippy

* modified testrun assignment to always return tickets

* Update version

* Update push-node-status-agent.yaml

* Update Cargo.toml

* add entrypoint for ns agents

* sqlx prepare and cargo fmt

* clippy fixes

* Update ci-check-ns-api-version.yml

---------

Co-authored-by: Mark Sinclair <mmsinclair@users.noreply.github.com>
Co-authored-by: benedetta davico <46782255+benedettadavico@users.noreply.github.com>
Co-authored-by: benedettadavico <benedetta.davico@gmail.com>
2025-09-29 14:53:15 +01:00
..
2025-02-11 12:07:15 +01:00
2025-07-22 15:25:43 +02:00

Nym Node Status API

The Node Status API serves information about individual nym-nodes in the Mixnet, such as which role they are operating in, statistics about them, services such as Network Requesters, as well as summaries of the state of the Mixnet.

We recommend that developers building applications such as explorers or analytics interfaces about the Mixnet run their own instance of the API, in order to promote a robust network of downstream services, and spread the load of API calls amongst as many endpoints as possible.

You can find build and operation instructions in the docs.

Database Support

The Node Status API supports both SQLite and PostgreSQL databases through Cargo feature flags:

  • SQLite (default): Lightweight, file-based database suitable for development and small deployments
  • PostgreSQL: Full-featured database recommended for production deployments

Building with Different Database Backends

# Build with SQLite (default)
cargo build --features sqlite --no-default-features

# Build with PostgreSQL
cargo build --features pg --no-default-features

Running Tests

# Test with SQLite
cargo test --features sqlite --no-default-features

# Test with PostgreSQL
make test-db  # This sets up a test PostgreSQL instance

Development Commands

The project includes a Makefile with helpful commands for both database backends:

# Check code compilation
make check-sqlite     # Check with SQLite
make check-pg        # Check with PostgreSQL

# Run clippy linter
make clippy-sqlite   # Lint with SQLite
make clippy-pg      # Lint with PostgreSQL
make clippy         # Run both

# PostgreSQL development
make dev-db         # Start a PostgreSQL instance for development
make prepare-pg     # Prepare SQLx offline cache for PostgreSQL

Implementation Details

The database abstraction is implemented using a query wrapper that automatically converts SQLite-style ? placeholders to PostgreSQL-style $1, $2, ... placeholders at runtime. This allows writing queries once using SQLite syntax while maintaining compatibility with both databases.

Key differences handled:

  • Placeholder syntax (? vs $1, $2, ...)
  • Type conversions (SQLite uses i64, PostgreSQL uses i32 for many fields)
  • SQL dialect differences (e.g., INSERT OR IGNORE vs ON CONFLICT DO NOTHING)
  • RETURNING clause behavior

For more details on PostgreSQL setup, see README_PG.md.