Comparisons

The fastest way to place Beignet: most typed-API tools stop at the HTTP boundary, and most application frameworks treat the HTTP boundary as an afterthought. Beignet is built on the bet that the two halves belong to one model — the same contract that validates a request also types the client, generates OpenAPI, and hands off to a use case that lives in an enforced application architecture with ports, providers, background work, and devtools.

If you only want one of the halves, one of the tools below is probably a better fit, and this page tries to say so honestly.

The short version

tRPC

tRPC gives full-stack TypeScript teams typed server procedures that feel like local function calls. It deliberately hides HTTP — methods, paths, and status codes are transport details — which is exactly right for internal APIs where both ends are TypeScript and ship together.

Beignet keeps the opposite bet: REST is the public API. Methods, paths, headers, status codes, and error shapes are explicit in the contract, so the same API serves your own frontend, non-TypeScript consumers, OpenAPI docs, and anything else that speaks HTTP — without a second API layer bolted on later.

Choose tRPC when the API is private to one TypeScript codebase, you want procedure-call ergonomics with middleware-chained context, or you need subscriptions and WebSockets, which Beignet does not have.

Choose Beignet when the HTTP surface is a product requirement — public APIs, mobile clients, webhooks, OpenAPI — or when you want the framework to also answer what happens behind the procedure: where use cases, policies, jobs, and infrastructure live.

ts-rest

ts-rest is the closest comparison at the contract layer: a compact object DSL for typed REST contracts shared between server and client, with response validation, React Query hooks, and OpenAPI generation. As a focused library it is easy to adopt incrementally inside an existing app, and its nested router contract shape is very discoverable.

Beignet's contract layer covers the same ground with a builder grammar (defineContractGroup().namespace(...).prefix(...)), but the differentiator is everything after the contract: a canonical app structure, use cases with validated inputs and outputs, ports and providers for infrastructure, an error catalog with route-owned errors, a workflow tier (events, jobs, schedules, tasks, notifications, uploads, a transactional outbox, idempotency), generators, architecture linting, doctor checks, and a devtools dashboard.

Choose ts-rest when you want typed REST inside an architecture you already own, with broader server adapter coverage (Express, Nest, Fastify, serverless) today.

Choose Beignet when you are starting an application and want the typed REST boundary and the application model behind it to come from one tool that enforces its own conventions.

oRPC

oRPC is a strong philosophical neighbor: no-codegen type safety, Standard Schema support, typed errors, and both RPC and OpenAPI transports, with wide adapter coverage across runtimes and frameworks. Its procedure builders and typed middleware are excellent at the transport layer.

The trade is the same as ts-rest but with an RPC accent: oRPC is a procedure layer you bring into your own architecture, and its OpenAPI story sits alongside an RPC protocol rather than REST being the only shape. Beignet has no RPC mode — REST is the boundary — and spends its complexity budget on the application framework instead: feature folders, dependency-direction linting, provider-backed infrastructure, background work, and tooling that keeps generated apps conformant.

Choose oRPC when you want procedure composition with maximum runtime flexibility and are happy owning the rest of the stack.

Choose Beignet when you want the REST contract and the production app structure to be the same opinionated system.

Hono

Hono is a fast, minimal web framework that runs everywhere fetch does, with typed routes via its RPC client and OpenAPI support through extensions. It is a router with excellent ergonomics — and deliberately not an application framework. Architecture, validation conventions, background work, and infrastructure wiring are yours to design.

Beignet sits a full layer up. Contracts are schema-first rather than route-handler-first, and the framework owns the answers Hono leaves open: where business logic lives, how infrastructure stays swappable, how jobs and events get reliability guarantees, and how drift gets caught (beignet lint, beignet doctor). Beignet's server core is runtime-portable through the same fetch standard — Next.js is the first-class adapter, and @beignet/web serves Cloudflare Workers, Bun, Deno, and Node fetch servers.

Choose Hono when you want a minimal, very fast HTTP layer and intend to build your own conventions on top.

Choose Beignet when you want the conventions included and enforced, and REST contracts as the source of truth rather than handler inference.

NestJS

NestJS is the most established Node application framework: modules, decorators, dependency injection, guards, pipes, interceptors, and an enormous ecosystem. It shares Beignet's belief that applications need structure, and it has a decade of production hardening Beignet cannot claim.

The differences are philosophical. Nest's structure comes from class decorators and a runtime DI container; types describe the code but the HTTP contract lives in decorator metadata, and end-to-end client typing or OpenAPI fidelity require additional layers. Beignet is functions and inference all the way down — the contract is a value, the client and OpenAPI derive from it, and architecture rules are enforced by static linting rather than a container. Beignet's ports are plain interfaces wired explicitly in infra/, not injected tokens.

Choose NestJS when you want a mature, hireable, batteries-available framework and your team likes explicit OOP structure.

Choose Beignet when end-to-end type inference from a single contract matters more than ecosystem breadth, and you prefer functional composition to decorators and DI containers.

AdonisJS

AdonisJS is the closest framework to Beignet's ambition: TypeScript-first, batteries included, with an ORM, auth, validation, mail, events, a CLI, and a testing story — Laravel's philosophy executed natively in TypeScript. If the question is "a real application framework, in TypeScript," Adonis is the incumbent answer, with years of production use behind it.

The split is in where types come from and where the app runs. Adonis is MVC: routes point at controllers, validators guard inputs, and the HTTP contract is an emergent property of handler code — typed clients and OpenAPI need additional packages and generation steps. Beignet inverts that: the contract is a standalone value, and the server, client, React Query options, forms, and OpenAPI all infer from it with no generation step. Architecture differs the same way — Adonis structures the app through an IoC container and service providers, where Beignet uses plain-interface ports wired explicitly in infra/ and enforced by static linting. And Adonis assumes a long-running Node server, while Beignet is built for the Next.js/serverless deployment model first.

Choose AdonisJS when you want a proven TypeScript monolith with the batteries already attached, you deploy long-running servers, and contract-derived client types are a nice-to-have rather than the point.

Choose Beignet when the contract-first boundary and no-codegen inference across the whole stack are the point, or your deployment target is serverless/Next.js rather than a persistent Node process.

Laravel and Rails

Laravel and Rails are the high-water mark for application frameworks: ORM, migrations, queues, mail, notifications, scheduling, policies, file storage, testing culture, deployment ecosystem, and conventions deep enough that any experienced developer can navigate any codebase. Beignet borrows their best idea — a canonical place for everything — openly.

What they cannot offer is the TypeScript contract story: one definition that types the server, the client, the forms layer, and the OpenAPI document with no codegen step. Beignet's equivalents of the application tier exist and are real — Drizzle-backed persistence across SQLite, Postgres, and MySQL with a unit of work, transactional outbox, idempotency storage, typed jobs, events, schedules, tasks, notifications, mail, uploads, policies — but they are years younger, and the ecosystem of packages, hosting recipes, and answered questions is a fraction of the size.

Choose Laravel or Rails when maturity, ecosystem, and hiring outweigh language choice, or the app is server-rendered with modest API needs.

Choose Beignet when the stack is TypeScript end to end and you want framework-grade structure without giving up typed contracts as the source of truth.

What Beignet deliberately doesn't do

Honest scope, stated once:

• No RPC protocol, no subscriptions, no WebSockets — REST and standard Response are the boundary.
• OpenAPI generation requires Zod schemas; runtime validation accepts any Standard Schema library.
• Next.js is the first-class server adapter; other runtimes go through the fetch adapter in @beignet/web rather than per-framework adapters.
• Pre-1.0: APIs can change between 0.0.x releases while the framework settles.

If those constraints fit, the rest of the docs show what the coherence buys: start with the mental model or build your first feature.