feTS: a TypeScript HTTP framework built on the fetch API

Fetch, TypeScript, and a small core

feTS describes itself as a fully-featured HTTP framework to build REST APIs with a focus on easy setup, performance, and developer experience, and the subtitle of the project is fetch API and TypeScript.

The fetch framing is the interesting part, because it is a departure from the usual Node server story. A framework built on the fetch request and response objects is working with the web platform interfaces rather than with the Node specific ones, and the consequences show up in the topic list, which includes the fetch API, the WHATWG name, and the WHATWG fetch implementation.

The second headline is end to end type safety, and that is the feature the rest of the project is organised around. The intent is that the types of a request and its response are derived rather than declared, so a change to the implementation changes the types, and the consumer sees the change at compile time rather than at run time.

The topics also mention JSON Schema, OpenAPI, Swagger, and Zod, which is the toolchain that a type safe API framework in this style is usually built on. A schema is the source of truth, the types come from the schema, and the OpenAPI document comes from the same place, so the schema, the types, and the published documentation cannot drift apart.

The project is MIT licensed, the site is fets.dev, and the last push was on 2026-10-19. The release tags are machine generated, with a timestamp and a date, which is the signature of a continuous release process rather than of a hand cut version, and the three most recent are from March, June, and August 2026.

The examples are the documentation

The README is short, and it points at two places, the documentation website and the examples directory, and the examples are the more informative of the two for judging the project.

There are ten of them, and the list is a good description of what the framework is for. There is an auth example, a todolist, a nextjs example, a clickhouse one, a fireblocks one, a navitia one, a soccer-stats one, and a spotify one. There is a trpc-openapi example and a typebox example, and those two are the interesting ones because they pair the framework with other schema and type tooling, which is the clearest signal of where it sits in the ecosystem.

The mix tells you something specific. An example against a database, an example against a payments API, an example against a transit data API, and an example against a music API are not toy applications, they are integrations, and building them means the framework handles the parts that come up when the data is not shaped like a to-do list: a third party response that does not match the schema, an error, an authentication handshake, a rate limit.

The README says the point of the examples is that developers can quickly start with feTS, and that the set is comprehensive, and the examples directory in the repository matches that list of ten.

The nextjs example is worth singling out, because a server framework that sits inside a Next application is a different use from a standalone service, and the fact that it is one of the ten says the framework is intended for both. The typebox example says the same about schema libraries, since the framework is designed to work with the one you already use rather than to insist on its own.

uWebSockets.js underneath

The dependency list in the root manifest has exactly one entry, and it is not a typical one.

It is uWebSockets.js, pinned to a specific tag of the upstream repository rather than to a version on the package registry, at tag 20.71.0. Everything else in the manifest is development tooling.

That tells you a lot about the performance story. The framework is not running on the Node HTTP server, it is running on a WebSocket and HTTP server written in C++, which is a common choice for a Node framework that cares about throughput and about the overhead of a request. uWebSockets.js is the same server that a number of other performance oriented frameworks use.

Fetching it from a repository rather than from the registry is a deliberate choice with a practical consequence. The code is exactly the tagged release, and the dependency is not a published version that the registry could have resolved, so the build depends on the network reaching that repository, and the version is visible in the manifest as a hash and a tag.

The other notable entry is in the postinstall script, which runs patch-package and then a script that shims the TypeScript 7 API. The shim is the interesting part, because it means the framework is being kept working against a TypeScript version whose API has changed underneath it, and doing that in the install step rather than by pinning an older compiler.

That is a maintenance cost of working at the edge of the language, and it is the kind of thing worth knowing about before you adopt a framework whose internals are tied to a specific compiler release.

The build pipeline, and the OpenAPI step

The scripts in the root manifest describe a pipeline that is unusual in one respect, and that respect is the point of the project.

The unusual part is that generating the Swagger user interface and generating the landing page are not separate manual tasks. They are wired into the build, the test, the type check, and the lint run, so that the published documentation and the landing page cannot fall behind the code.

  "workspaces": [
    "website",
    "packages/*",
    "e2e/*",
    "examples/*",
    "benchmark"
  ],

The workspaces tell you the shape of the repository, with the website, the packages, the end to end tests, the examples, and a benchmark each being a workspace, which means the benchmark and the end to end tests are run through the same tooling as the library rather than being separate scripts.

The test command runs jest with the open handle and leak detection flags, which is what you want in a test suite that starts servers. There is a separate integration test target that sets an environment variable, so the same runner can behave differently, and there is a separate type check with no emit.

Releases go through changesets. The version and publish steps are the changeset commands, the changelog is generated, and there is a changeset directory at the root of the repository with the configuration for the changelog generator. The release tags in the repository are machine generated, with a timestamp in the name, which is consistent with a pipeline that publishes whenever a changeset is merged.

The build itself uses bob, and there is a check step for the ES module output, which is the kind of check that catches a bundling regression before it reaches a user.

Open source governance, and where the project sits

The contributing section points at a workflow guide and a code of conduct that come from the Guild, the organisation behind a family of open source GraphQL and TypeScript projects, and the code of conduct is adopted from the Contributor Covenant.

That is worth noting because it says something about the project's lineage. The author of feTS is also the author of tRPC and of GraphQL Code Generator, and the three projects share a concern with type safety across a network boundary. feTS is the third of them, and it is the one that puts the idea in a plain HTTP framework rather than in a GraphQL transport.

The sponsorship section asks for support on the grounds that it is built and maintained in the open for everyone who wants to create reliable, type safe APIs with TypeScript, and it says what the money is for, ongoing maintenance, better documentation, performance improvements, and new features. The same paragraph makes the point that every contribution helps keep the project healthy.

The rest of the repository is the ordinary furniture of a modern TypeScript monorepo. There is an eslint configuration in two generations, a prettier configuration, a husky directory for the git hooks, a patches directory for the patched dependencies the postinstall script applies, a scripts directory, a benchmark directory, an end to end test directory, a website directory, and a renovate configuration for the dependency updates.

And there is a file at the root that is an instruction set for an assistant, which is a growing convention and a reasonable one for a project that wants its contributions to arrive in a consistent shape.

Taken together, the picture is of a young framework with a serious toolchain, a clear thesis about type safety, and an author who publishes the reasoning alongside the code.

Editorial conclusion

feTS fits a TypeScript team that wants the request and response types of an API to be inferred rather than maintained by hand, and that wants a schema in the repository to drive both the server and the documentation. It does not fit a project that needs the full framework, since the fetch based core is deliberately small and a lot of the conventional middleware is absent. Verify first that the type inference works end to end for the shape of the API, that the OpenAPI generation step in the build produces something usable for the consumers of the service, and that the choice of a git pinned uWebSockets.js dependency is acceptable for how the project is deployed, since it is fetched from a repository rather than from the registry.

Frequently asked questions

Official sources

1. ardatan/feTS on GitHub
2. License: MIT
3. Project website
4. README
5. Releases