You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal of this repository is to flatten out the state of current JS (HTTP) servers(less) ecosystem,
and determine what would be the best course of action to create a unified way to represent Handlers and Middlewares (and their Context).
The playground contains code to test some patterns, represent Handlers and Middlewares, and adapters for all the major implementations.
Some packages are also being authored (WIP).
The goal of those packages will be to provide tool authors a mean to declare their Handlers and Middlewares once, targetting all supported servers.
Think of it as unplugin but for Handlers and Middlewares.
Definitions
Handler
A function that returns a response. Depending on the framework, a response can be anything from a standard Response, a string, an object, a ServerResponse, etc.
A standard, agnostic and future-proof way to represent a request would certainly be with the Response interface, even if it currently have some limitations.
Middleware
A function that modifies the Context or Response, and can return nothing. It can be called before and after a Handler. Hono as a great way to represent this.
Each framework as its own way to implement middlewares.
Context
Some data with the same lifespan as a Request.
Each framework as its own way to represent the Context, either by attaching it to their internal Request representation, or by having the Context itself containing the Request.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The goal of this repository is to flatten out the state of current JS (HTTP) servers(less) ecosystem,
and determine what would be the best course of action to create a unified way to represent Handlers and Middlewares (and their Context).
The playground contains code to test some patterns, represent Handlers and Middlewares, and adapters for all the major implementations.
Some packages are also being authored (WIP).
The goal of those packages will be to provide tool authors a mean to declare their Handlers and Middlewares once, targetting all supported servers.
Think of it as unplugin but for Handlers and Middlewares.
Definitions
Handler
A function that returns a response. Depending on the framework, a response can be anything from a standard Response, a string, an object, a ServerResponse, etc.
A standard, agnostic and future-proof way to represent a request would certainly be with the Response interface, even if it currently have some limitations.
Middleware
A function that modifies the Context or Response, and can return nothing. It can be called before and after a Handler.
Hono as a great way to represent this.
Each framework as its own way to implement middlewares.
Context
Some data with the same lifespan as a Request.
Each framework as its own way to represent the Context, either by attaching it to their internal Request representation, or by having the Context itself containing the Request.
Current state of popular servers
express
fastify
h3
hatTip
Request
(wrapped in context) and standardResponse
hono
Request
and standardResponse
elysia
TBD
Useful resources
Beta Was this translation helpful? Give feedback.
All reactions