Roadmap

This page lists the work that lies ahead of Navree: the modules and drivers deliberately left out of 0.1, the performance problems the benchmark found, and the smaller gaps 0.1 shipped with. It is a list of known work, not a schedule. Nothing here has a date, and nothing here is promised; until something ships, plan as if it won't.

If one of these matters to you, Contributing explains how to help.

Deferred from 0.1

Navree's original requirements describe a much larger framework than 0.1. The first release covers the foundation and the modules a real application, the reference CRM, needed. These were left out on purpose:

Two decisions taken during 0.1 also shape what comes next. Authentication follows NestJS (JWTs and rotating refresh tokens), so Laravel Sanctum's SPA cookie authentication and personal access tokens aren't built. Errors use the NestJS format, so there are no application/problem+json responses. Both were choices, not omissions.

Performance work

The benchmark shows that Navree's own per-request cost is high. On plain JSON it delivers 22% of the throughput of a hand-written Axum and sqlx service built on the same libraries, and on a single database query 43%. Navree used nearly all its CPU in both tests while PostgreSQL had capacity to spare, so the time goes into Navree's request pipeline, not the database.

Reading the code behind those numbers found these causes. Fixing them is the next performance step:

1. An extra database round trip per connection. navree-db leaves sqlx's test_before_acquire on, so every checkout from the pool pings the database first: a single-query request costs two round trips instead of one. There is no setting to turn it off yet.
2. An extra query per transaction. Every unit-of-work transaction on PostgreSQL first runs SELECT set_config('navree.actor', ...) to record the acting user and the request id on the transaction: one more round trip before its first real query.
3. A task per request. The unit-of-work layer spawns a Tokio task for every request, including requests that never touch the database, such as the plain JSON test.
4. Process-wide locks on every request. Maintenance mode takes a mutex and a read-write lock, and the per-IP rate limiter uses one global Mutex<HashMap>.
5. Work done for nobody. The request-context layer builds metrics labels (fresh strings) even when no metrics recorder is installed, and creates a request scope and a UUID request id.
6. A slow CurrentUser. It finds AuthService by scanning every provider, and loads every column of the user, including the password hash and the two-factor secrets.
7. JSON parsed twice. Request bodies are parsed into a serde_json::Value, then into the DTO.
8. Change events nobody reads. Repo::insert serializes each new row for a change event even when nothing listens for change events.

A related kernel issue: AppContext::get, try_get and get_named search every provider on each call, so services that resolve optional dependencies per request pay for it every time.

Navree's memory use and startup are already good: 4 MB at idle, 38 MB at peak and 23 ms to ready in the benchmark. The work above is about throughput and latency.

Smaller gaps

These shipped in 0.1 and are described in the release notes:

• publishing the crates to crates.io;
• the configuration precedence of .env and config/app.toml, which is the opposite of what the generated files say;
• an auth:prune command for old refresh tokens;
• route-specific rate limits for registration and password reset, and a password confirmation for regenerating two-factor recovery codes;
• query parameters and non-JSON bodies in the OpenAPI document, and an OpenAPI schema for Page<T>;
• a soft-delete scope for record checks and exists rules;
• a size limit for the memory cache store;
• cloud disks for file storage, beyond the local filesystem;
• keeping the listening socket open across navree dev restarts;
• a command to assign roles to users;
• reporting validation's serde errors together with the garde rules, instead of one at a time.