In a meta-framework, what does it mean for a route to handle a write itself instead of posting to a separate API?

## The problem it solves The browser has been able to send data to a server since long before any framework existed: an HTML `<form>` with `method="post"` and an `action` URL. The browser encodes the fields, sends a `POST`, and renders whatever document comes back. The awkward part in a component-oriented app is that the code which should handle that submission — the code holding database credentials and reading the session cookie — belongs on the server, while the markup declaring the form lives in a component that may also render in the browser. A **route-handled write** is the framework closing that gap: you write the handler next to the component, and the framework gives it a public address so the form has something real to point at. The alternative is a separate endpoint plus client-side code that serialises state, sends it, interprets the response and updates the screen. That still works and is sometimes right; what the route-handled form removes is the second code path and the requirement that scripting be present and working. ## What the framework actually does Meta-frameworks package this in one of two shapes: - **A write step on the route module.** The file that owns a URL exports a read step and a write step; the read step runs for `GET`, the write step runs when a `POST` reaches that same URL. - **A server-only function marked as form-callable.** The function is compiled out of the client bundle, assigned a generated address, and the framework fills that address into the form's `action` for you. Either shape gives you the same three guarantees: 1. **The body never reaches the browser.** Secrets, queries and server-only imports stay on the server; the browser only ever sees a URL string. 2. **The submission is a real HTTP request.** It has a method, a body encoding, headers and cookies, and it obeys the same rules as any other request. 3. **Both transports share one handler.** Whatever runs for the scriptless submit is exactly what runs for the scripted one. ## The scriptless path, step by step 1. The server renders the route's HTML, including a form whose `action` is the handler's URL and whose `method` is `post`. 2. The user submits. The browser performs a full document `POST`, encoding the fields as URL-encoded pairs, or as multipart when the form carries a file. 3. The framework matches the request to the handler, parses the body, and calls the function with the submitted values plus access to the request context. 4. The function returns either a value or a redirect. 5. The browser renders the resulting document: a fresh page at the redirect target, or the same route rendered again with the returned value available to the form. No step there requires the JavaScript bundle to have arrived, parsed or hydrated. That matters more than "users with scripting disabled" suggests: between first paint and hydration there is a real window on every load, and on a slow device or a flaky connection it is long enough to click something. ## Two transports, one handler | | Before hydration | After hydration | |---|---|---| | What the browser sends | a document `POST` that replaces the page | a background `POST` of the same fields | | What comes back | a full HTML document | the data or redirect the handler produced | | What the user sees | a page load | the current screen updated in place | | Who runs the checks | the handler, on the server | the handler, on the server | The bottom row is the point. Because the transport changes but the handler does not, there is no second implementation of validation or permission checking to keep in sync, and no way for the scripted path to skip a check the scriptless one performs. ## What this buys and what it obliges The gain is that a write is declared where it is used, in one place, with the server's privileges, and works at the lowest common denominator of the platform. The obligations follow directly from the mechanism: - **The handler is a public URL.** Anything that can make an HTTP request can call it with any payload, so identity, permission and input checks have to live inside it. - **The return shape is a decision.** Rendering the route again with field errors as data keeps the user in the form; redirecting turns the result into a plain `GET` the user can reload safely. - **The write is not the whole job.** The route's read steps have to run again, or the screen after the write shows what was true before it. - **The same submission can arrive twice.** Networks retry and users double-click, so the handler should be safe to receive more than once. ## Where meta-frameworks differ The framing above is common, but the details are not universal. Some frameworks address the write through the route's own URL and distinguish several writes by a submitted field; others mint an opaque per-function address. Some accept only form-encoded fields; others serialise richer argument values for the scripted path while still accepting a plain form for the scriptless one. The scriptless guarantee itself holds only when the write is declared the way that framework designates for it — a handler wired up by hand in client code is back to needing script.