Why Kynetra FX

Kynetra FX was built because every major TypeScript web framework makes at least one of two mistakes: it ties you to a single runtime, or it forces you to learn a proprietary abstraction that drifts from the platform. Kynetra FX makes neither mistake.

The 11-framework synthesis#

Before writing a single line of Kynetra FX, the team audited 11 production frameworks — Express, Fastify, Hono, Elysia, Nitro, Remix, SvelteKit (server layer), tRPC, Zod-Router, Itty Router, and Worktop — cataloguing what each one got right and where each one showed its age or its constraints. The result is a set of first-principles decisions:

• Router from Hono / Itty Router: radix-tree routing with explicit match-score precedence (static beats dynamic beats wildcard) rather than first-match wins.
• Onion middleware from Express / Koa: await next() gives middleware full control over pre- and post-processing without requiring framework-specific hooks.
• Contract layer from tRPC / Zod-Router: type-safe input/output validated at the boundary, with the validated value surfaced on ctx rather than re-parsed in each handler.
• Port interfaces from Fastify / Nitro: adapters swap without touching business logic; in-memory fakes ship with the framework so tests never need external services.
• Plugin/hook model from Fastify: named plugins with dependency ordering, lifecycle hooks (onBoot, onClose, onError), and app-level decorators.
• Context object from Elysia: a single ctx that carries the request, response helpers, params, cookies, state, and decorations — no juggling multiple arguments.

Not a Hono wrapper#

Kynetra FX shares Hono's Web-Standards commitment but is a separate implementation. The two differ in meaningful ways:

• Kynetra FX has a first-class contract layer (app.route()) that drives validation, OpenAPI generation, and the typed client from a single declaration — Hono requires third-party libraries for each.
• Kynetra FX ships a plugin system with dependency ordering and lifecycle hooks; Hono does not have a comparable primitive.
• Kynetra FX's port interfaces (KvPort, StorePort, QueuePort, VectorPort, etc.) mean your business logic never imports a runtime-specific SDK.
• Kynetra FX includes an opinionated SaaS kernel, RBAC, and auth layer — batteries that Hono deliberately omits.

Build once, run anywhere#

Every Kynetra FX app exposes a single entry point:

import { createFX } from '@kynetra/fx'
const app = createFX()
app.get('/', (ctx) => ctx.text('ok'))
return { fetch: app.fetch }

That same export works on Cloudflare Workers (via the cloudflare(app) adapter), Bun (Bun.serve({ fetch: app.fetch })), Deno (Deno.serve(app.fetch)), and Node.js (via the @kynetra/fx-node adapter). The runtime adapter is the only thing that changes between deployments.

This is not just a marketing claim — it is enforced by architecture. Kynetra FX never imports Node.js built-ins (http, fs, crypto) in the core package. All runtime-specific code lives in adapter packages. The port interfaces ensure that even persistence and queuing remain runtime-agnostic.

TypeScript first, not TypeScript optional#

Kynetra FX is written in TypeScript and designed so that the type system does real work. The contract layer propagates types from your schema declarations through to handler arguments and client call sites. You define a schema once:

import { createFX, fx } from '@kynetra/fx'
 
const app = createFX()
 
const createUserInput = fx.object({
  name: fx.string().min(1),
  email: fx.string(),
  role: fx.enum(['admin', 'member']),
})
 
app.route({
  method: 'POST',
  path: '/users',
  input: createUserInput,
  handler(ctx) {
    // ctx.input is fully typed: { name: string; email: string; role: 'admin' | 'member' }
    const { name, email, role } = ctx.input
    return ctx.json({ id: '1', name, email, role }, { status: 201 })
  },
})

The same schema generates a JSON Schema for OpenAPI, validates the incoming request body (returning a 422 with structured error details on failure), and types the return value of the generated client — all from one declaration, zero redundancy.

When to choose Kynetra FX#

Good fits

• APIs that must run on Cloudflare Workers today but may move to Bun or Node later.
• SaaS products that need auth, RBAC, multi-tenancy, and audit logging without wiring five separate libraries together.
• Teams that want a single framework across edge functions, background workers, and API servers.
• Projects that need a typed HTTP client generated from the same contracts as the server.
• Applications that integrate WASM guests (Rust, C#, JavaScript-via-ClearScript) as first-class route handlers.

Cases where another tool may fit better

• You need SSR or file-system routing — Kynetra FX is an API/middleware framework, not a full-stack meta-framework. Pair it with Next.js, Remix, or SvelteKit for the frontend layer.
• You have an existing Express or Fastify codebase and cannot afford a rewrite — see the migration guides.
• You need a minimal, zero-dependency router with no opinions — Hono or Itty Router are excellent choices in that niche.