mfahampshire
02bc8b4fc0
* Debug logging * Yield based logging * Reintroduce non-dummy task manager, try add counting for BatchMessageSender, a couple of compiler target introductions on use statements. * Fixed time runtime err * Uncomment forgetme/rememberme * remove diffs from debug * missed commented out forgetme * yet more forgetme comments * * Added missing clientreqestsender clone to wasm client to stop premature drop & busyloop * Removed hacky mem::forget fix * Remove debug panic_hook * Conditional import + use of wasm_utils::console_log * add wasm_util dep * Commenting out or removing debug logging * Remove missed comment * cleanup gitignore * clippy * update go version in ci * removed unused deps * add clippy ignore * remove mixfetch from ci build * add minifetch fix * comment out unused ts builds * stop contract clients killing ci for the moment * wasm target locking for imports * Either remove console_log! macro or introduce cfg(debug_assertions) * downgrade netlink * debug assertions for console_log import * modify config logging (debug -> normal) * remove clone for client_request_sender + grab directly in struct creation * reintroduce debug print for config in debug mode * remove ood / unused custom topology from worker example file * clippy * clippy - ignore todo() tests * modified humantime test in line with new parsing rules
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 IGNOREvsON CONFLICT DO NOTHING) - RETURNING clause behavior
For more details on PostgreSQL setup, see README_PG.md.