Why Beignet?

Beignet is for teams that want REST to stay the public API while the TypeScript application behind it stays coherent.

The differentiator is not only "contract-first." A contract-first endpoint is the starting point. Beignet's lane is the full application loop around that contract: route validation, typed clients, OpenAPI, use cases, ports, providers, auth hooks, background workflows, uploads, devtools, generators, linting, and doctor checks that all agree on the same app shape.

Use Beignet when you want a framework that keeps production TypeScript apps explicit without making every team hand-roll the same architecture.

The lane

Beignet should be understood as:

A contract-first TypeScript framework for REST applications with typed clients, explicit application boundaries, provider-backed infrastructure, runtime adapters, and first-class app tooling.

That means Beignet is intentionally not trying to be the smallest HTTP router, the fastest Bun-only runtime, or an RPC protocol. It is trying to make a production app easier to reason about after the first route becomes many features, jobs, policies, providers, clients, and deployment entrypoints.

What Beignet optimizes for

Beignet optimizes for	Why it matters
Public REST contracts	Methods, paths, params, headers, status codes, response schemas, and errors stay visible.
One source of truth	Contracts feed server validation, clients, React helpers, OpenAPI, route inspection, and docs.
Feature-first architecture	Contracts, routes, use cases, policies, ports, tests, uploads, jobs, and UI live near the feature.
Explicit infrastructure boundaries	Ports and providers keep vendor APIs out of use cases and domain code.
Operational tooling	The CLI generates slices, inspects routes, checks architecture direction, detects drift, and runs app-owned operations.
Runtime clarity	Next.js is polished, and the Web adapter proves the core can run anywhere a Fetch handler makes sense.

Compared with hand-rolled REST

Hand-rolled REST gives maximum control, but the hidden cost is drift:

request validation may not match response validation
frontend types can diverge from server behavior
OpenAPI can lag behind route code
error envelopes drift by route
architecture rules live in code review memory
operational entrypoints become one-off scripts

Beignet keeps REST explicit but connects those surfaces. You still write the business logic, repository interfaces, policies, and provider wiring. The framework supplies the contracts, validation flow, typed clients, app structure, CLI checks, and production primitives around them.

Compared with Laravel

Laravel is the mature reference point for framework cohesion: routing, validation, ORM, queues, events, mail, notifications, storage, scheduler, auth, generators, testing, and operations all feel like one product.

Beignet borrows that "whole app" ambition, but adapts it for TypeScript:

Contracts are the API source of truth, not only route declarations.
Typed clients and React helpers come from the same endpoint shape.
Ports and providers make infrastructure dependencies explicit instead of facade-driven.
Dependency-direction lint and doctor checks turn conventions into inspectable tooling.

Laravel is far more mature and still wins on batteries and ecosystem depth. Beignet's bet is stronger TypeScript API correctness plus explicit architecture.

Compared with AdonisJS

AdonisJS is the closest TypeScript framework comparison. It is backend-first, opinionated, and ships a polished set of framework features.

Beignet should not copy AdonisJS class-for-class. The difference is the center of gravity:

AdonisJS starts with a traditional backend framework model.
Beignet starts with public API contracts and extends that model into the app.

Choose AdonisJS when you want a mature TypeScript backend framework with a deep, cohesive first-party stack. Choose Beignet when contract-first REST, typed clients, OpenAPI, feature slices, ports/providers, and drift tooling are the main reason you are adopting a framework.

Compared with Hono and Elysia

Hono and Elysia are excellent HTTP frameworks. They are especially strong at route ergonomics, middleware or guard composition, runtime portability, and small-to-fast server surfaces.

Beignet is not trying to beat them at being tiny. It should learn from their composition models, but it is solving a broader application problem:

validated REST contracts
typed clients and frontend adapters
app-owned use cases and policies
ports and providers
database, outbox, jobs, schedules, mail, notifications, uploads, and devtools
CLI generators, route inspection, architecture lint, and doctor checks

If you mainly need a lightweight router, Hono or Elysia may be the better fit. If you need a framework shape for a larger TypeScript application, Beignet is trying to own more of the production workflow.

Compared with tRPC and oRPC

tRPC and oRPC optimize for procedure-first TypeScript APIs. They are excellent when the caller and server are both TypeScript and the team wants function-like API ergonomics.

Beignet keeps REST as the boundary:

non-TypeScript clients can still consume the API
HTTP methods, paths, headers, status codes, and OpenAPI stay first-class
route-owned and framework-owned errors stay distinguishable
native Response boundaries remain available for redirects, streams, files, and other transport-owned responses

The tradeoff is that procedure frameworks often feel more compact for internal apps. Beignet accepts more explicit HTTP shape in exchange for public API clarity and framework-level production structure.

Compared with ts-rest

ts-rest is the closest typed REST comparison. It is a focused toolkit for contract-first REST surfaces with typed clients, server adapters, and OpenAPI.

Beignet's difference is scope:

ts-rest is a compact typed REST toolkit.
Beignet is a framework for typed REST applications.

That means Beignet includes more concepts: use cases, route groups, hooks, ports, providers, errors, jobs, events, schedules, mail, storage, uploads, devtools, CLI generators, lint, and doctor checks. That extra surface area only pays off if you want the framework to own the app shape, not just the endpoint types.

When not to use Beignet

Do not pick Beignet if:

you only need a tiny HTTP router
your app is intentionally RPC-only
you do not want framework conventions
you need a mature, battle-tested ecosystem today
alpha API churn is unacceptable

Beignet is experimental alpha software. It is a good fit for evaluating a contract-first framework direction, building prototypes, and shaping the framework with real apps. It is not yet a stable long-term platform.