Get started
Composing systems
Start with the boundary you need
Section titled “Start with the boundary you need”τjs adds one thing to ordinary Fastify, Vite and framework conventions: a declared request boundary, where each route states its data, policy and rendering. It does not ask you to convert an application. Start with what you have, then declare the routes whose initial responses benefit from server coordination.
- Add critical or deferred data when the server should own the initial read
- Mediate service access where validation, cancellation and observability matter
- Choose SSR, streaming and hydration per declared page
- Move applications between React, Vue and Solid without moving policy and services into components
Adopt the model incrementally.
Your architecture is data, not source code
Section titled “Your architecture is data, not source code”A τjs system with its declared request boundary can be read without being run: routes, policy, rendering and declared service edges live outside the component tree, as data.
The declaration is plain configuration. A home page that server-renders; a product page that streams, with its reviews declared alongside:
export default defineConfig({ apps: [ { appId: "storefront", entryPoint: "", renderer: reactRenderer({ project: "./tsconfig.json" }), routes: [ { path: "/", attr: { render: "ssr", hydrate: true } }, { path: "/products/:id", attr: { render: "streaming", hydrate: true, meta: { title: "Product" }, data: serviceData("catalogue", "product", (p) => ({ id: String(p.id) })), deferred: { reviews: serviceData("reviews", "forProduct", (p) => ({ id: String(p.id) })), }, }, }, ], }, ],});The product is critical: resolved before the response commits, able to set the HTTP status. The reviews are deferred: they start with the request, stream when ready, never block the shell, and hydrate without a client refetch.
Each declared page is a real Fastify route, and a route can also declare head metadata, authentication and Content Security Policy. Everything after hydration - mutations, polling, subscriptions, UI-local fetching - stays in your application, where it belongs.
Read about request contracts and data ownership.
The request graph records the architecture declared in taujs.config.ts. Development traces record
what one request actually selected, called, deferred and delivered. The MCP server exposes both
forms of evidence to tools and AI agents rather than asking them to infer the system from component
source.
Explore architecture-aware inspection through MCP.
One architecture, several application shapes
Section titled “One architecture, several application shapes”The same Fastify host can serve, for example, a storefront, an account area and an operations console - each a separate application with its own renderer root, module graph and output bundle, and each free to choose its own renderer framework.
Each URL belongs to exactly one application. Left undeclared within the application shell, it remains client-rendered.
Applications compose through routes and assembled build output rather than runtime module federation. They can be built selectively, while the deployed server artefact receives the bundles and manifests it needs to serve the complete system.
See how multi-app composition works.
Use the ecosystems you already know
Section titled “Use the ecosystems you already know”τjs composes existing tools rather than replacing their native APIs:
- Fastify owns HTTP routing, plugins, hooks, decorators and the host lifecycle
- Vite owns the application module graph, development pipeline and production bundles
- React, Vue and Solid keep their component models, streaming semantics and client runtimes
There is no second HTTP router or parallel plugin system to learn. Supply your own Fastify instance and τjs operates inside an encapsulated scope; omit it and τjs creates and operates the Fastify host.
The same request boundary holds across all three component models: policy, data orchestration and service access stay where they are when the renderer changes.
Next steps
Section titled “Next steps”Request contracts and data
Micro-frontends with τjs
Architecture-aware AI