Reference app

A real CRM,built on Navree.

Companies, contacts, a deal pipeline, tasks and a live dashboard for a sales team with roles and an audit trail. The API is a Navree app split into feature crates, and it ships with two front ends, Next.js and Nuxt. It lives in the repository and is tested with the framework.

Run it locally Read the tour

localhost:3000/

apps/crm-web

The Navree CRM dashboard in the Next.js front end: open pipeline, weighted forecast, deals won this month, the pipeline by stage and the manager's tasks

A deal page of the Next.js front end on a phone

CRM modules: 8CRM modulesFour feature crates on one shared core
framework modules: 19framework modulesHTTP to real time, configured once
roles: 3rolesChecked on routes, in SQL and in the browser
front ends: 2front endsNext.js and Nuxt on one BFF contract

The screens

Every screen, in both front ends.

Captured from the running app against the CRM API and its demo data, signed in as the sales manager. Switch between the Next.js and the Nuxt front end: the same API, the same contract, the same theme.

localhost:3000/

apps/crm-web

The dashboard · Next.js

Open pipeline, a forecast weighted by stage probability, deals won this month, the pipeline by stage and today's tasks, in one call.

Served by

GET /api/v1/dashboard

The same app on a phone.

The sidebar becomes a sheet, the top bar keeps search, Create and notifications, and every screen works at 390 px without scrolling sideways. Detail pages lead with a back arrow and the record's name.

The dashboard of the Next.js front end on a phone — Dashboard · Next.js

How it is built

A Navree app, from crates to sockets.

The CRM uses the framework the way your app will: feature modules on a shared core, access rules in one function, events and queues for side effects, real time over the Pusher protocol and a backend-for-frontend that keeps tokens out of the browser.

Read the full tour

01 · Modules

Feature crates on one core.

Each feature is a crate with its own module, controller, service and tests. Feature crates depend only on crm-core, never on each other, so a deal can reach shared models but never the contacts code. Cargo builds and tests them in parallel.

crm-core holds the ORM models and their factories, the migrations, the roles and the abilities function, and its platform() configures the framework modules once for the API and every test.

apps/crm-api/src/app.rs

pub fn app(sources: ConfigSources) -> AppBuilder {
    platform(Navree::app(), sources)
        .module(CrmCoreModule)
        .module(UsersModule)
        .module(CompaniesModule)
        .module(ContactsModule)
        .module(DealsModule)
        .module(ActivitiesModule)
        .module(DashboardModule)
        .module(DemoModule)
}

The CRM API

depends on

02 · Access rules

Every rule in one function, enforced three ways.

Three roles, admin, manager and rep, are stored in the access module's tables. One function, crm_core::abilities::define, says what each may do: read everything, create records, change what you own, never delete a won deal.

Routes declare what they need. #[can(Move, Deal, from = "id")] loads the deal and checks it before the handler runs.
Lists take Accessible<Deal, Read>, which turns the rules into SQL, so a page only holds rows the user may read.
The browser gets the same rules as CASL JSON from GET /api/me/abilities and hides what a user can't do.

crates/crm-deals/src/controller.rs

#[controller("/deals", version = "1")]
impl DealsController {
    #[get("/board")]
    #[can(Read, Deal)]
    async fn board(
        &self,
        uow: Uow,
        scope: Accessible<Deal, Read>,
        Valid(Query(filter)): Valid<Query<BoardFilter>>,
    ) -> Result<Json<DealBoard>> {
        Ok(Json(self.deals.board(&uow, scope, filter).await?))
    }

    #[post("/{id}/move")]
    #[can(Move, Deal, from = "id")]
    async fn move_deal(
        &self,
        uow: Uow,
        CurrentUser(user): CurrentUser,
        deal: Authorized<Deal, Move>,
        Valid(Json(input)): Valid<Json<MoveDeal>>,
    ) -> Result<Json<DealResource>> {
        let deal = self.deals.move_to(&uow, user.id, deal.into_inner(), input).await?;
        Ok(Json(deal))
    }
}

03 · Events and real time

A deal moves on every open board.

After every change to a deal commits, the API broadcasts it as deal.updated on private-crm.deals, and every open board moves the card. Winning or reassigning a deal also emits DealWon or DealAssigned: a queued listener notifies the owner, stored for the bell, pushed to their browser and mailed.

crates/crm-deals/src/lib.rs

impl DealsModule {
    /// The owner notifications (a queued listener of both events) and
    /// their mail template.
    fn wire(&self, m: &mut ModuleBuilder) {
        m.listen::<DealAssigned, NotifyDealOwner>()
            .on::<DealWon, NotifyDealOwner>()
            .templates(notification::TEMPLATES);
    }
}

04 · Workspaces

One team today, many tomorrow.

The CRM runs one team's workspace. To serve many teams, add WorkspaceModule and give the tenant tables a workspace_id: requests resolve their workspace from a header, a subdomain, a path or a token claim, members get workspace roles, and every query stays inside its workspace. Routes, services and rules stay as they are.

Read about workspaces

apps/crm-api/src/app.rs

platform(Navree::app(), sources)
    .module(WorkspaceModule::from_config())
    .module(CrmCoreModule)
    .module(CompaniesModule)
    .module(DealsModule)

Backend for frontend

request
real-time event

05 · The BFF

No token ever reaches the browser.

The browser calls only its own server. That server, the backend-for-frontend, keeps Navree's access token and rotating refresh token in httpOnly cookies, forwards each call with Authorization: Bearer and refreshes once per refresh token, because reusing a rotated one ends the session.

The WebSocket goes straight to Navree and carries no token. Private channels are authorized through the BFF.

The backend-for-frontend pattern

One API, your front end

Next.js or Nuxt. Same contract, same theme.

Both front ends run a backend-for-frontend with the same routes, cookies and rules, written as framework-free TypeScript and wired in with a few lines. Pick the one your team knows; the API doesn't change.

One API, two front ends

request

The contract

POST /api/auth/login signs in at Navree, keeps the tokens in httpOnly cookies (navree_at, navree_rt) and returns only the user.
Every other /api/* call is forwarded on the same path, so the API's OpenAPI document types the client.
A 401 refreshes once per refresh token, shared by every request in flight.
A write from another origin gets a 403 before it reaches Navree.
/broadcasting/auth signs private channels for pusher-js.
The UI reads the access rules from GET /api/me/abilities with CASL.

The theme

Both are dark, on the navree.com tokens, with a sidebar that folds to icons with Ctrl B, a 48px top bar, a command palette on Ctrl K, 4px corners on controls and 6px on surfaces. shadcn/ui draws the React app and shadcn-vue the Vue one.

Next.js

apps/crm-web

Next.js 16, React, TanStack Query, shadcn/ui

src/app/api/[...path]/route.ts

import { bff } from "@/lib/bff/server";

/** Every `/api/*` call from the browser is forwarded to Navree with the bearer token from the httpOnly cookie. */
function handle(request: Request): Promise<Response> {
  return bff.proxy(request, new URL(request.url).pathname);
}

export const dynamic = "force-dynamic";
export { handle as DELETE, handle as GET, handle as HEAD, handle as PATCH, handle as POST, handle as PUT };

Nuxt

apps/crm-nuxt

Nuxt 4, Vue 3, TanStack Query, shadcn-vue

server/api/[...path].ts

import { useBff } from "../lib/instance";

/**
 * Every `/api/*` call from the browser goes to Navree with the bearer token
 * from the httpOnly cookie (refreshed once on a 401). Mutations must come from
 * this app's own origin.
 */
export default defineEventHandler((event) => {
  const request = toWebRequest(event);
  return useBff().proxy(request, new URL(request.url).pathname);
});

Start your own

The same stack, one command away.

The SaaS starter kit is built from the CRM's patterns: an API with sign-in, workspaces, billing and an admin panel, and a front end with the same BFF. Choose the front end with --ui.

Read about the starter kits

Next.js front end

A SaaS app on Next.js

$ navree new acme --kit saas --ui next

$ cd acme

$ navree dev

navree dev serves the API on :8080 and the web app on :3000. To run them apart, use navree dev --no-web and pnpm dev in web/.

Nuxt front end

A SaaS app on Nuxt

$ navree new acme --kit saas --ui nuxt

$ cd acme

$ navree dev

navree dev serves the API on :8080 and the web app on :3000. To run them apart, use navree dev --no-web and pnpm dev in web/.

Run this CRM

Run it on your machine.

You need Rust 1.95 or newer, Node.js and pnpm. No database server: development uses SQLite. Run each long-running command in its own terminal.

Every option in the tour

The API

Create a key, the database and its demo data, then serve the API and its WebSocket server.

apps/crm-api

git clone https://github.com/NavreeHQ/navree
cd navree/apps/crm-api
cargo run -p crm-api -- key:generate          # put it in .env as APP_KEY=...
cargo run -p crm-api -- migrate:fresh --seed  # SQLite: schema, roles, demo data
APP_REALTIME__ALLOWED_ORIGINS=http://localhost:3000,http://localhost:3102 \
  cargo run -p crm-api -- serve               # http://127.0.0.1:8080

The Next.js front end

Talks to the API at NAVREE_API_URL, http://127.0.0.1:8080 by default.

apps/crm-web

cd navree/apps/crm-web
pnpm install
pnpm dev                                      # http://localhost:3000

Or the Nuxt front end

Point its BFF and its socket at the same API.

apps/crm-nuxt

cd navree/apps/crm-nuxt
pnpm install
NAVREE_API_URL=http://127.0.0.1:8080 NUXT_PUBLIC_WS_PORT=8080 pnpm dev
                                              # http://localhost:3102

Sign in with a demo account. Every password is `password123`.
Email	Role	Can
[email protected]	admin	Everything, with users, roles and the audit log
[email protected]	manager	Every record, reassign deals, export contacts
[email protected]	rep	Read everything, change only their own records
[email protected]	rep	A second rep, to watch live updates and ownership

No Rust toolchain yet?

pnpm dev:mock runs either front end against an in-browser mock of the API, with the same demo accounts.

Browse the code on GitHub