Why srvx

When you want to create a HTTP server using Node.js, you have to use node:http module.

Example: Node.js HTTP server (learn more):

import { createServer } from "node:http";

const server = createServer((req, res) => {
  res.end("Hello, Node.js!");
});

server.listen(3000, () => {
  console.log(`Server running at http://localhost:3000/`);
});

Whenever a new request is received, the request event is called with two objects: a request req object (node:IncomingMessage) to access HTTP request details and a response res object (node:ServerResponse) that can be used to prepare and send a HTTP response. Popular framework such as Express and Fastify are also based on Node.js server API.

Recent JavaScript server runtimes like Deno and Bun have a different way to define a server which is similar to web fetch API.

Example: Deno HTTP server (learn more):

Deno.serve({ port: 3000 }, (_req, info) => new Response("Hello, Deno!"));

Example: Bun HTTP server (learn more):

Bun.serve({ port: 3000, fetch: (req) => new Response("Hello, Bun!") });

As you probably noticed, there is a difference between Node.js and Deno and Bun. The incoming request is a web Request object and server response is a web Response object. Accessing headers, request path, and preparing response is completely different between Node.js and other runtimes.

There are subtle differences between Deno and Bun too in the way to provide options, server lifecycle, access to request info such as client IP which is not part of Request standard are some examples.

Main use-case of this library is for tools and frameworks that want to be runtime agnostic. By using srvx as standard server layer, instead of depending on of the individual runtime APIs, we push JavaScript ecosystem to be more consistent and moving towards web standards!

How is it different?

You might ask, what is the difference between srvx and other HTTP frameworks like h3, Nitro, and Express?

Srvx provides a simple, low-level, and universal API, very similar to Deno and Bun. It has no conventions, utilities, or router, and in most cases, using srvx introduces zero overhead.

We plan to adopt srvx as the runtime-agnostic server API across the ecosystem (h3, Nitro, Listhen, and more). So if you're using one of these today, you'll soon benefit from srvx without even needing to read this documentation!

The idea of srvx was extracted from the h3 v2 development branch and opened to a broader ecosystem to encourage the adoption of Web platform standards without enforcing it's own conventions.