Modern TypeScript applications often become difficult to reason about because rendering, API behavior, background work, caching, and deployment are owned by unrelated layers. Jeston takes a different approach: it keeps the runtime explicit while providing a coherent full-stack foundation for SaaS products, APIs, and internal platforms.
The problem: too many implicit boundaries
A framework can make the first screen easy to render while leaving production concerns to a collection of ad hoc conventions. Teams then have to decide how request cancellation reaches a database call, how a health check reports dependency latency, how a queue exposes idempotency, and how a deployment remains portable.
Jeston brings these concerns into explicit contracts. Its platform includes file-based routing, React SSR and SSG, hydration, streaming, deterministic API routes, jobs, cache contracts, health checks, metrics hooks, authentication primitives, and portable Node deployment.
Explicit does not mean inflexible
The goal is not to lock an application into one vendor. Jeston exposes provider-neutral contracts for databases, caches, queues, storage, metrics, frontend integrations, AI integrations, and deployment. The core does not bundle vendor SDKs, so providers can publish adapters independently.
This separation is useful when an application needs to move between local development and production infrastructure, or when a team wants to change a provider without rewriting application-level behavior.
A practical starting point
A new project can start with one route and one response:
npx jeston create my-app
cd my-app
npm install
npm run dev
For a production-oriented SaaS boundary, the repository also provides a starter template:
npx jeston create my-saas --template=saas
The important design choice is incremental adoption. Add SQL, authentication, cache, jobs, storage, or agents when the application slice actually needs them.
What to measure
Jeston does not promise a universal capacity number. Real throughput depends on application code, database design, queue topology, cache behavior, proxy configuration, hardware, workload, and operational discipline. A complete deployment should be measured before making performance claims.
That restraint is part of the framework's value: explicit boundaries make it easier to identify what is being measured and which layer needs improvement.
Conclusion
Jeston is designed for teams that want a full-stack TypeScript runtime without making their architecture dependent on a proprietary hosting platform. Its central idea is simple: make the runtime, contracts, and operational signals visible, then keep the implementation replaceable.
Explore the source and documentation at github.com/kvantjs/jeston.
Top comments (0)