DEV Community: Martin Palopoli

Isomorphic hydration in Fitz: first paint on the server, then WASM adopts the DOM

Martin Palopoli — Thu, 17 Sep 2026 09:20:53 +0000

TL;DR — Mark a component hydrate and the same .fitzv does two
jobs: the server renders it to HTML for a fast first paint (SEO,
works-without-JS), and on boot the client-WASM runtime adopts that
exact DOM — restoring the serialized state from an embedded
<script>, walking the existing nodes, and wiring the event
listeners — instead of wiping and rebuilding. No re-render flash, no
lost DOM identity, no "hydration mismatch" class of bug. (Part 8 of
the FitzLiveViews series — the payoff Part 7 promised.)

Part 7 closed the fullstack loop: a .fitzv component calling an @rpc
server function, typed end to end. It ended on a promise — SSR
hydration: the same component rendered on the server for first paint,
then the WASM runtime taking over the existing DOM. This is that part.

Why hydration, and why it's usually painful

Server-side rendering gives you the good first paint: the browser shows
real HTML immediately, search engines see content, the page works with
JavaScript disabled. But then the interactive runtime has to take over
that page. The naive way — mount the app fresh — throws the
server-painted DOM away and rebuilds it, producing a flash and doing the
work twice. The framework way — reconcile a virtual DOM against the
server HTML — is where "hydration mismatch" warnings come from, and it
ships the whole framework runtime to do it.

Fitz does neither. The WASM runtime adopts the exact nodes the
server painted.

One source, both ends

A .fitzv component already compiles two ways: to server HTML (the
LiveViews path) and to a standalone WASM app. Hydration is opt-in with
one marker on the root:

component App hydrate {
  state {
    name: Str = "world"
  }

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

  <template>
    <p class="greeting">Hello, <span class="nm">{name}</span></p>
    <input @input="on_name" value="{name}" />
  </template>
}

The marker is opt-in so components rendered for the LiveViews
WS-takeover (whose DOM diff forbids a <script> in the root) stay
byte-identical. When it's present, both halves cooperate.

What the server emits

The SSR emitter paints the DOM and leaves the client everything it
needs to adopt it:

The rendered HTML, exactly as the component's template produces it.
A state payload — <script type="application/json" id="__flv_state_App">{"name":"Ada"}</script> — so the client boots with the server's state, not the template defaults.
Adoption markers the client walks by: … around interpolations in mixed text (Hello, {name}!), … around {#if}/{#for} regions, a <div class="__fitz-child-Card"> wrapper around a composed child, and slot content inlined in the parent's scope.

This is a real render-a-string on the server — not a hand-authored
index.html. The server computes App_render(App { name: "Ada" }) and
that string is what the browser paints and the WASM adopts.

What the client does on boot

Instead of mount() (which wipes the root and builds), a hydratable
component runs hydrate():

It sees the mount root already has content.
It restores the serialized state from the <script> payload — primitives, and composite state too (List<T>, Map<Str,V>, nullables, imported nominal types round-trip through JSON).
It walks the existing DOM with a cursor (depth-first), mapping each element/text/comment node onto the same keep-node handles the build walk would have created — no create_element, no wipe.
It wires the @input/@click listeners onto the adopted nodes.

From there a state change patches in place (keep-node reconciliation),
so the live <input> keeps its caret. The page was never rebuilt — it
was taken over.

It really runs

Verified end-to-end in real Chrome (via Puppeteer), and the test is the
convincing part: a JS property is set on a server-painted node before
init() runs. After hydration, that property is still there — proof
the node was adopted, not recreated. The greeting shows "Ada" (the
server's state, not the template default "world"), typing patches the
text in place, and there are zero page errors. The runnable examples
cover the shapes:
hydrate
(base),
hydrate-mixed
(mixed static+interpolated text),
hydrate-regions
({#if}/{#for}), and
hydrate-composition
(<Child /> + slots, adopted across the component boundary).

Why this is different

Hydration is a solved problem in the JS world — the point is what it
costs:

React / Next.js ship the framework runtime to the client and run a reconciliation pass to attach to the server HTML; a mismatch between the two is a whole category of warnings. Fitz adopts the exact nodes by walking them — there's nothing to reconcile and no framework runtime to ship.
Astro islands / partial hydration are great, but each island is still a JS-framework runtime. Fitz's client is a single compiled WASM app that took over the whole server-painted tree.
Phoenix LiveView / Hotwire are server-driven: the "client" is a thin JS layer patching the DOM. Fitz's client is a real compiled app with its own state — it just starts from the server's DOM instead of a blank mount.

Same source both ends, node-for-node adoption, opt-in per component,
keep-node patching afterward, zero framework runtime. That combination
is the differentiator.

The honest edges (MVP)

Hydration is opt-in with the hydrate marker (universal auto-hydration is a future improvement — opt-in keeps the LiveViews path byte-identical).
Composite state restore is covered; types that don't round-trip through JSON (a Map with a non-Str key, tuples, functions) reset to their default on restore, symmetric with the dump.
Named slots in the SSR emitter and dynamic composition inside a {#if}/{#for} are later slices; the default slot + static composition adopt today.

That's the loop the series has been building toward: the server paints
first (fast, indexable, @rpc-fed), and the same .fitzv — as a WASM
app — takes over that exact DOM and keeps it alive. Next up: the
companion UI library the flagship admin panel is built from — ~40
importable components, extracted from a real app.

Hidratación isomórfica en Fitz: first paint en el server, y después WASM adopta el DOM

Martin Palopoli — Thu, 17 Sep 2026 09:19:49 +0000

TL;DR — Marcás un componente con hydrate y el mismo .fitzv hace
dos trabajos: el server lo renderiza a HTML para un first paint rápido
(SEO, funciona-sin-JS), y al boot el runtime client-WASM adopta ese
DOM exacto — restaurando el estado serializado desde un <script>
embebido, recorriendo los nodos existentes y cableando los event
listeners — en vez de tirar todo y reconstruir. Sin flash de
re-render, sin perder la identidad del DOM, sin la categoría de bug
"hydration mismatch". (Parte 8 de la serie FitzLiveViews — el pago que
prometió la Parte 7.)

La Parte 7 cerró el loop fullstack: un componente .fitzv llamando a una
función de servidor @rpc, tipada de punta a punta. Terminó con una
promesa — hidratación SSR: el mismo componente renderizado en el server
para el first paint, y después el runtime WASM tomando control del DOM
existente. Esta es esa parte.

Por qué hidratación, y por qué suele doler

El server-side rendering te da el buen first paint: el browser muestra
HTML real de una, los buscadores ven contenido, la página funciona con
JavaScript deshabilitado. Pero después el runtime interactivo tiene que
tomar control de esa página. La forma naive —montar la app de cero—
tira el DOM pintado por el server y lo reconstruye, produciendo un flash
y haciendo el trabajo dos veces. La forma framework —reconciliar un
virtual DOM contra el HTML del server— es de donde salen los warnings de
"hydration mismatch", y encima manda el runtime entero del framework para
hacerlo.

Fitz no hace ninguna de las dos. El runtime WASM adopta los nodos
exactos que pintó el server.

Un solo source, los dos extremos

Un componente .fitzv ya compila de dos formas: a HTML del server (el
camino LiveViews) y a una app WASM standalone. La hidratación es opt-in
con un marcador en el root:

component App hydrate {
  state {
    name: Str = "world"
  }

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

  <template>
    <p class="greeting">Hello, <span class="nm">{name}</span></p>
    <input @input="on_name" value="{name}" />
  </template>
}

El marcador es opt-in para que los componentes renderizados para el
WS-takeover de LiveViews (cuyo diff de DOM prohíbe un <script> en el
root) queden byte-idénticos. Cuando está, las dos mitades cooperan.

Qué emite el server

El emisor SSR pinta el DOM y le deja al cliente todo lo que necesita
para adoptarlo:

El HTML renderizado, exactamente como lo produce el template del componente.
Un payload de estado — <script type="application/json" id="__flv_state_App">{"name":"Ada"}</script> — así el cliente bootea con el estado del server, no con los defaults del template.
Marcadores de adopción por los que el cliente camina: … alrededor de las interpolaciones en texto mixto (Hello, {name}!), … alrededor de las regiones {#if}/{#for}, un <div class="__fitz-child-Card"> envolviendo a un hijo compuesto, y el contenido de slot inlineado en el scope del padre.

Esto es un render-a-string de verdad en el server — no un index.html
hecho a mano. El server computa App_render(App { name: "Ada" }) y ese
string es lo que el browser pinta y el WASM adopta.

Qué hace el cliente al boot

En vez de mount() (que limpia el root y construye), un componente
hidratable corre hydrate():

Ve que el root del mount ya tiene contenido.
Restaura el estado serializado desde el payload del <script> — primitivos, y estado compuesto también (List<T>, Map<Str,V>, nullables, tipos nominales importados round-trippean por JSON).
Recorre el DOM existente con un cursor (depth-first), mapeando cada nodo elemento/texto/comentario sobre los mismos handles keep-node que el walk de build habría creado — sin create_element, sin wipe.
Cablea los listeners @input/@click sobre los nodos adoptados.

De ahí en más un cambio de estado parchea in-place (reconciliación
keep-node), así que el <input> vivo conserva su caret. La página nunca
se reconstruyó — se tomó control de ella.

Corre de verdad

Verificado end-to-end en Chrome real (vía Puppeteer), y el test es la
parte convincente: se le pone una propiedad JS a un nodo pintado por el
server antes de que corra init(). Después de la hidratación, esa
propiedad sigue ahí — prueba de que el nodo fue adoptado, no
recreado. El saludo muestra "Ada" (el estado del server, no el default
del template "world"), tipear parchea el texto in-place, y hay cero
errores de página. Los ejemplos runnable cubren las formas:
hydrate
(base),
hydrate-mixed
(texto mixto estático+interpolado),
hydrate-regions
({#if}/{#for}), y
hydrate-composition
(<Child /> + slots, adoptados cruzando el borde del componente).

Por qué es distinto

La hidratación es un problema resuelto en el mundo JS — la cuestión es
qué cuesta:

React / Next.js mandan el runtime del framework al cliente y corren una pasada de reconciliación para engancharse al HTML del server; un mismatch entre los dos es una categoría entera de warnings. Fitz adopta los nodos exactos recorriéndolos — no hay nada que reconciliar ni runtime de framework que mandar.
Astro islands / hidratación parcial están buenísimos, pero cada isla sigue siendo un runtime de framework JS. El cliente de Fitz es una sola app WASM compilada que tomó control del árbol entero pintado por el server.
Phoenix LiveView / Hotwire son server-driven: el "cliente" es una capa fina de JS parcheando el DOM. El cliente de Fitz es una app compilada de verdad con su propio estado — solo que arranca desde el DOM del server en vez de un mount en blanco.

Mismo source los dos extremos, adopción nodo-por-nodo, opt-in por
componente, parcheo keep-node después, cero runtime de framework. Esa
combinación es el diferencial.

Los bordes honestos (MVP)

La hidratación es opt-in con el marcador hydrate (la auto-hidratación universal es una mejora futura — el opt-in mantiene el camino LiveViews byte-idéntico).
El restore de estado compuesto está cubierto; los tipos que no round-trippean por JSON (un Map con key no-Str, tuplas, funciones) resetean a su default al restaurar, simétrico con el dump.
Los named slots en el emisor SSR y la composición dinámica adentro de un {#if}/{#for} son slices posteriores; el slot default + la composición estática adoptan hoy.

Ese es el loop hacia el que venía la serie: el server pinta primero
(rápido, indexable, alimentado por @rpc), y el mismo .fitzv — como
app WASM — toma control de ese DOM exacto y lo mantiene vivo. Lo que
sigue: la librería de UI companion de la que está hecho el panel admin
flagship — ~40 componentes importables, extraídos de una app real.

Server functions in Fitz: call the server from a WASM component, no plumbing

Martin Palopoli — Fri, 11 Sep 2026 19:37:13 +0000

TL;DR — Mark an async fn with @rpc and call it from a .fitzv
component as if it were local: let u = get_user(42).await?. The
compiler generates both halves from that one declaration — a
POST /__rpc/get_user endpoint on the server (which can touch the DB,
auth, secrets) and a fetch-based stub on the client — with the same
type shared back and front. No hand-written HTTP handler, no
fetch, no JSON glue, no route strings, no external deps. (Part 7 of
the FitzLiveViews series — the "whole stack, no plumbing" moment.)

Earlier parts showed a .fitzv component compiling two ways: to
server-rendered HTML (LiveViews over a WebSocket) and to a standalone
WebAssembly SPA. Both are great — but a component in the browser is an
island. Anything real — reading the database, checking a token — has
to happen on the server, and the classic bridge is plumbing: write an
endpoint, write a fetch, marshal the JSON both ways, and keep the
types in sync by hand.

This part erases all of that with one decorator.

One declaration, both halves

Here's a server function. It's a normal async fn — it could open a
Postgres connection, run an ORM query, verify a JWT. The only special
thing is @rpc:

// api.fitz (classic — has db, auth, secrets)
type User {
  id: Int
  name: Str
}

@rpc
async fn get_user(id: Int) -> Result<User> {
  let conn = db.connect(db_url()).await?
  return User.where(fn(u) => u.id == id).first(conn).await
}

And here's the client calling it, inside a .fitzv component's event
handler:

// App.fitzv (client-WASM)
from api import get_user, User

component App {
  state { name: Str = "" }

  event load() {
    let u = get_user(42).await?   // ← a round-trip, typed, like a local call
    name = u.name
  }

  <template>
    <p>{name}</p>
    <button @click="load">Load user 42</button>
  </template>
}

That's the whole app. No fetch. No /api/users/:id. No
JSON.parse + a hand-written User interface that drifts from the
server. The User type lives once in api.fitz; the server
compiles it into a native binary, the client compiles it into WASM, and
they share the definition.

What the compiler actually emits

@rpc is invisible-but-typed because the compiler writes both sides for
you.

Server side (fitz build --bin server): the @rpc fn is mounted as
POST /__rpc/get_user. The request body is a JSON object with one field
per parameter ({"id": 42}); each param is deserialized from its field,
the function runs, and its Result<T> becomes 200 + the JSON of T
(Ok) or 500 + {"error": ...} (Err). It reuses the entire @post
pipeline — observability, panic-catch, everything.

Client side (fitz build --bin web --target wasm-client): the
imported @rpc fn is emitted as an async fetch stub — its
(server-side) body is not transpiled into the WASM. The stub
serializes the args, POSTs same-origin (so the session cookie rides
along), and maps the reply back to Result<T>. And because the event
handler now .awaits, the compiler splits it into a sync wrapper + an
async worker (spawn_local), so state updates and a re-render fire when
the reply lands.

You write get_user(42).await?. You get a network round-trip with a
typed result.

It really runs

The runnable example
is a two-button SPA plus a server binary. Verified end-to-end in real
Chrome: click "Greet" and the greeting comes back from the server
("Hello, world!"); click "Load user" and the User is fetched,
deserialized, and rendered ("Ada") — zero page errors. The client
crate compiles to a real .wasm via wasm-pack; the server answers the
exact /__rpc/* routes.

fitz build --bin server     # mounts POST /__rpc/* on :3838
fitz build --bin web        # → target/wasm/web/{web.js, web_bg.wasm}

Serve the SPA from the same origin as the server (in production,
have the server serve the bundle, or put both behind one reverse proxy)
so the relative fetch("/__rpc/...") reaches it.

Why this is different

Server functions aren't new — Next.js Server Actions, Remix
loaders/actions, SvelteKit +page.server, tRPC, Phoenix all have the
pattern. What's different in Fitz:

No infrastructure step. No "use server" directive, no tRPC router, no code generator. One decorator; the compiler does the rest.
The same type, literally. Not "inferred types" across a boundary — the exact same User definition compiled to both a native struct and a WASM struct. Zero drift, by construction.
Zero external deps. The server half reuses the built-in HTTP stack; the client half pulls in fetch + serde only when a crate actually uses @rpc. No @trpc/*, no bundler magic.
One language, both ends. The server fn and the client component are the same Fitz, checked by the same checker.

The honest edges (MVP)

A nominal type that crosses the wire is imported into the .fitzv too (from api import ..., User) so the client gets its struct.
Stacked auth on the generated endpoint (@authenticated/@admin) is a post-MVP refinement; for now the same-origin session cookie travels with the request and you check the token inside the @rpc body.
The component re-renders once, when the reply arrives — a mid-request "loading…" flash is a later fine-grained-reactivity slice.

That's the fullstack loop closed: a component in the browser calling a
function on the server, typed end-to-end, with nothing in between that
you had to write. Next up: SSR hydration — the same .fitzv rendered on
the server for first paint, then the WASM runtime taking over the
existing DOM (including the state your @rpc calls produced).

Funciones de servidor en Fitz: llamá al server desde un componente WASM, sin plomería

Martin Palopoli — Fri, 11 Sep 2026 19:35:48 +0000

TL;DR — Marcás una async fn con @rpc y la llamás desde un
componente .fitzv como si fuera local: let u = get_user(42).await?. El compilador genera las dos mitades desde
esa única declaración — un endpoint POST /__rpc/get_user del lado
server (que puede tocar la DB, auth, secrets) y un stub fetch del
lado client — con el mismo type compartido back y front. Sin handler
HTTP a mano, sin fetch, sin JSON glue, sin rutas escritas a mano,
sin deps externas. (Parte 7 de la serie FitzLiveViews — el momento
"todo el stack junto, sin plomería".)

Las partes anteriores mostraron un componente .fitzv compilando de
dos formas: a HTML server-rendered (LiveViews sobre un WebSocket) y
a una SPA WebAssembly standalone. Las dos están buenas — pero un
componente en el browser es una isla. Cualquier cosa real —leer la
base, verificar un token— tiene que pasar en el server, y el puente
clásico es plomería: escribís un endpoint, escribís un fetch, parseás
el JSON de ida y de vuelta, y mantenés los tipos sincronizados a mano.

Esta parte borra todo eso con un decorator.

Una declaración, las dos mitades

Acá hay una función de servidor. Es una async fn normal — podría abrir
una conexión a Postgres, correr una query del ORM, verificar un JWT. Lo
único especial es @rpc:

// api.fitz (classic — tiene db, auth, secrets)
type User {
  id: Int
  name: Str
}

@rpc
async fn get_user(id: Int) -> Result<User> {
  let conn = db.connect(db_url()).await?
  return User.where(fn(u) => u.id == id).first(conn).await
}

Y acá el cliente llamándola, dentro del event handler de un componente
.fitzv:

// App.fitzv (client-WASM)
from api import get_user, User

component App {
  state { name: Str = "" }

  event load() {
    let u = get_user(42).await?   // ← un round-trip, tipado, como una llamada local
    name = u.name
  }

  <template>
    <p>{name}</p>
    <button @click="load">Cargar usuario 42</button>
  </template>
}

Esa es toda la app. Sin fetch. Sin /api/users/:id. Sin
JSON.parse + una interface User hecha a mano que se desincroniza del
server. El tipo User vive una vez en api.fitz; el server lo
compila a un binario nativo, el client lo compila a WASM, y comparten la
definición.

Qué emite el compilador en realidad

@rpc es invisible-pero-tipado porque el compilador escribe los dos
lados por vos.

Del lado server (fitz build --bin server): la @rpc fn se monta
como POST /__rpc/get_user. El body es un objeto JSON con un campo por
parámetro ({"id": 42}); cada param se deserializa de su campo, la
función corre, y su Result<T> se vuelve 200 + el JSON de T (Ok) o
500 + {"error": ...} (Err). Reusa toda la cadena de @post —
observability, panic-catch, todo.

Del lado client (fitz build --bin web --target wasm-client): la
@rpc fn importada se emite como un stub fetch async — su cuerpo
(server-side) no se transpila al WASM. El stub serializa los args,
POSTea al mismo origen (así la cookie de sesión viaja sola), y mapea la
respuesta a Result<T>. Y como el event handler ahora hace .await, el
compilador lo parte en un wrapper sync + un worker async
(spawn_local), así que el estado se actualiza y el componente
re-renderiza cuando llega la respuesta.

Vos escribís get_user(42).await?. Obtenés un round-trip de red con un
resultado tipado.

Corre de verdad

El ejemplo runnable
es una SPA de dos botones más un binario de server. Verificado
end-to-end en Chrome real: clickeás "Greet" y el saludo vuelve del
server ("Hello, world!"); clickeás "Cargar usuario" y el User se
pide, se deserializa y se renderiza ("Ada") — cero errores de página.
El crate del cliente compila a un .wasm real vía wasm-pack; el
server responde las rutas /__rpc/* exactas.

fitz build --bin server     # monta POST /__rpc/* en :3838
fitz build --bin web        # → target/wasm/web/{web.js, web_bg.wasm}

Serví la SPA desde el mismo origen que el server (en producción, que
el server sirva el bundle, o poné a los dos detrás de un reverse proxy)
para que el fetch("/__rpc/...") relativo lo alcance.

Por qué es distinto

Las funciones de servidor no son nuevas — Next.js Server Actions, Remix
loaders/actions, SvelteKit +page.server, tRPC, Phoenix tienen el
patrón. Lo distinto en Fitz:

Sin paso de infraestructura. Sin directiva "use server", sin router de tRPC, sin generador de código. Un decorator; el compilador hace el resto.
El mismo type, literal. No "tipos inferidos" cruzando un borde — la misma definición exacta de User compilada a un struct nativo y a un struct WASM. Cero drift, por construcción.
Cero deps externas. La mitad server reusa el stack HTTP nativo; la mitad client trae fetch + serde solo cuando un crate realmente usa @rpc. Sin @trpc/*, sin magia de bundler.
Un solo lenguaje, los dos extremos. La fn del server y el componente del client son el mismo Fitz, chequeados por el mismo checker.

Los bordes honestos (MVP)

Un tipo nominal que cruza el cable se importa también en el .fitzv (from api import ..., User) para que el cliente tenga su struct.
Auth apilable sobre el endpoint generado (@authenticated/@admin) es refinamiento post-MVP; por ahora la cookie de sesión same-origin viaja con el request y verificás el token dentro del cuerpo de la @rpc.
El componente re-renderiza una vez, cuando llega la respuesta — un flash de "cargando…" a mitad de camino es un slice posterior de reactividad fine-grained.

Ese es el loop fullstack cerrado: un componente en el browser llamando a
una función en el server, tipado de punta a punta, sin nada en el medio
que hayas tenido que escribir. Lo que sigue: hidratación SSR — el mismo
.fitzv renderizado en el server para el first paint, y después el
runtime WASM tomando control del DOM existente (incluyendo el estado que
produjeron tus llamadas @rpc).

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.

DEV Community: Martin Palopoli

Isomorphic hydration in Fitz: first paint on the server, then WASM adopts the DOM

Why hydration, and why it's usually painful

One source, both ends

What the server emits

What the client does on boot

It really runs

Why this is different

The honest edges (MVP)

Hidratación isomórfica en Fitz: first paint en el server, y después WASM adopta el DOM

Por qué hidratación, y por qué suele doler

Un solo source, los dos extremos

Qué emite el server

Qué hace el cliente al boot

Corre de verdad

Por qué es distinto

Los bordes honestos (MVP)

Server functions in Fitz: call the server from a WASM component, no plumbing

One declaration, both halves

What the compiler actually emits

It really runs

Why this is different

The honest edges (MVP)

Funciones de servidor en Fitz: llamá al server desde un componente WASM, sin plomería

Una declaración, las dos mitades

Qué emite el compilador en realidad

Corre de verdad

Por qué es distinto

Los bordes honestos (MVP)

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

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