DEV Community

Kvant swatg
Kvant swatg

Posted on Originally published at github.com

Starting a Jeston Application with One Valuable Route

#react #webdev #tutorial #typescript

A useful framework should help you reach a working slice quickly without forcing you to decide every production detail on day one. Jeston's recommended path starts with the smallest valuable request: one route and one response.

Create the application

Jeston requires Node.js 20 or newer. Create and run a project with:

npx jeston create my-app
cd my-app
npm install
npm run dev
Enter fullscreen mode Exit fullscreen mode

For a SaaS-oriented starting point:

npx jeston create my-saas --template=saas
Enter fullscreen mode Exit fullscreen mode

The SaaS starter includes React SSR, hydration, an API health route, a signed-session inspection route, TypeScript strict mode, security limits, and extension points for database, cache, jobs, and storage adapters.

Choose a routing convention

Jeston supports the established pages/ convention and can also discover app/ page and route-handler files. An app/ application can use:

  • page.tsx for a page
  • route.ts for an HTTP handler
  • layout.tsx for a persistent layout
  • loading.tsx for loading boundaries
  • error.tsx for a render boundary
  • not-found.tsx for a custom 404 page
  • forbidden.tsx and unauthorized.tsx for typed authorization errors

Route groups such as (marketing) organize files without changing the public URL. Layouts compose from the app root toward the leaf route.

Add an API contract

A typed API handler can validate and persist input while receiving the request cancellation signal:

import type { ApiHandler } from '@kvantjs/jeston';

export const POST: ApiHandler = async ({ body, signal }) => {
  await validateAndPersist(body, { signal });
  return { status: 201, json: { created: true } };
};
Enter fullscreen mode Exit fullscreen mode

The runtime bounds JSON bodies, returns a stable 400 for malformed JSON, and returns 413 when the configured body limit is exceeded. OPTIONS can expose the allowed methods, and HEAD uses an explicit handler or the GET handler without sending a body.

Expand only when the slice proves its value

Once the first route is useful, add the capabilities the product actually requires: a SQL adapter, sessions, authorization, rate limiting, cache, jobs, storage, or observability. This keeps architectural decisions connected to real product needs rather than hypothetical scale.

Jeston's documentation frames the progression as three questions:

  1. What is the smallest valuable request?
  2. What must remain portable?
  3. How will success be proven?

That sequence is a practical way to avoid both premature infrastructure and accidental production gaps.

Read the source and examples at github.com/kvantjs/jeston.

Top comments (0)