Overview
NextRush is a Node.js + TypeScript framework I'm building to understand how frameworks actually work under the hood. It ships with a middleware pipeline, a small plugin/adapter system, a custom router, and a zero-dependency core. It's not trying to replace Express — it's trying to teach me (and whoever reads the code) how Express-like things are built.
/ Scope
- HTTP server & lifecycle
- Middleware pipeline
- Routing layer
- Plugin/adapter system
- Body parser
Highlights
01
Framework internals from first principles
02
Extensible plugin architecture
03
Zero-dependency core
04
Inspired by modern backend frameworks
/ Tracks
- Research
- Open source
The Problem
Express feels like magic until you read its source. I wanted to understand the moving parts — middleware composition, routing, request lifecycle — by building them myself instead of reading about them.
Approach
Start with the smallest possible HTTP server, then add one concept at a time: request/response wrappers, then middleware, then a router, then plugins. Each layer gets its own tests and its own doc page before moving on.
Key Decisions
- 01
Zero-dependency core
No Express, no Fastify, no koa-style borrowings at runtime. Every abstraction is written by hand so there's no place to hide.
- 02
Middleware as a typed pipeline
Each middleware is `(ctx, next) => Promise<void>`. Composition is a single reducer. This makes the 'how does Express work?' question visible in ~30 lines.
- 03
Plugins as adapters, not hooks
Plugins receive the framework instance and extend it explicitly. No implicit `beforeEach` hooks. Behaviour stays traceable.
Architecture
- 01Middleware pipeline
- 02Plugin/adapter system
- 03Custom routing layer
- 04Custom body parser
Challenges & How I Solved Them
Async error propagation
/ Problem
An error thrown inside an async middleware silently hung the request.
/ Solution
Wrapped the pipeline in a try/catch-next that forwards any thrown error to an error-stage middleware. Same pattern Express uses, but visible in the framework's core.
Router design
/ Problem
Naive string-matching breaks down with params, wildcards and optional segments.
/ Solution
Built a trie-based router that pre-compiles routes once at startup. O(k) lookup where k is path depth, with zero regex at hot path.
Outcomes
- A framework I understand end-to-end
- Reference implementation of the middleware pattern
- Docs explain the 'why', not just the API
What I Learned
- 01
Frameworks are a stack of small decisions. None of them are clever individually
- 02
Writing docs while you build surfaces design mistakes earlier
- 03
A good core is boring. The magic comes from composition
Tech Stack
Next Steps
- Request validation layer
- Streaming response helpers
- Benchmarks vs Express and Fastify