Guides
Guides: a worked guide from route registry through to a production build.
Example
Start from an explicit route registry and add one application boundary at a time so browser, server, and production behavior stay testable.
export const registry = createRouteRegistry(() => {
group({ layout: AppLayout }, () => {
route('/', DashboardPage);
route('/projects/{projectId}', ProjectPage);
route('/404', NotFoundPage);
});
});Choose a guide
Each recipe in this section targets a specific shape of application: an SPA, an SSR app, an authenticated full-stack app, an API-only server, a static site, or an MCP server. Pick the one that matches your deployment target rather than reading them in order — createSPA, hydrateSPA, and createIslands are mutually exclusive client execution models, not layers you stack. createStaticGen is different: it's a build-time step, commonly paired with hydrateSPA (generate HTML, then hydrate it), not a fourth option in the same mutually-exclusive set. If you're not sure which fits, start with the SPA guide and add SSR or static generation later; the router and component code barely changes.
Start from a starter
askr create startkit my-app scaffolds a working project with the right @askrjs/vite plugin wiring already in place, so you're not hand-assembling vite.config.ts from these snippets. askr create --prompt "..." picks a template automatically when you describe the app you want. Both write a .askr/blueprint.json you can diff against as you follow a guide, which makes it easy to see exactly what a recipe added on top of the base scaffold.
Keep boundaries explicit
Askr's server layer asks you to build dependencies — database handles, auth resolvers, audit loggers — at a single composition root and pass them into route registration functions, not stash them on request context or reach for a service locator. Follow the same pattern on the client: build your route registry with createRouteRegistry() once, and pass query and mutation definitions in rather than constructing them ad hoc inside components. It costs a little boilerplate up front and pays off the first time you need to swap a real dependency for a test fake.
Production finish bar
Before calling any of these recipes done, check that ErrorBoundary wraps the parts of the tree that can fail at render time, that mutations declared with defineAction/action invalidate the right query keys, and that routes carrying real auth requirements are marked runtime-only rather than accidentally prerendered by createStaticGen. Run askr openapi --check if you're exposing a contract, since it fails CI on any byte-level drift from the committed spec. None of this is exotic — it's the same checklist every guide in this section ends on.