How do their APIs compare?

These two repos serve fundamentally different purposes, so their "APIs" aren't really comparable in a head-to-head sense — but let me break down what each actually exposes.

koajs/koa: a runtime middleware API

Koa exposes a small, object-oriented runtime API centered on four objects: Application, Context, Request, and Response. The core interaction model is:

• Middleware registration via app.use(fn), where fn is either an async function or a common function taking (ctx, next) — shown in the Readme examples [Readme.md:L88-L141] and exercised in tests like [tests/application/use.test.js:L36-L75], which demonstrates composing mixed async/sync middleware and verifying execution order (onion-style: downstream then upstream).
• Request/Response delegation — rather than extending Node's native IncomingMessage/ServerResponse, Koa wraps them with getter-based property APIs. For example, request.protocol [lib/request.js:L411-L416], request.secure [lib/request.js:L429-L431], request.fresh/request.stale [lib/request.js:L321-L342], and request.idempotent [lib/request.js:L352-L355] are all plain JS getters computed from underlying Node objects. Similarly response.status is a getter/setter pair over res.statusCode [lib/response.js:L73-L83].
• Context shortcuts — ctx delegates to both request and response so you can write ctx.body instead of ctx.response.body [Readme.md:L128-L134].
• Small internal utilities like lib/search-params.js (custom querystring stringify/parse, tested in [tests/lib/search-params.test.js:L1-L40]) support the request API without being part of the public surface.

So Koa's API is imperative, stateful per-request, and designed to be composed at runtime inside a running HTTP server.

trekhleb/javascript-algorithms: a library of pure functions/classes

This repo isn't a framework — it's a reference collection of algorithm and data-structure implementations, each exposing simple, stateless function or class APIs meant to be imported and called directly, e.g.:

• Cipher functions like encodeRailFenceCipher(str, base) / decodeRailFenceCipher(str, base) [src/algorithms/cryptography/rail-fence-cipher/test/railFenceCipher.test.js:L1-L26], or the Caesar cipher concept described in [src/algorithms/cryptography/caesar-cipher/README.md:L10-L25].
• Graph traversal APIs like breadthFirstSearch/depthFirstSearch that accept a Graph, a starting vertex, and callback hooks (enterVertex, leaveVertex) invoked with { currentVertex, previousVertex } — see [src/algorithms/graph/depth-first-search/test/depthFirstSearch.test.js:L141-L166] and [src/algorithms/graph/breadth-first-search/test/breadthFirstSearch.test.js:L71-L110]. This callback pattern is the closest thing to Koa's middleware pattern in spirit (visitor callbacks), but it's synchronous graph traversal, not async HTTP middleware.
• Documentation-first algorithms like polynomial hashing [src/algorithms/cryptography/polynomial-hash/README.md:L3-L15] and seam carving [src/algorithms/image-processing/seam-carving/README.md:L7-L16, L118-L125], where the "API" is really just an exported function per algorithm folder.

Key contrasts

Aspect	koajs/koa	javascript-algorithms
Purpose	Runtime HTTP middleware framework	Educational algorithm/data-structure reference
API shape	Stateful objects (ctx, app) with getters/setters	Pure functions/classes per algorithm
Composition	Async middleware chain via next()	Callback hooks for traversal (enter/leave vertex)
Surface size	Small, deliberately minimal (~570 SLOC per README)	Large, one module per algorithm across many folders
Consumption pattern	app.use(), then app.listen()	import { fn } from '...'; fn(args)

In short, Koa's API is about orchestrating request/response lifec