Getting Started

Introduction

What NextRush is, who it's for, and the one path to your first running API.

Start here

One request flow. Every runtime. Zero hidden behavior.

Build APIs with explicit routing, middleware, and adapters. Install only the packages you need — nothing hidden, nothing automatic — on Node, Bun, Deno, Edge, or Serverless.

Beginner5 minNode · Bun · Deno · EdgeTypeScript
  • 0 core dependencies
  • 5 runtimes on one codebase
  • 100% TypeScript

MIT licensed · Open source

Your first NextRush app

The smallest useful NextRush app — create an application, register one route, start listening:

src/index.ts
import { createApp, createRouter, listen } from 'nextrush'; const app = createApp();create applicationconst router = createRouter(); router.get('/', (ctx) => {register route  ctx.json({ message: 'Hello NextRush!' });}); app.route('/', router);await listen(app, 8080);start server
GET /200 OK{ "message": "Hello NextRush!" }
No decorators·No configuration·One route·Node · Bun · Deno · Edge · Serverless

Why NextRush exists

Bare Node frameworks and full platforms each give something away. NextRush is built to skip that trade:

Tiny framework

Pros

  • ✓ Small, learnable core
  • ✓ Easy to understand

Trade-offs

  • ✗ Reinvent middleware
  • ✗ Weak scalability

Heavy framework

Pros

  • ✓ Batteries included
  • ✓ Scales for big teams

Trade-offs

  • ✗ Large runtime
  • ✗ Smallest service pays for the whole machine
★ Recommended

NextRush

  • ✓ Explicit
  • ✓ Modular
  • ✓ Typed
  • ✓ Portable

One request path explains every feature; nothing is hidden behind a decorator or a global — on a core that stays under 3,000 lines and runs the same code across all five runtimes.

Core mental model

Four concepts carry every request, each owning one job — the flow below doubles as the page's chapter index: click any concept stop to jump to its walkthrough. For the full tour with the request diagram, both programming styles, and the runtimes, read NextRush in One Page.

  1. Request
  2. Application
  3. Middleware
  4. Router
  5. Handler
  6. Response

Application

The entry point — holds the middleware chain and hands each request down it. It orchestrates; it doesn't match routes or handle requests itself.

Middleware

Behavior wrapped around a handler like layers of an onion — auth, parsing, logging — running before and after, so cross-cutting concerns live in one place.

Router

Maps a path to the one handler responsible for it, matched by a segment trie so lookup cost tracks URL depth, not how many routes you've registered.

Context

The one per-request object every step reads from and writes to — params/query/body in, json/status/headers out — fresh per request, so nothing leaks between them.

Deep dive into Concepts

Your next step

One path, three stops — each hands you straight to the next.

Where other frameworks trade off

If you've shipped HTTP APIs before, you've felt these edges. Each card names the one job a framework wins at and the cost you take on — so you can place NextRush against what you already know.

Express

Best for
A familiar API up fast on the largest middleware ecosystem.
Tradeoff
You wire middleware by hand and add types after the fact.

Koa

Best for
A clean async/await core with a minimal surface.
Tradeoff
Smaller ecosystem, and plugin quality varies.

Fastify

Best for
High Node throughput with a rich plugin system.
Tradeoff
Verbose JSON-Schema validation, and Node-only.

NestJS

Best for
Batteries-included structure and DI for large teams.
Tradeoff
Heavier runtime; Angular-style patterns for a small service.

Hono

Best for
Edge-first deploys on a modern, fast core.
Tradeoff
Younger ecosystem; defaults feel tight for a classic Node server.

Migrating from Express, Fastify, Hono, or NestJS? — the migration guide maps each one's habits to NextRush's, with side-by-side snippets and a difficulty rating per origin.

Choose NextRush if...

  • REST APIs and backend services that want strict TypeScript end to end
  • Projects that start functional and may grow into controllers and DI later
  • Deploying the same application code to more than one runtime (Node, Bun, Deno, Edge)
  • Teams who'd rather wire things explicitly than inherit implicit framework behavior

Choose another framework if...

It's a backend API framework, not a full-stack one

NextRush doesn't do SSR or full-stack routing. For that, reach for Next.js, Remix, or SvelteKit.

  • You need SSR or full-stack page routing
  • You want the widest npm middleware catalog available today (Express)
  • You need the longest production track record (Express, Fastify)

Continue learning

Four on-ramps pick up where this page leaves off — read in whichever order matches what you're building.

Was this helpful?

On this page