HTTP layer

# pnpm  pnpm add @glandjs/http @glandjs/express @glandjs/fastify @glandjs/koa @glandjs/hono @glandjs/node
# npm   npm install @glandjs/http @glandjs/express @glandjs/fastify @glandjs/koa @glandjs/hono @glandjs/node
# yarn  yarn add @glandjs/http @glandjs/express @glandjs/fastify @glandjs/koa @glandjs/hono @glandjs/node
# bun   bun add @glandjs/http @glandjs/express @glandjs/fastify @glandjs/koa @glandjs/hono @glandjs/node

Package	@glandjs/http
Version	1.1.0-beta
Repository	glandjs/http
License	MIT
Node	>= 20
Dependencies	@glandjs/core ^1.0.3-beta · @glandjs/events ^1.1.0 · @medishn/toolkit ^1.0.4 · tslib ^2.8.1
Peer dependencies	@glandjs/common ^1.0.3-beta · reflect-metadata ^0.2.2

Synced from glandjs/http

This page is generated from docs/README.md on main at main. Edit the document in its own repository and it will be republished on the next build. Open the source on GitHub

Gland’s HTTP layer in six packages: one framework-agnostic core and a pluggable adapter per server. The claim this documentation has to support is narrow and testable — the same controller, the same middleware and the same assertions produce the same results on all five transports — and every page here is organised around that.

If you are new here

Read these five, in this order. About twenty minutes, and afterwards nothing in the rest of this folder will surprise you.

1. Getting started — a working service, from pnpm to a request
2. Controllers and routes — how a method becomes a route
3. The context — what a handler is handed
4. Replies — what it may return, and what goes on the wire
5. Choosing an adapter — and then you are done

Guides

Guide	Covers
Getting started	A working service, from install to a request
Choosing an adapter	The five, and which to reach for
Controllers and routes	Declaring routes, every method, the prefix rules
The context	HttpContext, member by member
Middleware	The onion, path scoping, useRaw, the Express caveat
Replies	What a handler may return, and what goes on the wire
Errors	Problem details, the error handler, what is never leaked
CORS	One policy, one implementation, five adapters
Bodies and uploads	The parsers, the limit, the maxAge trap
Lifecycle events	The bus, and the five events worth wiring up
Deployment	TLS, proxies, graceful shutdown, health checks
Testing	Unit vs. integration, and the five-transport contract
Migrating to 1.1	What changed, and what to change

Architecture

What the layer is built from, and why. Read this before changing a shared behaviour — most of it is load-bearing for a reason that is not obvious from the code.

Document	Covers
Overview	The five ideas the layer is built from
The adapter contract	What an adapter implements, and what it does not
The request lifecycle	What happens, in order, for one request
Writing an adapter	Building a sixth transport from the contract

Reference

Document	Covers
API	Every public export, grouped by package
Differences between adapters	What each transport can and cannot do

Project

Document	Covers
Contributing	Setup, conventions, branching, releases
Changelog	Where the history actually lives
Security	Reporting a vulnerability, and where the risk is
Code of conduct

The five adapters

Package	Framework	Middleware onion	Extended methods	Runtime
@glandjs/express	Express 5	hand-off	via a method guard	Node
@glandjs/fastify	Fastify 5	real, inside one hook	most WebDAV	Node
@glandjs/koa	Koa 3	real	native	Node
@glandjs/hono	Hono 4	real	native	Node and the edge
@glandjs/node	node:http	real	native	Node, zero dependencies

Koa is the baseline: it is the one with nothing worth writing down. The other four each have one row that is not a tick, and it is always a property of the framework rather than of this layer.

• Express — Middleware → The Express caveat
• Fastify — Adapter matrix → Fastify
• Hono — Adapter matrix → Hono
• node:http — Adapter matrix → node:http

Conventions used in these pages

• app is the Gland application, http the connected HTTP layer. ctx is always the framework-agnostic context, never req or res.
• A table cell in bold is a limit, not a feature.
• “Built in” in a table means no package to install — not mounted for you. Every adapter needs a declared body parser; see Bodies and uploads.