A web server for Deno. Inspired by express et al.
This is a side project that I work on from time to time. It's mainly for learning, and not intended for real use.
import { srv } from "../mod.ts";
const app = srv({ port: 8000 });
app.get("/", ({ response }) => {
response.setBody("hello world!");
});
app.listen();
console.log(`listening: ${app.location.origin}`);app.get("/", ({ response }) => {
response.html("<!DOCTYPE html>");
});
app.get("/", ({ response }) => {
response.json({ foo: true });
});
app.get("/", ({ response }) => {
response.redirect("somewhere/else");
});// assuming a request to /some/path?with=query-string
app.get("/some/path", ({ url }) => {
console.log(url);
console.log(Object.fromEntries(url.searchParams));
});URL {
href: "http:https://localhost:8000/some/path?with=query-string",
origin: "http:https://localhost:8000",
protocol: "http:",
username: "",
password: "",
host: "localhost:8000",
hostname: "localhost",
port: "8000",
pathname: "/some/path",
hash: "",
search: "?with=query-string"
}
{ with: "query-string" }// assuming a request to /posts/programming/the-title
app.get("/posts/:category/:title", ({ params }) => {
console.log(params);
});{ category: "programming", title: "the-title" }All route handlers are passed a single object the shape of
HandlerArgs
todo
todo
todo
todo
Route handlers are automatically set up for HEAD and OPTIONS request methods.
In the same way that Deno embraces web standards, this framework should default to reusing native platform features and create minimal abstractions.
The framework should be composed of small parts. And those small parts should be exposed so that users can assemble solutions for use cases that don't match the high-level API surface.
At a high level, the API surface should be as simple as possible. The ideal interface is subjective, but there is value in emulating the patterns used in other popular frameworks.
Srv is currently handling more requests per second than most others I've
tested - see /bench/results. The testing is probably flawed
and will definitely change if/when srv is developed further. If development
continues, performance will be a key consideration.
-
automatic HEAD responses
-
automatic OPTIONS responses
-
automatic 405 responses
-
cookie parsing, (encoding/decoding?)
-
cookie signing/verification with key rotation
-
form data parsing
-
middleware?
-
etag
-
vary
-
CSP
-
server sent events
-
logging
-
optimizations - LRU cache? workers?