DEV Community: Martin Palopoli

Building the flagship (3): a packaged UI library, i18n, and one-command Docker

Martin Palopoli — Fri, 28 Aug 2026 15:15:52 +0000

TL;DR — The Admin flagship isn't just an app — it's the app the companion UI library (fitz_liveviews.ui.*) was extracted from. The DataGrid, the sortable headers, the toolbar, the pager, the confirm dialog, the toasts, the tree view, every form input — all drop-in components you import and render. They're themed through --flv-* design tokens (so a light/dark/auto switch is free), translated ES/EN through a tiny server-side dictionary, and the whole thing runs with one docker compose up. This closes the flagship trilogy. (Part 6 of the FitzLiveViews series.)

Parts 4 and 5 showed the flagship's auth and its live grid. This one is about reuse: the app is built almost entirely from packaged components, and this is how you'd build yours.

Excerpts from the real app (examples/admin/); the runnable path is git clone + docker compose up.

The library was mined from this app

Open the top of the employees screen and you see the library, imported piece by piece — this is verbatim from the app:

from fitz_liveviews.ui.DataGrid import data_grid, data_grid_render
from fitz_liveviews.ui.SortableHeader import sortable_header, sortable_header_render
from fitz_liveviews.ui.GridToolbar import grid_toolbar, grid_toolbar_render
from fitz_liveviews.ui.GridFilters import grid_filters, grid_filters_render
from fitz_liveviews.ui.Pager import pager, pager_render
from fitz_liveviews.ui.ConfirmDialog import confirm_dialog, confirm_dialog_render, ...
from fitz_liveviews.ui.Toast import toast, toast_render, toast_show, toast_dismiss
from fitz_liveviews.ui.TreeView import tree_view, tree_view_render
from fitz_liveviews.ui.Chip import chip, chip_render
from fitz_liveviews.ui.CountBadge import count_badge, count_badge_render

Each is a fitz.toml dependency sub-path (fitz_liveviews.ui.X) — the cross-directory / dependency import that lets you pull a component out of the library instead of copying it. You render one by building its props and taking .raw:

let filters = grid_filters_render(grid_filters {
  pills: estado_pills,
  filter_label: t(locale, "grid.col.estado"),
}).raw

The employee row (EmpleadoRow) stays app-specific on purpose — it's the domain row, re-rendered N times per live frame. Everything around it is the library. The catalog is in docs/ui-components.md, and you can play with the components in isolation in the gallery.

One theme switch, everywhere

Every packaged component reads its colors from --flv-* design tokens (--flv-color-primary, --flv-surface, --flv-text, …). The app defines those tokens once, aliased to its palette, with light and dark values behind a data-theme attribute. A tiny inline script sets that attribute before first paint from the saved preference — so there's no flash — and the theme switch just flips it. Because every component reads the same tokens, the whole panel — grid, forms, dialogs, chips — switches light/dark/auto in one move. No per-component theme wiring.

i18n without a library

Translation is a server-side dictionary — no i18n framework, no build step:

// i18n.fitz
fn t(locale: Str, key: Str) -> Str { ... }   // "es"/"en" + key → string

Every user-facing string goes through t(locale, "grid.search"). The active locale comes from a cookie; a GET /lang/{code} handler sets it and redirects back:

@get("/lang/{code}")
fn set_lang(code: Str, referer: Str?) -> Response {
  let cookie = lang_cookie_name() + "=" + loc + "; Path=/; SameSite=Lax; Max-Age=31536000"
  return Response {
    status: 303,
    headers: { "Set-Cookie": cookie, "Location": back },   // back to where you were
  }
}

The 🌐 ES / EN switch in the topbar hits that route. Because rendering is server-side, switching language re-renders every string on the next frame — including inside the live grid.

One command to run it

The whole stack — Postgres with schema + seed, and the app — is one docker compose up:

services:
  db:
    image: postgres:16-alpine
    environment: { POSTGRES_USER: fitz, POSTGRES_PASSWORD: fitz, POSTGRES_DB: fitz_admin }
    volumes:
      - ./db/init.sql:/docker-entrypoint-initdb.d/init.sql:ro   # schema + seed
    healthcheck: { test: ["CMD-SHELL", "pg_isready -U fitz -d fitz_admin"], ... }
  app:
    build: { context: ../.., dockerfile: examples/admin/Dockerfile }
    depends_on: { db: { condition: service_healthy } }
    environment:
      DATABASE_URL: "postgres://fitz:fitz@db:5432/fitz_admin?sslmode=disable"
    ports: ["3000:3000"]

The Dockerfile is two stages: a fitz build in the official Fitz image, then the resulting native binary copied into a distroless runtime — no interpreter, no Python, no node. Postgres runs db/init.sql (schema + seed) on first boot; the app waits for the healthcheck and serves. fitz run and the built binary render bit-for-bit identical, so you develop on the interpreter and ship the binary.

git clone https://github.com/Thegreekman76/fitz-liveviews
cd fitz-liveviews/examples/admin
docker compose up --build
# → http://localhost:3000/   login: admin@fitz.dev / admin1234

The whole stack, one language

Step back and look at what that one command brings up: cookie auth (Argon2id + JWT), a responsive themed shell, live DataGrids querying Postgres over WebSockets, rich forms, i18n, CSV export, all built from a packaged UI library — and it's one language, one binary, no JavaScript build, no node_modules. That's the pitch from part 1, proven on something real.

That's the series (for now)

Six posts: the pitch, the counter twice, forms and payloads, and the flagship in three parts. If any of it made you curious, the best next step is to run the flagship — docker compose up — and then read the same components in the catalog.

Star the repo, try it, and tell me what you'd build with it.

Construyendo el flagship (3): una librería de UI empaquetada, i18n, y Docker de un comando

Martin Palopoli — Fri, 28 Aug 2026 15:15:08 +0000

TL;DR — El Admin flagship no es solo una app — es la app de la que se extrajo la librería de UI empaquetada (fitz_liveviews.ui.*). El DataGrid, los headers ordenables, la toolbar, el pager, el diálogo de confirmación, los toasts, el tree view, cada input de form — todos componentes drop-in que importás y renderizás. Están tematizados con design tokens --flv-* (así un switch light/dark/auto es gratis), traducidos ES/EN con un diccionario chiquito del lado del servidor, y todo corre con un docker compose up. Esto cierra la trilogía del flagship. (Parte 6 de la serie FitzLiveViews.)

Las partes 4 y 5 mostraron la auth del flagship y su grid en vivo. Esta es sobre reuso: la app está construida casi enteramente con componentes empaquetados, y así construirías la tuya.

Extractos de la app real (examples/admin/); el camino runnable es git clone + docker compose up.

La librería se extrajo de esta app

Abrí el tope de la pantalla de empleados y ves la librería, importada pieza por pieza — esto es textual de la app:

from fitz_liveviews.ui.DataGrid import data_grid, data_grid_render
from fitz_liveviews.ui.SortableHeader import sortable_header, sortable_header_render
from fitz_liveviews.ui.GridToolbar import grid_toolbar, grid_toolbar_render
from fitz_liveviews.ui.GridFilters import grid_filters, grid_filters_render
from fitz_liveviews.ui.Pager import pager, pager_render
from fitz_liveviews.ui.ConfirmDialog import confirm_dialog, confirm_dialog_render, ...
from fitz_liveviews.ui.Toast import toast, toast_render, toast_show, toast_dismiss
from fitz_liveviews.ui.TreeView import tree_view, tree_view_render
from fitz_liveviews.ui.Chip import chip, chip_render
from fitz_liveviews.ui.CountBadge import count_badge, count_badge_render

Cada uno es un sub-path de dependencia del fitz.toml (fitz_liveviews.ui.X) — el import cross-directory / de dependencia que te deja sacar un componente de la librería en vez de copiarlo. Renderizás uno construyendo sus props y tomando .raw:

let filters = grid_filters_render(grid_filters {
  pills: estado_pills,
  filter_label: t(locale, "grid.col.estado"),
}).raw

La fila de empleado (EmpleadoRow) queda app-específica a propósito — es la fila del dominio, re-renderizada N veces por frame en vivo. Todo lo que la rodea es la librería. El catálogo está en docs/ui-components.md, y podés jugar con los componentes aislados en la galería.

Un switch de tema, en todos lados

Cada componente empaquetado lee sus colores de design tokens --flv-* (--flv-color-primary, --flv-surface, --flv-text, …). La app define esos tokens una vez, aliaseados a su paleta, con valores light y dark detrás de un atributo data-theme. Un script inline chiquito setea ese atributo antes del primer paint desde la preferencia guardada — así no hay flash — y el switch de tema solo lo cambia. Como todos los componentes leen los mismos tokens, todo el panel — grid, forms, diálogos, chips — cambia light/dark/auto de una. Sin cablear el tema por componente.

i18n sin librería

La traducción es un diccionario del lado del servidor — sin framework de i18n, sin paso de build:

// i18n.fitz
fn t(locale: Str, key: Str) -> Str { ... }   // "es"/"en" + key → string

Cada string user-facing pasa por t(locale, "grid.search"). El locale activo viene de una cookie; un handler GET /lang/{code} la setea y redirige de vuelta:

@get("/lang/{code}")
fn set_lang(code: Str, referer: Str?) -> Response {
  let cookie = lang_cookie_name() + "=" + loc + "; Path=/; SameSite=Lax; Max-Age=31536000"
  return Response {
    status: 303,
    headers: { "Set-Cookie": cookie, "Location": back },   // de vuelta a donde estabas
  }
}

El switch 🌐 ES / EN en la topbar pega a esa ruta. Como el render es del lado del servidor, cambiar idioma re-renderiza cada string en el próximo frame — incluso adentro del grid en vivo.

Un comando para correrlo

Todo el stack — Postgres con schema + seed, y la app — es un docker compose up:

services:
  db:
    image: postgres:16-alpine
    environment: { POSTGRES_USER: fitz, POSTGRES_PASSWORD: fitz, POSTGRES_DB: fitz_admin }
    volumes:
      - ./db/init.sql:/docker-entrypoint-initdb.d/init.sql:ro   # schema + seed
    healthcheck: { test: ["CMD-SHELL", "pg_isready -U fitz -d fitz_admin"], ... }
  app:
    build: { context: ../.., dockerfile: examples/admin/Dockerfile }
    depends_on: { db: { condition: service_healthy } }
    environment:
      DATABASE_URL: "postgres://fitz:fitz@db:5432/fitz_admin?sslmode=disable"
    ports: ["3000:3000"]

El Dockerfile son dos stages: un fitz build en la imagen oficial de Fitz, después el binario nativo resultante copiado a un runtime distroless — sin intérprete, sin Python, sin node. Postgres corre db/init.sql (schema + seed) al primer boot; la app espera el healthcheck y sirve. fitz run y el binario buildeado renderizan bit-a-bit idéntico, así que desarrollás sobre el intérprete y shipeás el binario.

git clone https://github.com/Thegreekman76/fitz-liveviews
cd fitz-liveviews/examples/admin
docker compose up --build
# → http://localhost:3000/   login: admin@fitz.dev / admin1234

Todo el stack, un lenguaje

Alejate y mirá lo que ese comando levanta: auth por cookie (Argon2id + JWT), un shell responsive tematizado, DataGrids en vivo consultando Postgres por WebSockets, forms ricos, i18n, export CSV, todo construido con una librería de UI empaquetada — y es un lenguaje, un binario, sin build de JavaScript, sin node_modules. Ese es el pitch de la parte 1, probado en algo real.

Esa es la serie (por ahora)

Seis posts: el pitch, el counter dos veces, forms y payloads, y el flagship en tres partes. Si algo te dio curiosidad, el mejor próximo paso es correr el flagship — docker compose up — y después leer los mismos componentes en el catálogo.

Dale una estrella al repo, probalo, y contame qué construirías con esto.

Building the flagship (2): a live DataGrid that queries Postgres on every keystroke

Martin Palopoli — Mon, 24 Aug 2026 09:53:15 +0000

TL;DR — The Admin flagship's employees screen is a live DataGrid: type in the search box, click a filter pill, sort a column, page through — and each one re-runs a real SQL query against Postgres through the Fitz ORM, then diff-patches the table over a WebSocket. Nothing is filtered in memory; the count reflects the active filters; the sort is a dynamic ORDER BY. All grid state (search term, filters, sort, page) is per-connection, so two browsers filter independently. No React, no API endpoints, no client state management. (Part 5 of the FitzLiveViews series — the flagship's centerpiece.)

Part 4 gave the flagship auth and a shell. This is the screen that makes it worth building: an employees grid that behaves like a rich SPA data table, but is entirely server-driven.

The code below is excerpted from the real app (examples/admin/) — the full grid is a few hundred lines. The snippets show the shape faithfully; the guaranteed-to-work path is git clone + docker compose up (see "Try it").

The shape

SSR paints the grid once (so the first load is instant and crawlable), then a @ws socket takes over the live layer. Each connection keeps its own grid state — the current search, filters, sort, and page — and on every event it rebuilds the query, renders, diffs, and patches:

@header(name="cookie")
@ws("/live/empleados")
async fn live(ws: WsConn<LiveFrame>, cookie: Str?) {
  let user = match user_from_cookie(cookie).await { ... }   // gate the socket
  let conn = db.connect(db_url()).await?

  // Per-connection grid state — two browsers filter independently.
  let q = ""            // search term
  let estado = "all"    // Todos / Activos / Inactivos
  let depto = 0         // department filter (0 = all)
  let sort_col = "nombre"
  let asc = true
  let page = 0

  let last = render_grid(conn, q, estado, depto, sort_col, asc, page).await

  loop {
    let frame = ws.recv()?
    // update state from the event's payload
    q      = pget(frame.payload, "q", q)
    estado = pget(frame.payload, "estado", estado)
    depto  = pget_int(frame.payload, "depto", depto)
    // ... sort + page ...

    let html    = render_grid(conn, q, estado, depto, sort_col, asc, page).await
    let patches = diff_html(last, html)
    ws.send(LiveFrame { html: html, patches: patches })?
    last = html
  }
}

pget / pget_int just read the event payload (a Map<Str, Str>) with defaults — str.to_int() parses the page number and department id. Notice there's no per-event branching: the loop reads the payload into state and re-renders. Add a filter dimension by adding a state variable and a .where.

Every dimension is real SQL

render_grid builds one query through the Fitz ORM. Each active dimension is a chained .where (they AND together), the sort is a dynamic ORDER BY, and pagination is LIMIT/OFFSET:

async fn rows_for(conn, q, estado, depto, sort_col, asc, page) -> List<Empleado> {
  let query = Empleado.where(fn(e) => e.nombre.ilike("%" + q + "%"))

  // Estado + department filters are more ANDed WHEREs, applied
  // conditionally — the whole thing is one SQL statement.
  // ... .where(fn(e) => e.activo == true) ...
  // ... .where(fn(e) => e.departamento_id == depto) ...

  return query
    .order_by(sort_col, asc)          // dynamic ORDER BY <col> ASC|DESC
    .limit(PAGE_SIZE)
    .offset(page * PAGE_SIZE)
    .all(conn).await
}

The count reflects the filters — the same .where chain, terminated with .count(conn) instead of .all — so "showing 8 of 23" is honest, not a client-side guess. Search is ilike("%q%") (case-insensitive LIKE); the estado pills map to .where(e.activo == …); the department pills to .where(e.departamento_id == …). It's all SQL, all typed, all in the same .fitz file as the socket.

What the browser does

Nothing you write. The grid's controls are the same data-flv-* conventions from part 3: the search box is a data-flv-change input that sends {"q": "<text>"}, a filter pill is a data-flv-click with a data-flv-value-estado, a sortable header sends {"sort": "cargo"}. The framework serializes those into the socket message; your loop reads them from frame.payload. The diff engine sends only the <tr>s that changed. Keyed diffing ({#for … key=e.id}) means a mid-list insert (a new row from a save) patches cleanly instead of cascading.

The result feels like a client-side data table — instant search, snappy sort — but the source of truth is Postgres, the query is real, and there's zero client state to keep in sync with the server.

Per-connection, for free

Because the grid state lives in the @ws loop's local variables, each connection has its own. Two admins on the same page filter independently; there's no shared client store, no query-param juggling. Open the app in two tabs and filter each differently — they don't interfere. That isolation is just... how server-side local variables work.

The same screen also does row selection + multi-delete, group-by, per-row expand, and a CSV export (a Response { content_type: "text/csv", ... } that bakes the active search into its href). All of it is more .where chains and more diffs.

Try it

cd fitz-liveviews/examples/admin && docker compose up --build
# → http://localhost:3000/empleados   (login: admin@fitz.dev / admin1234)

Type in the search, click the estado/department pills, sort a column, page through — every one is a round-trip to Postgres, diffed back to your table.

What's next in this series

#6 — The packaged UI library + i18n + Docker. Every reusable piece of this app — DataGrid, GridToolbar, Pager, ConfirmDialog, Toast, TreeView, the form inputs — is a drop-in component from fitz_liveviews.ui.*. The library was extracted from this app. Plus ES/EN i18n and the one-command Docker setup.

Star the repo if a Postgres-backed live grid without a client framework is the kind of thing you'd use. Next: the library it's all built from.

Construyendo el flagship (2): un DataGrid en vivo que consulta Postgres en cada tecla

Martin Palopoli — Mon, 24 Aug 2026 09:52:14 +0000

TL;DR — La pantalla de empleados del Admin flagship es un DataGrid en vivo: tipeás en el buscador, clickeás un pill de filtro, ordenás una columna, paginás — y cada uno re-ejecuta una query SQL real contra Postgres por el ORM de Fitz, después diff-parchea la tabla por WebSocket. Nada se filtra en memoria; el count refleja los filtros activos; el sort es un ORDER BY dinámico. Todo el estado del grid (término de búsqueda, filtros, sort, página) es per-connection, así que dos browsers filtran independientemente. Sin React, sin endpoints de API, sin manejo de estado en el cliente. (Parte 5 de la serie FitzLiveViews — la pieza central del flagship.)

La parte 4 le dio al flagship auth y un shell. Esta es la pantalla que hace que valga la pena construirlo: una grilla de empleados que se comporta como una data table de SPA rica, pero es enteramente server-driven.

El código de abajo son extractos de la app real (examples/admin/) — el grid completo son unos cientos de líneas. Los snippets muestran la forma fielmente; el camino garantizado-que-funciona es git clone + docker compose up (ver "Probalo").

La forma

SSR pinta el grid una vez (así la primera carga es instantánea y crawleable), después un socket @ws toma la capa en vivo. Cada conexión guarda su propio estado del grid — el search, filtros, sort y página actuales — y en cada evento reconstruye la query, renderiza, diffea y parchea:

@header(name="cookie")
@ws("/live/empleados")
async fn live(ws: WsConn<LiveFrame>, cookie: Str?) {
  let user = match user_from_cookie(cookie).await { ... }   // gatea el socket
  let conn = db.connect(db_url()).await?

  // Estado del grid per-connection — dos browsers filtran independientemente.
  let q = ""            // término de búsqueda
  let estado = "all"    // Todos / Activos / Inactivos
  let depto = 0         // filtro de departamento (0 = todos)
  let sort_col = "nombre"
  let asc = true
  let page = 0

  let last = render_grid(conn, q, estado, depto, sort_col, asc, page).await

  loop {
    let frame = ws.recv()?
    // actualiza el estado desde el payload del evento
    q      = pget(frame.payload, "q", q)
    estado = pget(frame.payload, "estado", estado)
    depto  = pget_int(frame.payload, "depto", depto)
    // ... sort + page ...

    let html    = render_grid(conn, q, estado, depto, sort_col, asc, page).await
    let patches = diff_html(last, html)
    ws.send(LiveFrame { html: html, patches: patches })?
    last = html
  }
}

pget / pget_int solo leen el payload del evento (un Map<Str, Str>) con defaults — str.to_int() parsea el número de página y el id de departamento. Fijate que no hay branching por evento: el loop lee el payload al estado y re-renderiza. Agregás una dimensión de filtro agregando una variable de estado y un .where.

Cada dimensión es SQL real

render_grid construye una query por el ORM de Fitz. Cada dimensión activa es un .where encadenado (que ANDean juntos), el sort es un ORDER BY dinámico, y la paginación es LIMIT/OFFSET:

async fn rows_for(conn, q, estado, depto, sort_col, asc, page) -> List<Empleado> {
  let query = Empleado.where(fn(e) => e.nombre.ilike("%" + q + "%"))

  // Los filtros de estado + departamento son más WHEREs ANDeados,
  // aplicados condicionalmente — todo es un solo statement SQL.
  // ... .where(fn(e) => e.activo == true) ...
  // ... .where(fn(e) => e.departamento_id == depto) ...

  return query
    .order_by(sort_col, asc)          // ORDER BY <col> ASC|DESC dinámico
    .limit(PAGE_SIZE)
    .offset(page * PAGE_SIZE)
    .all(conn).await
}

El count refleja los filtros — la misma cadena de .where, terminada con .count(conn) en vez de .all — así que "mostrando 8 de 23" es honesto, no una adivinanza del cliente. El search es ilike("%q%") (LIKE case-insensitive); los pills de estado mapean a .where(e.activo == …); los de departamento a .where(e.departamento_id == …). Todo es SQL, todo tipado, todo en el mismo archivo .fitz que el socket.

Qué hace el browser

Nada que escribas vos. Los controles del grid son las mismas convenciones data-flv-* de la parte 3: el buscador es un input data-flv-change que manda {"q": "<texto>"}, un pill de filtro es un data-flv-click con un data-flv-value-estado, un header ordenable manda {"sort": "cargo"}. El framework las serializa al mensaje del socket; tu loop las lee de frame.payload. El motor de diff manda solo los <tr> que cambiaron. El diffing por key ({#for … key=e.id}) hace que un insert en el medio de la lista (una fila nueva de un save) parchee limpio en vez de cascadear.

El resultado se siente como una data table de cliente — search instantáneo, sort ágil — pero la fuente de verdad es Postgres, la query es real, y hay cero estado de cliente que mantener en sync con el servidor.

Per-connection, gratis

Como el estado del grid vive en las variables locales del loop @ws, cada conexión tiene el suyo. Dos admins en la misma página filtran independientemente; no hay store de cliente compartido, ni malabares de query-params. Abrí la app en dos pestañas y filtrá cada una distinto — no se interfieren. Ese aislamiento es simplemente... cómo funcionan las variables locales del lado del servidor.

La misma pantalla también hace selección de filas + multi-delete, group-by, expand por fila, y un export CSV (un Response { content_type: "text/csv", ... } que bakea el search activo en su href). Todo eso son más cadenas de .where y más diffs.

Probalo

cd fitz-liveviews/examples/admin && docker compose up --build
# → http://localhost:3000/empleados   (login: admin@fitz.dev / admin1234)

Tipeá en el buscador, clickeá los pills de estado/departamento, ordená una columna, paginá — cada uno es un round-trip a Postgres, diffeado de vuelta a tu tabla.

Qué viene en la serie

#6 — La librería de UI empaquetada + i18n + Docker. Cada pieza reusable de esta app — DataGrid, GridToolbar, Pager, ConfirmDialog, Toast, TreeView, los inputs del form — es un componente drop-in de fitz_liveviews.ui.*. La librería se extrajo de esta app. Más i18n ES/EN y el setup Docker de un comando.

Dale una estrella al repo si un grid en vivo sobre Postgres sin framework de cliente es el tipo de cosa que usarías. Lo próximo: la librería de la que está todo construido.

Building the flagship (1): browser-correct cookie auth in Fitz

Martin Palopoli — Sat, 15 Aug 2026 11:15:17 +0000

TL;DR — Fitz has @auth_provider / @authenticated for Bearer-token APIs, but a browser admin panel needs something different: the browser can't send an Authorization header on a page navigation or a WebSocket handshake, and an unauthenticated request should redirect to /login, not return a JSON 401. So the flagship Admin app uses a session cookie: login verifies the password with Argon2id, signs a JWT, and puts it in an HttpOnly cookie; every protected page reads the cookie, resolves the user through the ORM, and redirects on failure — the way Django or Rails gate a browser session. All in Fitz, no external auth library. (Part 4 of the FitzLiveViews series — the first of a few on the flagship.)

Parts 1–3 built components in isolation. Now the real thing: a complete back-office admin panel — auth, a responsive shell, live DataGrids over Postgres, i18n, Docker. This post is auth and the shell; the next ones are the grids.

The code below is excerpted from the real app (examples/admin/) to show the shape — it's a 14-file, Postgres-backed, dockerized project, so the guaranteed-to-work path is to clone it and run docker compose up (see "Try it" at the end). The snippets are faithful to the source; the repo is the runnable artifact.

Why cookies, not `@auth_provider`

Fitz core ships @auth_provider + @authenticated — and they're great for a JSON API where the client sends Authorization: Bearer <token> and gets a 401 on failure. A browser admin panel wants two different things:

The browser can't send an Authorization header on plain page navigation, or on a WebSocket handshake. It does send cookies, automatically. So the session token rides in an HttpOnly cookie.
An unauthenticated page should redirect to /login, not dump a JSON error at the user.

So the app hand-rolls a cookie session — which in Fitz is about 40 lines, because JWT and password hashing are built into the language.

Login — Argon2id + JWT → Set-Cookie

Login is a @post that takes JSON credentials, verifies the password against the stored Argon2id hash, signs a JWT, and returns it as a Set-Cookie header using the Response { ... } built-in:

@post("/login")
async fn login_submit(creds: Credentials, cookie: Str?) -> Response {
  let user = match find_by_email(creds.email).await { ... }

  // hash.verify is Argon2id — built into Fitz, no passlib/bcrypt dep.
  if (not hash.verify(creds.password, user.password_hash)) {
    return login_failed(...)
  }

  let claims = { "email": user.email, "role": user.role }
  let token = jwt.encode(claims, jwt_secret())     // HS256, built-in

  let set_cookie = session_cookie_name() + "=" + token
    + "; HttpOnly; Path=/; SameSite=Lax; Max-Age=86400"

  return Response {
    status: 200,
    headers: { "Set-Cookie": set_cookie },
  }
}

hash.verify (Argon2id) and jwt.encode (HS256) are Fitz built-ins — no pip install passlib python-jose, no npm install bcrypt jsonwebtoken. The Response { ... } built-in is what lets a handler set a custom header instead of returning plain JSON.

(One wrinkle: login posts JSON via a small fetch, not a native <form>, because Fitz @post handlers take a JSON body, not form-urlencoded. A future core enhancement can accept form posts.)

The session check — cookie → JWT → user (via the ORM)

Resolving the logged-in user is: pull the token out of the raw Cookie header, decode the JWT, read the email claim, and look the user up in Postgres — through the Fitz ORM:

async fn user_from_cookie(cookie: Str?) -> Result<User> {
  let token  = token_from_cookie(cookie)?          // parse the Cookie header
  let claims = jwt.decode(token, jwt_secret())?    // verify signature + expiry
  let email  = match claims.get("email") { ... }

  let conn = db.connect(db_url()).await?
  return User.where(fn(u) => u.email == email).first(conn).await
}

Any failure — missing cookie, bad signature, expired token, unknown user — surfaces as Err, which a protected page turns into a redirect. Notice User.where(fn(u) => u.email == email).first(conn): that's the native Fitz ORM, a typed query against Postgres, in the same file as the auth.

Protecting a page

A protected handler reads the cookie with @header(name="cookie") and redirects to /login on any auth failure — a real 303, browser-correct:

@header(name="cookie")
@get("/")
async fn dashboard(cookie: Str?) -> Response {
  let user = match user_from_cookie(cookie).await {
    Ok(u) => u,
    Err(_) => return redirect_to("/login"),   // 303 → /login
  }
  // ... render the dashboard for `user` ...
}

That's the whole gate. An unauthenticated request to / gets 303 → /login — exactly what a browser expects, and what you can't express with a JSON-401 auth provider. /logout clears the cookie (Max-Age=0) and redirects. I verified the full flow end-to-end: GET / with no cookie → 303 /login; POST /login → Set-Cookie with the HttpOnly JWT; GET / with the cookie → the dashboard.

The responsive shell

Around every protected page is a shell built entirely from the companion UI library (AppShell / Sidebar / Topbar / Breadcrumbs / ThemeToggle):

Collapsible sidebar on desktop, off-canvas drawer on mobile — works down to 320px.
A light / dark / auto theme switch, persisted per-browser and applied before first paint (a tiny inline script reads the preference and sets the theme attribute before the body renders — no flash of the wrong theme).
A 🌐 ES / EN language switch (GET /lang/{code} sets a language cookie and redirects back).

Everything is themed through --flv-* design tokens aliased to the admin's palette, so the whole panel — every packaged component — inherits the theme switch for free.

Try it

git clone https://github.com/Thegreekman76/fitz-liveviews
cd fitz-liveviews/examples/admin
docker compose up --build          # Postgres + the app, one command
# → http://localhost:3000/   login: admin@fitz.dev / admin1234

What's next in this series

#5 — The live DataGrid. The flagship's centerpiece: an employees grid with search, filters, sorting, and pagination, re-querying Postgres and diff-patching over a WebSocket on every keystroke.

Star the repo if a real app in one language is your thing. Next: the live grid.

Construyendo el flagship (1): auth por cookie browser-correcta en Fitz

Martin Palopoli — Sat, 15 Aug 2026 11:14:36 +0000

TL;DR — Fitz tiene @auth_provider / @authenticated para APIs con Bearer token, pero un panel de administración de browser necesita otra cosa: el browser no puede mandar un header Authorization en una navegación de página ni en un handshake de WebSocket, y una request no autenticada debería redirigir a /login, no devolver un JSON 401. Así que el Admin flagship usa una cookie de sesión: el login verifica la contraseña con Argon2id, firma un JWT, y lo pone en una cookie HttpOnly; cada página protegida lee la cookie, resuelve el usuario por el ORM, y redirige si falla — como Django o Rails gatean una sesión de browser. Todo en Fitz, sin librería de auth externa. (Parte 4 de la serie FitzLiveViews — la primera de varias sobre el flagship.)

Las partes 1–3 construyeron componentes aislados. Ahora lo real: un panel de administración de back-office completo — auth, un shell responsive, DataGrids en vivo sobre Postgres, i18n, Docker. Este post es la auth y el shell; los próximos son las grillas.

El código de abajo son extractos de la app real (examples/admin/) para mostrar la forma — es un proyecto de 14 archivos, con Postgres, dockerizado, así que el camino garantizado-que-funciona es clonarlo y correr docker compose up (ver "Probalo" al final). Los snippets son fieles a la fuente; el repo es el artefacto runnable.

Por qué cookies, no `@auth_provider`

Fitz core trae @auth_provider + @authenticated — y son geniales para una API JSON donde el cliente manda Authorization: Bearer <token> y recibe un 401 si falla. Un panel de administración de browser quiere dos cosas distintas:

El browser no puede mandar un header Authorization en una navegación de página, ni en un handshake de WebSocket. Sí manda cookies, automático. Así que el token de sesión viaja en una cookie HttpOnly.
Una página no autenticada debería redirigir a /login, no tirarle un error JSON al usuario.

Así que la app se arma una sesión por cookie a mano — que en Fitz son unas 40 líneas, porque JWT y el hashing de contraseñas están integrados en el lenguaje.

Login — Argon2id + JWT → Set-Cookie

El login es un @post que toma credenciales JSON, verifica la contraseña contra el hash Argon2id guardado, firma un JWT, y lo devuelve como header Set-Cookie usando el built-in Response { ... }:

@post("/login")
async fn login_submit(creds: Credentials, cookie: Str?) -> Response {
  let user = match find_by_email(creds.email).await { ... }

  // hash.verify es Argon2id — built-in de Fitz, sin dep passlib/bcrypt.
  if (not hash.verify(creds.password, user.password_hash)) {
    return login_failed(...)
  }

  let claims = { "email": user.email, "role": user.role }
  let token = jwt.encode(claims, jwt_secret())     // HS256, built-in

  let set_cookie = session_cookie_name() + "=" + token
    + "; HttpOnly; Path=/; SameSite=Lax; Max-Age=86400"

  return Response {
    status: 200,
    headers: { "Set-Cookie": set_cookie },
  }
}

hash.verify (Argon2id) y jwt.encode (HS256) son built-ins de Fitz — sin pip install passlib python-jose, sin npm install bcrypt jsonwebtoken. El built-in Response { ... } es lo que deja a un handler setear un header custom en vez de devolver JSON plano.

(Un detalle: el login postea JSON con un fetch chiquito, no un <form> nativo, porque los handlers @post de Fitz toman un body JSON, no form-urlencoded. Una mejora futura del core puede aceptar form posts.)

El chequeo de sesión — cookie → JWT → usuario (vía el ORM)

Resolver el usuario logueado es: sacar el token del header Cookie crudo, decodificar el JWT, leer el claim email, y buscar el usuario en Postgres — por el ORM de Fitz:

async fn user_from_cookie(cookie: Str?) -> Result<User> {
  let token  = token_from_cookie(cookie)?          // parsea el header Cookie
  let claims = jwt.decode(token, jwt_secret())?    // verifica firma + expiración
  let email  = match claims.get("email") { ... }

  let conn = db.connect(db_url()).await?
  return User.where(fn(u) => u.email == email).first(conn).await
}

Cualquier falla — cookie ausente, firma mala, token expirado, usuario desconocido — sale como Err, que una página protegida convierte en redirect. Fijate en User.where(fn(u) => u.email == email).first(conn): ese es el ORM nativo de Fitz, una query tipada contra Postgres, en el mismo archivo que la auth.

Proteger una página

Un handler protegido lee la cookie con @header(name="cookie") y redirige a /login ante cualquier falla de auth — un 303 real, browser-correcto:

@header(name="cookie")
@get("/")
async fn dashboard(cookie: Str?) -> Response {
  let user = match user_from_cookie(cookie).await {
    Ok(u) => u,
    Err(_) => return redirect_to("/login"),   // 303 → /login
  }
  // ... renderiza el dashboard para `user` ...
}

Ese es todo el gate. Una request no autenticada a / recibe 303 → /login — exactamente lo que un browser espera, y lo que no podés expresar con un auth provider de JSON-401. /logout limpia la cookie (Max-Age=0) y redirige. Verifiqué el flujo entero end-to-end: GET / sin cookie → 303 /login; POST /login → Set-Cookie con el JWT HttpOnly; GET / con la cookie → el dashboard.

El shell responsive

Alrededor de cada página protegida hay un shell armado enteramente con la librería de UI empaquetada (AppShell / Sidebar / Topbar / Breadcrumbs / ThemeToggle):

Sidebar colapsable en desktop, drawer off-canvas en mobile — funciona hasta 320px.
Un switch de tema light / dark / auto, persistido por browser y aplicado antes del primer paint (un script inline chiquito lee la preferencia y setea el atributo de tema antes de que renderice el body — sin flash del tema equivocado).
Un switch de idioma 🌐 ES / EN (GET /lang/{code} setea una cookie de idioma y redirige de vuelta).

Todo está tematizado con design tokens --flv-* aliaseados a la paleta del admin, así que todo el panel — cada componente empaquetado — hereda el switch de tema gratis.

Probalo

git clone https://github.com/Thegreekman76/fitz-liveviews
cd fitz-liveviews/examples/admin
docker compose up --build          # Postgres + la app, un comando
# → http://localhost:3000/   login: admin@fitz.dev / admin1234

Qué viene en la serie

#5 — El DataGrid en vivo. La pieza central del flagship: una grilla de empleados con búsqueda, filtros, ordenamiento y paginación, re-consultando Postgres y diff-parcheando por WebSocket en cada tecla.

Dale una estrella al repo si una app real en un solo lenguaje es lo tuyo. Lo próximo: la grilla en vivo.

Benchmarkée el ORM Postgres nativo de mi lenguaje contra SQLAlchemy: ~8 más rápido en reads, 5.7 menos memoria — y dónde empata

Martin Palopoli — Wed, 12 Aug 2026 09:26:12 +0000

Parte 16 de la serie Fitz. Fitz es un lenguaje compilado donde HTTP, Postgres, JWT y WebSockets son parte de la sintaxis. Encadena con la Parte 9 (ORM tipado + migraciones). Hoy: dejo de agitar las manos sobre performance y lo mido de verdad.

La promesa que nadie debería creerse

Todo lenguaje que compila a binario nativo ama decir "cero overhead". Es lo más fácil de escribir en un README y lo más difícil de respaldar. Todo el pitch de Fitz es que HTTP + Postgres viven en el core del lenguaje — un driver Postgres en Rust puro compilado al binario, sin libpq, sin libpython, sin GIL. Eso debería hacerlo rápido. Pero "debería" no es un número.

Por eso el repo trae un benchmark reproducible. No un micro-loop sintético — dos boilerplates reales que cualquiera puede git clone y docker compose up:

Impl	Boilerplate	Stack
Fitz ORM	`api-postgres-fitz`	Driver Postgres wire puro + ORM nativo
Python	`api-postgres-python`	Fitz + `from python import` + SQLAlchemy 2.x + psycopg2

Mismo Postgres 16, misma red Docker, mismo host, los mismos tres endpoints con el mismo shape de JSON:

GET /users — lista de 50 filas
GET /users/{id} — un read por PK
POST /users — insert

Solo cambia el ORM/driver detrás. Si Fitz es más rápido, es el driver — nada más se movió.

Los números (v0.37.12, mediana de 3 corridas)

Hardware: Intel Core Ultra 7 155H (16 cores), 64 GB RAM, Windows 11 + Docker 29.2.1 (WSL2). 30s sostenidos a concurrencia 10, medido con oha. Mediana de 3 corridas (las corridas locales varían ±10% por thermals del CPU y estado del cache).

Cold start, imagen, memoria

Métrica	Fitz ORM	Python + SQLAlchemy	Ratio
Cold start (s)	0.34	0.31	~empate
Tamaño de imagen	134 MB	272 MB	2× más liviano
Memory peak (MB)	9.2	52.4	5.7× más eficiente

El número de memoria es el que hace mirar dos veces: 9.2 MB vs 52.4 MB bajo carga sostenida. No es un snapshot idle-en-frío — es el peak sirviendo miles de requests por segundo. Fitz carga un runtime tokio + axum + el driver, y nada más. SQLAlchemy arrastra un intérprete Python, la maquinaria de instancias por fila del ORM, y un connection pool custodiado por un threading.Lock.

Cold start es un empate hoy — y hay que ser honesto. Fitz booteaba en 0.14s, pero desde que empezó a linkear OpenTelemetry + tracing + metrics al binario HTTP, el cold start subió a ~0.34s, al lado de Python. (Es opt-out con @server(observability=false) si querés recuperar los 0.14s.)

`GET /users` — lista de 50 filas, 30s sostenidos, c=10

Métrica	Fitz ORM	Python + SQLAlchemy	Speedup
p50 latency (ms)	3.57	31.24	8.75×
p95 latency (ms)	5.76	56.75	9.85×
p99 latency (ms)	8.22	72.39	8.81×
Throughput (RPS)	2618	297	8.81×

`GET /users/{id}` — un read por PK, 30s sostenidos, c=10 ⭐

Métrica	Fitz ORM	Python + SQLAlchemy	Speedup
p50 latency (ms)	2.74	21.52	7.85×
p95 latency (ms)	4.51	44.07	9.77×
p99 latency (ms)	6.44	61.50	9.55×
Throughput (RPS)	3377	411	8.22×

Los read workloads — la forma típica de una API REST — quedan alrededor de ~8× el throughput con ~8× menos latencia, y la cola (p95/p99) ensancha la diferencia en vez de cerrarla. La cola de Fitz es apretada porque no hay pausa de GC ni contención de GIL serializando el manejo de requests.

Por qué Fitz gana en reads

El driver Postgres en Rust puro está compilado directo al binario nativo. Un request hace: parsear el frame HTTP (axum) → armar SQL parametrizado (sin malabares de strings con muchas allocations) → un round trip a Postgres → deserializar filas a structs tipados → serializar JSON. Ese es todo el hot path, y su overhead de runtime es casi nada.

SQLAlchemy suma capas en cada request: compilación de SQL del lado de Python, un connection pool coordinado con un threading.Lock, y convertir cada fila del resultado en una instancia del ORM con __init__ por fila — todo serializado por el GIL. Nada de eso es lento aislado; es simplemente trabajo que Fitz no hace.

Por qué Python no es ridículamente lento (la parte honesta)

SQLAlchemy 2.x está genuinamente bien optimizado, y el GIL solo bloquea Python puro — no la ejecución de SQL, no el I/O. Para un workload DB-bound, el verdadero cuello de botella suele ser Postgres, no el lenguaje encima. Por eso exactamente los writes empatan:

`POST /users` — 100 sequential, body único por request

Métrica	Fitz ORM	Python + SQLAlchemy	Speedup
p50 latency (ms)	174.69	190.23	1.09×
p95 latency (ms)	243.97	271.75	1.11×
Throughput (RPS)	3.28	2.98	1.10×

Eso es un empate técnico — y tengo que ser directo con el por qué. Esto no mide el throughput de escritura del server; mide el cliente. El bench hace un loop curl sequential con un email único por request, y en Git Bash sobre Windows cada subshell arrastra ~1s de overhead. Que la latencia per-request sea ~igual te dice que el cuello de botella es el write durable de Postgres, no el server. Medir throughput de POST honesto necesita k6 o wrk+lua con randomización de bodies — eso es una extensión futura, no un número que voy a maquillar.

El bug que alguna vez hizo a Fitz 30% MÁS LENTO que Python

La parte más instructiva de toda esta historia: Fitz alguna vez perdió.

En una versión anterior, GET /users/{id} tenía un p50 de 43.70 ms — como 30% más lento que SQLAlchemy sobre exactamente la misma query. Para un "binario nativo con driver puro", eso fue humillante y, honestamente, un gran empujón para profilear de verdad en vez de asumir.

El culpable era el algoritmo de Nagle. El driver mandaba los cinco mensajes del Extended Query Protocol de Postgres (Parse / Bind / Describe / Execute / Sync) como cinco write().await separados. Nagle coalescía los paquetes chicos y esperaba un delayed-ACK — sumando ~40 ms a cada query parametrizada. El fix fueron dos líneas en el driver:

set_nodelay(true) en el TcpStream (deshabilita Nagle entre cliente y server).
Batchear los cinco mensajes del protocolo en un solo write_all.

Resultado: GET /users/{id} pasó de 43.70 ms → ~2.7 ms p50 — una mejora de ~16×, dando vuelta la historia de "Fitz pierde" a "Fitz gana ~8×". Estable ahí desde entonces.

La lección es exactamente para lo que sirven los benchmarks: no existen para que un gráfico se vea lindo, existen para cazarte siendo lento. Sin un bench reproducible, esos 40 ms seguirían ahí.

Reproducilo vos mismo

cd benchmarks/orm-vs-sqlalchemy
bash run.sh

El script levanta cada boilerplate con docker compose up -d --build, espera el primer 200, seedea users, bencha cada endpoint con oha, muestrea memoria via docker stats, y escribe un summary.md. Para números publicables, corrélo tres veces y tomá la mediana — los ratios headline (5.7× memoria, ~8× reads) son estables entre corridas; solo se mueven los decimales.

Lo que no estoy afirmando

Reads, no writes. La ventaja es en workloads read-heavy. El throughput de POST es un artefacto client-side de este bench, no una medición del server.
Mediana, no best-case. Los números absolutos se mueven con la carga de la máquina. Los ratios son lo que se sostiene.
Todavía sin queries con JOINs pesados. Eager loading, agregaciones y window functions tienen perfiles distintos. Hay un bench mixed-workload separado (Fitz vs Python vs Node) para el panorama más completo.

Si querés las tripas del driver — wire protocol v3.0, SCRAM-SHA-256, el connection pool — están todas en src/db.rs, un solo archivo, sin libpq. Ese es todo el punto: lo que lo hace rápido es algo que podés leer.

Próximo en la serie: más del stack que está incorporado en el lenguaje, y los modos de falla honestos que sigo encontrando construyendo productos reales con él.

I benchmarked my language's native Postgres ORM against SQLAlchemy: ~8 faster reads, 5.7 less memory — and where it ties

Martin Palopoli — Wed, 12 Aug 2026 09:25:05 +0000

Part 16 of the Fitz series. Fitz is a compiled language where HTTP, Postgres, JWT and WebSockets are part of the syntax. Follows Part 9 (typed ORM + migrations). Today: I stop hand-waving about performance and actually measure it.

The claim nobody should take on faith

Every language that compiles to a native binary loves to say "zero overhead." It's the easiest thing to write in a README and the hardest thing to back up. Fitz's whole pitch is that HTTP + Postgres live in the core of the language — a pure-Rust Postgres driver compiled into the binary, no libpq, no libpython, no GIL. That should make it fast. But "should" isn't a number.

So the repo ships a reproducible benchmark. Not a synthetic micro-loop — two actual boilerplates that any user can git clone and docker compose up:

Impl	Boilerplate	Stack
Fitz ORM	`api-postgres-fitz`	Pure Postgres wire driver + native ORM
Python	`api-postgres-python`	Fitz + `from python import` + SQLAlchemy 2.x + psycopg2

Same Postgres 16, same Docker network, same host, the same three endpoints with the same JSON shape:

GET /users — list of 50 rows
GET /users/{id} — single read by PK
POST /users — insert

Only the ORM/driver behind them changes. If Fitz is faster, it's the driver — nothing else moved.

The numbers (v0.37.12, median of 3 runs)

Hardware: Intel Core Ultra 7 155H (16 cores), 64 GB RAM, Windows 11 + Docker 29.2.1 (WSL2). Sustained 30s at concurrency 10, measured with oha. Median of 3 runs (local runs swing ±10% with CPU thermals and cache state).

Cold start, image, memory

Metric	Fitz ORM	Python + SQLAlchemy	Ratio
Cold start (s)	0.34	0.31	~tie
Image size	134 MB	272 MB	2× leaner
Memory peak (MB)	9.2	52.4	5.7× more efficient

The memory number is the one that makes people do a double take: 9.2 MB vs 52.4 MB under sustained load. That's not a warm-idle snapshot — it's the peak while serving thousands of requests per second. Fitz carries a tokio runtime + axum + the driver, and that's it. SQLAlchemy drags a Python interpreter, the ORM's per-row instance machinery, and a connection pool guarded by threading.Lock.

Cold start is a tie now — worth being honest about. Fitz used to boot in 0.14s, but since it started linking OpenTelemetry + tracing + metrics into the HTTP binary, cold start rose to ~0.34s, right next to Python. (It's opt-out with @server(observability=false) if you want the 0.14s back.)

`GET /users` — list of 50 rows, 30s sustained, c=10

Metric	Fitz ORM	Python + SQLAlchemy	Speedup
p50 latency (ms)	3.57	31.24	8.75×
p95 latency (ms)	5.76	56.75	9.85×
p99 latency (ms)	8.22	72.39	8.81×
Throughput (RPS)	2618	297	8.81×

`GET /users/{id}` — single read by PK, 30s sustained, c=10 ⭐

Metric	Fitz ORM	Python + SQLAlchemy	Speedup
p50 latency (ms)	2.74	21.52	7.85×
p95 latency (ms)	4.51	44.07	9.77×
p99 latency (ms)	6.44	61.50	9.55×
Throughput (RPS)	3377	411	8.22×

Read workloads — the typical shape of a REST API — land around ~8× the throughput at ~8× lower latency, and the tail (p95/p99) actually widens the gap rather than closing it. Fitz's tail is tight because there's no GC pause and no GIL contention serializing request handling.

Why Fitz wins the reads

The pure-Rust Postgres driver is compiled straight into the native binary. A request does: parse the HTTP frame (axum) → build parameterized SQL (no allocation-heavy string juggling) → one round trip to Postgres → deserialize rows into typed structs → serialize JSON. That's the whole hot path, and its runtime overhead is close to nothing.

SQLAlchemy adds layers on every request: SQL compilation on the Python side, a connection pool coordinated with a threading.Lock, and converting each result row into an ORM instance with __init__ per row — all serialized by the GIL. None of that is slow in isolation; it's just work Fitz simply doesn't do.

Why Python isn't ridiculously slow (the honest part)

SQLAlchemy 2.x is genuinely well-optimized, and the GIL only blocks pure Python — not SQL execution, not I/O. For a DB-bound workload, the real bottleneck is usually Postgres, not the language on top. That's exactly why the writes tie:

`POST /users` — 100 sequential, unique body per request

Metric	Fitz ORM	Python + SQLAlchemy	Speedup
p50 latency (ms)	174.69	190.23	1.09×
p95 latency (ms)	243.97	271.75	1.11×
Throughput (RPS)	3.28	2.98	1.10×

That's a technical tie — and I have to be upfront about why. This isn't measuring server write throughput; it's measuring the client. The bench does a sequential curl loop with a unique email per request, and in Git Bash on Windows each subshell carries ~1s of overhead. The per-request latency being ~equal tells you the bottleneck is Postgres' durable write, not the server. Measuring honest POST throughput needs k6 or wrk+lua with body randomization — that's a future extension, not a number I'll dress up.

The bug that once made Fitz 30% SLOWER than Python

The most instructive part of this whole story: Fitz used to lose.

In an earlier version, GET /users/{id} had a p50 of 43.70 ms — about 30% slower than SQLAlchemy on the exact same query. For a "native binary with a pure driver," that was humiliating and, frankly, a great forcing function to actually profile instead of assume.

The culprit was Nagle's algorithm. The driver sent the five messages of Postgres' Extended Query Protocol (Parse / Bind / Describe / Execute / Sync) as five separate write().await calls. Nagle coalesced small packets and waited for a delayed-ACK — piling ~40 ms onto every parameterized query. The fix was two lines in the driver:

set_nodelay(true) on the TcpStream (disable Nagle between client and server).
Batch all five protocol messages into a single write_all.

Result: GET /users/{id} went from 43.70 ms → ~2.7 ms p50 — a ~16× improvement, flipping the story from "Fitz loses" to "Fitz wins ~8×." It's been stable there ever since.

The lesson is the one benchmarks are actually for: they don't exist to make a graph look good, they exist to catch you being slow. Without a reproducible bench, that 40 ms would still be there.

Reproduce it yourself

cd benchmarks/orm-vs-sqlalchemy
bash run.sh

The script spins up each boilerplate with docker compose up -d --build, waits for the first 200, seeds users, benches each endpoint with oha, samples memory via docker stats, and writes a summary.md. For publishable numbers, run it three times and take the median — the headline ratios (5.7× memory, ~8× reads) are stable across runs; only the decimals move.

What I'm not claiming

Reads, not writes. The win is on read-heavy workloads. POST throughput is a client-side artifact of this bench, not a server measurement.
Median, not best-case. Absolute numbers shift with the machine's load. The ratios are what hold.
No JOIN-heavy queries yet. Eager loading, aggregations, and window functions have different profiles. There's a separate mixed-workload bench (Fitz vs Python vs Node) for the fuller picture.

If you want the raw driver internals — wire protocol v3.0, SCRAM-SHA-256, the connection pool — they're all in src/db.rs, one file, no libpq. That's the whole point: the thing that makes it fast is a thing you can read.

Next up in the series: more of the stack that's built into the language, and the honest failure modes I keep finding while building real products with it.

Forms, payloads, and live inputs in Fitz LiveViews

Martin Palopoli — Tue, 11 Aug 2026 09:51:12 +0000

TL;DR — Events in Fitz LiveViews carry data three ways: a click payload (data-flv-value-*) tags a button with the value it should send; a form submit (data-flv-submit) reads the form's named inputs; and a live value (@input / @change) delivers a control's current value in payload["value"]. All three land in the same place — a payload map your handler reads. This post builds a live name list (add / remove / count) that runs both server-rendered and as WebAssembly. (Part 3 of the FitzLiveViews series.)

Parts 1 and 2 covered the pitch and the counter. A counter only reads +1/-1 — no data flows in. Real UIs take input: text, selections, form fields. Here's how that data reaches your handlers.

The `payload`

Every event handler has a payload in scope — a Map<Str, Str>. The three mechanisms below all fill it; your handler reads it with payload["key"] (guard with payload.has("key")):

1. Click payload — a button that carries a value

Tag any element with data-flv-value-<key>="{expr}", and when a data-flv-click on it (or an ancestor) fires, that value rides along:

<button data-flv-click="remove" data-flv-value-item="{it}">×</button>

event remove() {
  if (payload.has("item")) {
    let target = payload["item"]
    names = names.filter(fn(it) => it != target)
  }
}

The delete button knows which row it is because the row's value is stamped on it. No IDs threaded through a callback, no closure capture.

2. Form submit — the whole form at once

data-flv-submit="handler" on a <form> reads each named input into the payload on submit; data-flv-clear resets a field afterward:

<form data-flv-submit="add">
  <input name="item" placeholder="Add a name" data-flv-clear />
  <button type="submit">Add</button>
</form>

event add() {
  if (payload.has("item")) {
    let n = payload["item"]
    if (n != "") { names.push(n) }
  }
}

payload["item"] is the input's value at submit time. No preventDefault, no FormData, no fetch.

3. Live value — `@input` / `@change`

For a control that reports as you type or on selection, @input (every keystroke) and @change (on blur/selection) deliver the current value in payload["value"]:

<input @input="on_name" value="{name}" />
<select @change="on_color"> … </select>

event on_name() { name = payload["value"] }

The same payload["value"] covers <input>, <select>, and <textarea>. On the server-rendered target this is the classic data-flv-change attribute; on the client-WASM target it's the @input / @change decorator — same payload, same handler, so one .fitzv serves both.

Putting it together — a live name list

component NameList {
  state {
    names: List<Str> = ["Ada", "Grace", "Margaret"]
  }

  event add() {
    if (payload.has("item")) {
      let n = payload["item"]
      if (n != "") { names.push(n) }
    }
  }

  event remove() {
    if (payload.has("item")) {
      let target = payload["item"]
      names = names.filter(fn(it) => it != target)
    }
  }

  <template>
    <div class="names">
      <form data-flv-submit="add">
        <input name="item" placeholder="Add a name" data-flv-clear />
        <button type="submit">Add</button>
      </form>
      <ul>
        {#for it in names}
          <li>{it} <button data-flv-click="remove" data-flv-value-item="{it}">×</button></li>
        {/for}
      </ul>
      <p>{names.len()} total</p>
    </div>
  </template>
}

{#for it in names} iterates; {it} interpolates each item; the remove button stamps its own value. Add a name, remove a row, watch the count — no client code, no API.

Wire it into a main.fitz (the same shape as the counter in part 2) and it runs:

from fitz_liveviews import Html, html, live_layout, html_response,
  LiveFrame, diff_html, component, dispatch_component_events, flv_register
from NameList import NameList, NameList_render, NameList_add, NameList_remove

@get("/")
fn page() -> Response {
  return html_response(live_layout("/live/names", "names-app",
    component("NameList", "root")))
}

@ws("/live/names")
async fn socket(ws: WsConn<LiveFrame>) {
  let last = component("NameList", "root").raw
  loop {
    let frame = ws.recv()?
    let _ = dispatch_component_events(frame)
    let new_html = component("NameList", "root").raw
    ws.send(LiveFrame { html: new_html, patches: diff_html(last, new_html) })?
    last = new_html
  }
}

@server(3000) fn main() => 0

fitz run, open http://localhost:3000, add and remove names. (I ran exactly this — the page renders the seeded list, the count, and the wired form/buttons.) The client-WASM build of the same list is running in the live gallery — add/remove/count entirely in your browser, offline.

Two honest caveats

Live text inputs re-mount. The current rendering model is dirty-flag + naive re-render: a state change rebuilds the component's DOM. For a <select> @change that's invisible; for a live text <input> @input, the field re-mounts each keystroke — the value re-binds via value="{name}", but the caret jumps to the end. Fine-grained reactivity (patch in place) is the next rendering-model step, and it's what fixes this. The value always reaches the handler reliably; that's what @input guarantees today.
String methods on WASM — now supported. A case-insensitive filter (names.filter(fn(x) => q == "" or x.lower().contains(q.lower()))) used to be server-rendered only; as of Fitz core v0.29.8 the string methods (.lower / .contains / …) and logical and/or compile on the client-WASM target too, so the filter runs offline. The only remaining wrinkle is the caret caveat above for the filter box itself while you type.

What's next in this series

#4+ — Building the flagship. A complete admin panel in Fitz + Fitz LiveViews: cookie-based auth (Argon2id + JWT), live DataGrids querying Postgres over WebSockets, the packaged UI library, i18n, and a one-command Docker setup.

If typed events without a client framework sound good, star the repo. Next: a real app.

Forms, payloads e inputs en vivo en Fitz LiveViews

Martin Palopoli — Tue, 11 Aug 2026 09:49:07 +0000

TL;DR — Los eventos en Fitz LiveViews llevan data de tres formas: un click payload (data-flv-value-*) marca un botón con el valor que tiene que mandar; un form submit (data-flv-submit) lee los inputs con nombre del form; y un valor en vivo (@input / @change) entrega el valor actual de un control en payload["value"]. Las tres caen en el mismo lado — un mapa payload que tu handler lee. Este post construye una lista de nombres en vivo (agregar / quitar / contar) que corre server-rendered y como WebAssembly. (Parte 3 de la serie FitzLiveViews.)

Las partes 1 y 2 cubrieron el pitch y el counter. Un counter solo lee +1/-1 — no entra data. Las UIs reales toman input: texto, selecciones, campos de formulario. Acá está cómo esa data llega a tus handlers.

El `payload`

Cada handler de evento tiene un payload en scope — un Map<Str, Str>. Los tres mecanismos de abajo lo llenan; tu handler lo lee con payload["clave"] (guardá con payload.has("clave")):

1. Click payload — un botón que lleva un valor

Marcá cualquier elemento con data-flv-value-<clave>="{expr}", y cuando un data-flv-click sobre él (o un ancestro) dispara, ese valor viaja:

<button data-flv-click="remove" data-flv-value-item="{it}">×</button>

event remove() {
  if (payload.has("item")) {
    let target = payload["item"]
    names = names.filter(fn(it) => it != target)
  }
}

El botón de borrar sabe qué fila es porque el valor de la fila está estampado en él. Sin IDs pasados por un callback, sin captura de closure.

2. Form submit — el form entero de una

data-flv-submit="handler" en un <form> lee cada input con nombre al payload en el submit; data-flv-clear limpia el campo después:

<form data-flv-submit="add">
  <input name="item" placeholder="Agregar un nombre" data-flv-clear />
  <button type="submit">Agregar</button>
</form>

event add() {
  if (payload.has("item")) {
    let n = payload["item"]
    if (n != "") { names.push(n) }
  }
}

payload["item"] es el valor del input al momento del submit. Sin preventDefault, sin FormData, sin fetch.

3. Valor en vivo — `@input` / `@change`

Para un control que reporta mientras tipeás o al seleccionar, @input (cada tecla) y @change (al blur/selección) entregan el valor actual en payload["value"]:

<input @input="on_name" value="{name}" />
<select @change="on_color"> … </select>

event on_name() { name = payload["value"] }

El mismo payload["value"] cubre <input>, <select> y <textarea>. En el target server-rendered esto es el atributo clásico data-flv-change; en el target client-WASM es el decorador @input / @change — mismo payload, mismo handler, así que un .fitzv sirve a los dos.

Todo junto — una lista de nombres en vivo

component NameList {
  state {
    names: List<Str> = ["Ada", "Grace", "Margaret"]
  }

  event add() {
    if (payload.has("item")) {
      let n = payload["item"]
      if (n != "") { names.push(n) }
    }
  }

  event remove() {
    if (payload.has("item")) {
      let target = payload["item"]
      names = names.filter(fn(it) => it != target)
    }
  }

  <template>
    <div class="names">
      <form data-flv-submit="add">
        <input name="item" placeholder="Agregar un nombre" data-flv-clear />
        <button type="submit">Agregar</button>
      </form>
      <ul>
        {#for it in names}
          <li>{it} <button data-flv-click="remove" data-flv-value-item="{it}">×</button></li>
        {/for}
      </ul>
      <p>{names.len()} total</p>
    </div>
  </template>
}

{#for it in names} itera; {it} interpola cada ítem; el botón de borrar estampa su propio valor. Agregá un nombre, quitá una fila, mirá el contador — sin código de cliente, sin API.

Cablealo a un main.fitz (la misma forma que el counter de la parte 2) y corre:

from fitz_liveviews import Html, html, live_layout, html_response,
  LiveFrame, diff_html, component, dispatch_component_events, flv_register
from NameList import NameList, NameList_render, NameList_add, NameList_remove

@get("/")
fn page() -> Response {
  return html_response(live_layout("/live/names", "names-app",
    component("NameList", "root")))
}

@ws("/live/names")
async fn socket(ws: WsConn<LiveFrame>) {
  let last = component("NameList", "root").raw
  loop {
    let frame = ws.recv()?
    let _ = dispatch_component_events(frame)
    let new_html = component("NameList", "root").raw
    ws.send(LiveFrame { html: new_html, patches: diff_html(last, new_html) })?
    last = new_html
  }
}

@server(3000) fn main() => 0

fitz run, abrís http://localhost:3000, agregás y quitás nombres. (Corrí exactamente esto — la página renderiza la lista sembrada, el contador, y el form/botones cableados.) El build client-WASM de la misma lista está corriendo en la galería en vivo — agregar/quitar/contar entero en tu browser, offline.

Dos caveats honestos

Los inputs de texto en vivo se re-montan. El modelo de render actual es dirty-flag + naive re-render: un cambio de estado reconstruye el DOM del componente. Para un <select> @change es invisible; para un <input> @input en vivo, el campo se re-monta en cada tecla — el valor se re-bindea con value="{name}", pero el caret salta al final. La reactividad fine-grained (patch in-place) es el próximo paso del modelo de render, y es lo que arregla esto. El valor siempre llega al handler de forma confiable; eso es lo que @input garantiza hoy.
Métodos de string en WASM — ahora sí. Un filtro case-insensitive (names.filter(fn(x) => q == "" or x.lower().contains(q.lower()))) antes era solo server-rendered; desde Fitz core v0.29.8 los métodos de string (.lower / .contains / …) y el and/or lógico compilan también en el target client-WASM, así que el filtro corre offline. Lo único que queda es el caret caveat de arriba para la caja del filtro mientras tipeás.

Qué viene en la serie

#4+ — Construyendo el flagship. Un panel de administración completo en Fitz + Fitz LiveViews: auth por cookie (Argon2id + JWT), DataGrids en vivo consultando Postgres por WebSockets, la librería de UI empaquetada, i18n, y un setup Docker de un comando.

Si eventos tipados sin framework de cliente te suena bien, dale una estrella al repo. Lo próximo: una app real.

A native frontend for a compiled language: .fitzv components that compile to WebAssembly

Martin Palopoli — Tue, 11 Aug 2026 09:47:12 +0000

Part 14 of the Fitz series. Part 13 showed the dev loop for .fitzv → WASM; this part is what a .fitzv component actually is, and how a language that emits native binaries also emits a frontend — to WebAssembly, without adopting a JavaScript framework.

The problem: a server language needs a frontend, without importing an ecosystem

Fitz compiles to a native binary and has HTTP/async/Postgres/JWT in the syntax. But a backend eventually needs a UI, and the usual answer is: bolt on the JavaScript ecosystem — a framework (React/Vue/Svelte), a bundler, a node_modules, a second toolchain, and a second definition of every type that crosses the wire.

Fitz's answer is a component format the same compiler understands, that compiles to WebAssembly — no JS framework, no npm.

A component

A .fitzv is a single file: state, events, a <template>, optional scoped styles — the Vue/Svelte shape, but it's Fitz all the way down:

component Counter {
  state {
    count: Int = 0
  }

  event inc() { count = count + 1 }
  event dec() { count = count - 1 }

  <template>
    <div class="counter">
      <button @click="dec">-</button>
      <span class="n">{count}</span>
      <button @click="inc">+</button>
    </div>
  </template>

  <style scoped>
    .counter { display: flex; gap: 12px; }
    .n { font-variant-numeric: tabular-nums; }
  </style>
}

{count} interpolates state. @click wires an event. <style scoped> is scoped to this component (via a hash on the class names). Build it:

fitz build --bin web --target wasm-client   # → target/wasm/web/{web.js, web_bg.wasm}

That's the whole toolchain. No package.json, no bundler config.

What the compiler emits

There's no framework runtime in the bundle. The emitter lowers the component directly to Rust over wasm-bindgen + web-sys: a struct with the state fields, a mount() that builds the DOM with create_element/append_child, event closures that mutate state, and a render() that re-paints the component's subtree on a state change. It's a self-contained WASM module — the counter above is 26 KB raw / 11.4 KB gzipped.

The template is a real DSL: interpolation ({user.name.upper()} — arbitrary Fitz expressions over state), directives ({#if} / {#for}), events (@click / @input), and composition:

<template>
  <ul>
    {#for todo in todos}
      <TodoRow label="{todo.title}" @remove="drop" />
    {/for}
  </ul>
</template>

<Child prop="v" /> passes props down; @remove="drop" bubbles an event up with its payload; <slot> lets a parent inject content. Composition works across files, so a component library is just imports.

The type is the same type

This is the part a bolted-on framework can't give you. The type your server defines is the exact one your component uses — imported from the same .fitz module:

// models.fitz
type Todo {
  id: Int
  title: Str
  done: Bool
}

// App.fitzv
from models import Todo
// ... a List<Todo> in state, {todo.title} in the template

The server compiles Todo into a native struct; the component compiles it into a WASM struct; there's one definition. No types.ts that drifts from the backend, no codegen step to keep them in sync — by construction they can't diverge.

Why this is different

Component models aren't new — the point is what compiles them:

React / Vue / Svelte are excellent, but they're JavaScript: a framework runtime shipped to the browser, a bundler, an npm tree, and a separate type story for the API boundary. .fitzv compiles to WASM with none of that.
Elm is a lovely own-language frontend, but it compiles to JavaScript and lives only in the browser — it isn't the same language as your compiled backend.
Rust WASM frameworks (Dioxus, Leptos) compile to WASM too, but you're adopting a framework, its macro DSL, and its toolchain on top of Rust. In Fitz the component is the language, and the same fitz binary builds it.

One language, one compiler, one type definition — emitting a native binary for the server and a WASM bundle for the browser.

The honest edges (MVP)

Re-render is naive: a state change re-paints the component's subtree, not a fine-grained signal graph. It's fast enough for the common case; fine-grained reactivity is a future slice.
The template supports a growing envelope of constructs (interpolation, {#if}/{#for}, events, composition, slots, scoped styles); genuinely exotic patterns fall outside it for now and the compiler tells you where.
The client is WASM-first; there's no JS-vanilla target — a deliberate choice recorded when the counter came in under the 40 KB bundle gate.

That's the frontend as a first-class part of the language: components you write in Fitz, compiled to WebAssembly, sharing types with a backend compiled to native code. Next up: how a function on that backend becomes callable from the component as if it were local — @rpc.

Fitz is a compiled language with gradual typing and HTTP/async/DB as first-class citizens, compiling to native binary via Rust. Its frontend is .fitzv single-file components compiled to WebAssembly — no framework, no npm. Open source.

Un frontend nativo para un lenguaje compilado: componentes .fitzv que compilan a WebAssembly

Martin Palopoli — Tue, 11 Aug 2026 09:46:26 +0000

Parte 14 de la serie Fitz. La Parte 13 mostró el dev loop para .fitzv → WASM; esta parte es qué es realmente un componente .fitzv, y cómo un lenguaje que emite binarios nativos también emite un frontend — a WebAssembly, sin adoptar un framework de JavaScript.

El problema: un lenguaje de servidor necesita frontend, sin importar un ecosistema

Fitz compila a binario nativo y tiene HTTP/async/Postgres/JWT en la sintaxis. Pero un backend tarde o temprano necesita una UI, y la respuesta habitual es: pegar el ecosistema JavaScript — un framework (React/Vue/Svelte), un bundler, un node_modules, un segundo toolchain, y una segunda definición de cada tipo que cruza el cable.

La respuesta de Fitz es un formato de componentes que el mismo compilador entiende, que compila a WebAssembly — sin framework JS, sin npm.

Un componente

Un .fitzv es un solo archivo: state, events, un <template>, estilos scoped opcionales — la forma Vue/Svelte, pero es Fitz de punta a punta:

component Counter {
  state {
    count: Int = 0
  }

  event inc() { count = count + 1 }
  event dec() { count = count - 1 }

  <template>
    <div class="counter">
      <button @click="dec">-</button>
      <span class="n">{count}</span>
      <button @click="inc">+</button>
    </div>
  </template>

  <style scoped>
    .counter { display: flex; gap: 12px; }
    .n { font-variant-numeric: tabular-nums; }
  </style>
}

{count} interpola el state. @click cablea un evento. <style scoped> queda scopeado a este componente (vía un hash en los nombres de clase). Buildealo:

fitz build --bin web --target wasm-client   # → target/wasm/web/{web.js, web_bg.wasm}

Ese es el toolchain entero. Sin package.json, sin config de bundler.

Qué emite el compilador

No hay runtime de framework en el bundle. El emisor baja el componente directo a Rust sobre wasm-bindgen + web-sys: un struct con los campos de state, un mount() que construye el DOM con create_element/append_child, closures de evento que mutan el state, y un render() que re-pinta el subtree del componente ante un cambio de state. Es un módulo WASM autocontenido — el contador de arriba pesa 26 KB raw / 11.4 KB gzipped.

El template es un DSL de verdad: interpolación ({user.name.upper()} — expresiones Fitz arbitrarias sobre el state), directivas ({#if} / {#for}), eventos (@click / @input), y composición:

<template>
  <ul>
    {#for todo in todos}
      <TodoRow label="{todo.title}" @remove="drop" />
    {/for}
  </ul>
</template>

<Child prop="v" /> pasa props hacia abajo; @remove="drop" burbujea un evento hacia arriba con su payload; <slot> deja que un padre inyecte contenido. La composición funciona entre archivos, así que una librería de componentes es solo imports.

El tipo es el mismo tipo

Esta es la parte que un framework pegado por encima no te puede dar. El type que define tu server es exactamente el que usa tu componente — importado del mismo módulo .fitz:

// models.fitz
type Todo {
  id: Int
  title: Str
  done: Bool
}

// App.fitzv
from models import Todo
// ... un List<Todo> en el state, {todo.title} en el template

El server compila Todo a un struct nativo; el componente lo compila a un struct WASM; hay una sola definición. Sin un types.ts que se desincroniza del backend, sin un paso de codegen para mantenerlos en sync — por construcción no pueden divergir.

Por qué es distinto

Los modelos de componentes no son nuevos — la cuestión es qué los compila:

React / Vue / Svelte son excelentes, pero son JavaScript: un runtime de framework mandado al browser, un bundler, un árbol npm, y una historia de tipos aparte para el borde de la API. .fitzv compila a WASM sin nada de eso.
Elm es un hermoso frontend de lenguaje propio, pero compila a JavaScript y vive solo en el browser — no es el mismo lenguaje que tu backend compilado.
Frameworks WASM de Rust (Dioxus, Leptos) compilan a WASM también, pero estás adoptando un framework, su DSL de macros, y su toolchain sobre Rust. En Fitz el componente es el lenguaje, y el mismo binario fitz lo buildea.

Un lenguaje, un compilador, una definición de tipo — emitiendo un binario nativo para el server y un bundle WASM para el browser.

Los bordes honestos (MVP)

El re-render es naive: un cambio de state re-pinta el subtree del componente, no un grafo de señales fine-grained. Alcanza para el caso común; la reactividad fine-grained es un slice futuro.
El template soporta un envelope creciente de constructos (interpolación, {#if}/{#for}, eventos, composición, slots, estilos scoped); los patrones genuinamente exóticos quedan afuera por ahora y el compilador te dice dónde.
El cliente es WASM-first; no hay target JS-vanilla — una decisión deliberada registrada cuando el contador entró bajo el gate de bundle de 40 KB.

Ese es el frontend como parte de primera clase del lenguaje: componentes que escribís en Fitz, compilados a WebAssembly, compartiendo tipos con un backend compilado a código nativo. Lo que sigue: cómo una función de ese backend se vuelve llamable desde el componente como si fuera local — @rpc.

Fitz es un lenguaje compilado con tipado gradual, HTTP/async/DB como ciudadanos de primera clase, que compila a binario nativo vía Rust. Su frontend son componentes single-file .fitzv compilados a WebAssembly — sin framework, sin npm. Código abierto.

DEV Community: Martin Palopoli

Building the flagship (3): a packaged UI library, i18n, and one-command Docker

The library was mined from this app

One theme switch, everywhere

i18n without a library

One command to run it

The whole stack, one language

That's the series (for now)

Construyendo el flagship (3): una librería de UI empaquetada, i18n, y Docker de un comando

La librería se extrajo de esta app

Un switch de tema, en todos lados

i18n sin librería

Un comando para correrlo

Todo el stack, un lenguaje

Esa es la serie (por ahora)

Building the flagship (2): a live DataGrid that queries Postgres on every keystroke

The shape

Every dimension is real SQL

What the browser does

Per-connection, for free

Try it

What's next in this series

Construyendo el flagship (2): un DataGrid en vivo que consulta Postgres en cada tecla

La forma

Cada dimensión es SQL real

Qué hace el browser

Per-connection, gratis

Probalo

Qué viene en la serie

Building the flagship (1): browser-correct cookie auth in Fitz

Why cookies, not @auth_provider

Login — Argon2id + JWT → Set-Cookie

The session check — cookie → JWT → user (via the ORM)

Protecting a page

The responsive shell

Try it

What's next in this series

Construyendo el flagship (1): auth por cookie browser-correcta en Fitz

Por qué cookies, no @auth_provider

Login — Argon2id + JWT → Set-Cookie

El chequeo de sesión — cookie → JWT → usuario (vía el ORM)

Proteger una página

El shell responsive

Probalo

Qué viene en la serie

Benchmarkée el ORM Postgres nativo de mi lenguaje contra SQLAlchemy: ~8 más rápido en reads, 5.7 menos memoria — y dónde empata

La promesa que nadie debería creerse

Los números (v0.37.12, mediana de 3 corridas)

Cold start, imagen, memoria

GET /users — lista de 50 filas, 30s sostenidos, c=10

GET /users/{id} — un read por PK, 30s sostenidos, c=10 ⭐

Por qué Fitz gana en reads

Por qué Python no es ridículamente lento (la parte honesta)

POST /users — 100 sequential, body único por request

El bug que alguna vez hizo a Fitz 30% MÁS LENTO que Python

Reproducilo vos mismo

Lo que no estoy afirmando

I benchmarked my language's native Postgres ORM against SQLAlchemy: ~8 faster reads, 5.7 less memory — and where it ties

The claim nobody should take on faith

The numbers (v0.37.12, median of 3 runs)

Cold start, image, memory

GET /users — list of 50 rows, 30s sustained, c=10

GET /users/{id} — single read by PK, 30s sustained, c=10 ⭐

Why Fitz wins the reads

Why Python isn't ridiculously slow (the honest part)

POST /users — 100 sequential, unique body per request

The bug that once made Fitz 30% SLOWER than Python

Reproduce it yourself

What I'm not claiming

Forms, payloads, and live inputs in Fitz LiveViews

The payload

1. Click payload — a button that carries a value

2. Form submit — the whole form at once

3. Live value — @input / @change

Putting it together — a live name list

Two honest caveats

What's next in this series

Forms, payloads e inputs en vivo en Fitz LiveViews

El payload

1. Click payload — un botón que lleva un valor

Why cookies, not `@auth_provider`

Por qué cookies, no `@auth_provider`

`GET /users` — lista de 50 filas, 30s sostenidos, c=10

`GET /users/{id}` — un read por PK, 30s sostenidos, c=10 ⭐

`POST /users` — 100 sequential, body único por request

`GET /users` — list of 50 rows, 30s sustained, c=10

`GET /users/{id}` — single read by PK, 30s sustained, c=10 ⭐

`POST /users` — 100 sequential, unique body per request

The `payload`

3. Live value — `@input` / `@change`

El `payload`

3. Valor en vivo — `@input` / `@change`