Giant Context builds and hosts websites. The website is the product: public, indexed, served fast to strangers. The console is the portal where a customer builds and manages theirs, an authenticated app behind a login. Two surfaces, opposite jobs.

The console is not a Next.js app, and it is not react-router or TanStack Router either. Routing there is a system I own outright. There was never a bake-off, because by the time the console needed routing the codebase already generated its API client, its cache keys, its hooks and its form validation from one schema. The route table was one more output from machinery that was already running.

The architecture committed to its structure before there was a product in the repository. The API is the hub, and everything that renders is a satellite. The API describes itself in an OpenAPI schema, and every consumer works from that description: the browser SPA that is the console, the Electron desktop shell, a native mobile client if one ever becomes necessary, the SDKs, and consumers that are not browsers at all. Tool-calling agents are already in the repository. None of them get a private contract. The schema is the contract.

That last group is the reason this matters more than it looks. I want an SDK, and I want an SDK because I want the platform reachable over MCP, so an agent can operate it the way a person operates the console. A model calling this API should not have to know a rendering framework exists. If the API is tangled into one, then every non-browser consumer either drags that framework along or reimplements the contract by hand, and the second one is how contracts drift.

Satellites are replaceable on purpose. Electron is a solid way to wrap an SPA into a desktop app, and I do not fully trust it as a long-term answer, because wrapper quality is somebody else's roadmap. If the day comes when only a real native app will do, the satellite gets swapped and the hub does not move. The presentation layer stays decoupled from the schema, so that no rendering choice made today can hold the data model hostage later.

The same shape pays elsewhere. A self-describing API gives you a Swagger surface, generated client bindings, and one place where permission checks live against the schema instead of once per rendering framework.

Next fights this shape, because Next is not a router. It is a commitment to a rendering server. Your routes become its route files, your data fetching runs inside its request lifecycle, and your components are split into ones that may run on the server and ones that may not. Those are reasonable rules for a rendering server to have. But adopting them puts the framework at the centre of a system whose centre is supposed to be the schema.

The objection to a homegrown router was never the runtime. Path matching is a solved problem the size of a util file. The objection is everything around it: keeping the route table, the view files and the types in agreement, forever, by hand. Somebody has to notice when a new view file appears and add it to the table. Somebody has to notice when a folder is renamed and fix the path. That work never ends and nobody is assigned to it, which is why using a library is the right default for almost everyone.

Here that work is already automated, for reasons that had nothing to do with routing. The generated package runs a set of generator scripts:

In the first line, the client's API bindings materialize from the running dev server's own OpenAPI spec. That 127.0.0.1:5175 URL is the API describing itself, and the description becomes typed code. The same machinery emits the query cache keys, the data hooks, the form validation, the mocks and factories the tests run on, and the same habit keeps the reactive layer honest.

All of that was built to serve the API client. Routing was added to a pipeline that already existed, which is the entire reason it was cheap. And the input it needed was already sitting there, because a folder tree is a declaration that nobody has to maintain separately.

A directory means a path. A bracketed directory means a parameter. A view file means a page. The generator walks the tree and emits the route table, and the build refuses to proceed without regenerating first, so a folder added without a regeneration fails typecheck rather than 404ing in a browser.

That import identifier is a name nobody would type, and nobody has to. The hooks that fetch a route's data, the validation on its forms, the cache keys it invalidates, all of those are generated from the same schema, so a view file receives them rather than importing them by hand. The only thing anyone writes is the folder name.

Which means that identifier is doing real work. It is the join between a folder in the console and an operation in the API, made by machine at both ends. Rename the folder and the path changes with it. Rename the operation and the client method changes with it. Neither one can be quietly half-done.

The runtime that remains matches a path, mounts the view, and hands over the params. It is one Router component and its utils, small enough to read in a sitting.