Revision · Part 2: The Frontend

Part 2 gives quill a face: a real Astro frontend talking to the Rust API. The interesting engineering isn’t the HTML — it’s the contract between a JavaScript frontend and a Rust backend, and the two hard things every full-stack app must solve: who the user is, and how to stream a response as it’s produced.

What this part covered

• The front/back contract — a typed API client, CORS, and a shared schema, deciding what renders static (SSG) versus server-rendered (SSR) against a live API.
• A reader site and an editor — the post list and each post rendered from the Rust API, static where it can be and server-rendered where it must be fresh; plus a real editor form that creates and updates posts through the API with optimistic UI and error surfaces.
• Sessions as auth — signed cookies so the editor knows who you are, verified on the Rust side, with CSRF basics and auth implemented as axum middleware.
• Server-Sent Events, built now on purpose — a text/event-stream endpoint the frontend consumes token-by-token, built here because Part 3’s AI drafting rides on exactly this pipe; covers backpressure and the streaming contract.
• Keep the frontend dumb, the backend authoritative — the Rust service owns data, identity, and business rules; Astro owns presentation. The same split you’d draw for a mobile app, a CLI, or a third-party integration.

The takeaway

Part 2’s answer to the thread is a trust boundary: the moment a browser can talk to your service, every request is untrusted input. Rust’s type system and axum’s extractors make “parse, don’t validate” the default, and the same Send/Sync discipline from async Rust keeps a streaming endpoint safe under many simultaneous readers. With the SSE pipe in place, Part 3 sends AI-generated tokens through it.