Showcase

The bike shop is Renox's flagship example. Customers buy bikes and gear, rent a bike by the hour or the day, and book services or a plan that books them for them. Staff in three stores run the counter, the fleet, the workshop board, the stock and the reports, each with the permissions their role gives them in that store. It is a complete app, tested end to end, and it runs from one executable with SQLite next to it.

Every page explains itself: on a wide screen a panel beside it says what the page is for, which Renox features it uses and why, and shows the code that makes it work.

Try the live demo Read the code Every page and its features

Take a look

The shop's front doorBuy, rent or book a service; the panel explains the page

The catalogueFilters and sorting; htmx swaps only the results

A productSizes and colours, with stock in each store

Renting a bikeThe bikes free for the whole period, with their price

The workshop boardWork orders moved by dragging or the keyboard

The reportsFigures and charts drawn on the server, no chart library

Measured

A release build of Renox 1.1.1 with the demo's large seed: 1,016 product variants, 601 customers, 15,412 rentals, 5,000 orders and 3,002 work orders. How we measured is at the bottom.

How it stays fast

Ok(view("catalog/index.html", context! { cards, filters, … })
    .fragment("results"))

let photos = has_many(
    db, &products, ProductPhoto::query(),
    "product_id", |p| p.product_id).await?;

Fast, and still correct

Speed is no use if two customers can rent the same bike for the same afternoon. The form checks first, so the customer sees "just taken" next to the field. Then the transaction that writes the rental takes the bike's row and checks again, because another booking may have landed in between: two bookings of one bike run one after the other, and the second sees the first.

let mut tx = db.begin_immediate().await?;
// SQLite's write lock, PostgreSQL's row lock:
let Some(bike) = RentalBike::query()
    .where_(RentalBike::ID.eq(new.bike_id))
    .lock_for_update()
    .first(&mut tx)
    .await?
else {
    return Ok(Err(Refusal::Gone));
};
if clashing(bike.id, new.start, new.end).exists(&mut tx).await? {
    return Ok(Err(Refusal::Taken)); // rolled back, nothing written
}
// ...the rental, with its price and deposit, then
tx.commit().await?;

The rental keeps the store that owns the bike and the store that rented it out, so the books between the stores never change when a bike moves later.

How we measured

• examples/bikeshop at Renox 1.1.1, built with cargo build --release (80 MB, 62 MB stripped), then demo:seed --size large, as on the demo. Serving these pages it used about 60 MB of memory.
• Queries per page from /_renox/debug, on the second visit: a product list runs 13 (14 in a category, for 4 products or 24), a search 13, a product page 7, the home page 8.
• Sizes with curl, and gzip -9 for the compressed figures: the app sends plain responses and leaves compression to the proxy in front of it. Each page carries its "About this page" panel with code samples, as on the demo.
• We'll add throughput and latency once they come from a quiet server; the laptop these figures come from was busy compiling, which isn't a fair place to time anything.