How do their APIs compare?

Here's a comparison of the two frameworks' APIs, based on what's in the retrieved data plus general architecture visible in the source:

koajs/koa: minimal, middleware-centric API

Koa's API surface is intentionally tiny — the README notes the whole codebase is only "~570 SLOC" and that "Koa is not bundled with any middleware." The entire public API is built around a handful of primitives:

• new Koa() — creates the app instance.
• app.use(fn) — registers middleware, either async (ctx, next) => {} or the older common-function style (ctx, next) => next().then(...) [tests/application/use.test.js:L36-L75]. Middleware composes in a "stack-like" onion fashion — this is directly demonstrated by the test that pushes call-order markers and asserts the interleaved execution [1, 2, 3, 4, 5, 6] [tests/application/use.test.js:L40-L67].
• app.callback() — returns a (req, res) handler compatible with Node's raw http.createServer.
• app.createContext(req, res) — internally builds the per-request ctx object by prototypally linking context, request, and response, wiring ctx.req, ctx.res, ctx.app, and ctx.state = {} [lib/application.js:L213-L228].
• ctx.body — a single assignable property that drives the response; Koa inspects its type (string, Buffer, Stream, Response-like object, JSON) and responds accordingly. Tests show it accepting whatgl-fetch Response objects with ReadableStream or Blob bodies [tests/application/respond.test.js:L692-L731], plain Node streams with automatic cleanup on replacement [tests/response/body.test.js:L156-L238], and null for empty responses with correct content-length handling [tests/application/respond.test.js:L1128-L1157].
• Error handling is a single onerror method plus an 'error' event you listen to on the app [lib/application.js:L236-L243], [tests/response/flushHeaders.test.js:L131-L145].

There's no built-in router, no DI, no decorators — Koa gives you the request/response lifecycle primitives and lets the ecosystem (koa-router, koa-bodyparser, etc.) supply everything else.

nestjs/nest: opinionated, framework-scale API

Nest's API is much larger and structured, built on TypeScript decorators, dependency injection, and modules — none of that is in the retrieved chunks directly (which are mostly tsconfig/CONTRIBUTING boilerplate), but the README excerpt confirms the architecture: Nest "combines elements of OOP, FP, and FRP" and, "under the hood... makes use of Express, but also provides compatibility with... Fastify" [Readme.md:L24-L29]. That means:

• Nest's API includes @Module(), @Controller(), @Injectable(), decorators for routes (@Get(), @Post(), etc.), pipes, guards, interceptors, and exception filters — a much richer, class-based, declarative surface compared to Koa's plain-function middleware.
• It's platform-agnostic at the HTTP layer, abstracting over Express or Fastify, whereas Koa is the HTTP abstraction layer itself (a thinner replacement for raw Express-style middleware).
• The integration/*/tsconfig.json files show Nest's monorepo structure, with packages like @nestjs/core, @nestjs/common, @nestjs/microservices, @nestjs/websockets, @nestjs/testing, and platform adapters (@nestjs/platform-express, @nestjs/platform-socket.io, @nestjs/platform-ws) [integration/cors/tsconfig.json:L14-L30] — indicating Nest's API spans HTTP, WebSockets, and microservices as first-class citizens, unlike Koa which only addresses HTTP.

Summary of the contrast