Skip to content

The Interface Exists. Before Any Logic Is Written.

Most teams decide the interface while implementing it. Jardis reverses that: the Domain API is generated typed from the schema, alongside the domain code. The API layer of every bounded context is fixed before the first line of business logic.

Learn more

API Docs That Always Lag Behind.

The code is done, the API is running. Now the docs are missing. By the time they are accurate, the interface has changed twice.

Frontend waits on backend decisions

The backend developer decides on the fly how an endpoint should look. The frontend team is blocked. Hours of coordination calls do not replace a defined contract.

API docs are always out of date

Swagger files are maintained by hand. After three sprints, the documentation no longer matches reality. Everyone knows it, no one has time to catch up.

Interfaces are designed after the fact

API design is a byproduct of implementation. Contract errors surface only when frontend and backend finally meet. By then, rework is expensive.

How Jardis Implements API-First Architecture.

Jardis generates the Domain API as part of the domain code. Not afterward, not separately. Simultaneously.

STEP 1: MODEL

Domain schema as the single source of truth

You define your database schema and aggregate structure. The builder understands which operations each bounded context should expose. The domain model is the single source of truth for both code and API.

STEP 2: GENERATE

The Domain API emerges with the domain code

Jardis generates the Domain API alongside entities, commands, queries, and domain events. Every bounded context exposes its use cases as typed commands and queries. The interface describes exactly what the builder implements. No gap between definition and reality.

STEP 3: BUILD IN PARALLEL

Frontend and backend start at the same time

The interface is fixed, straight from the model. The backend team fills the generated structures with business logic while the frontend knows every operation and its types from day one. No endpoints improvised on the fly, no surprises when the two sides finally meet.

BUILDER OUTPUT
80%
Domain code generatedEntities, commands, queries, domain events, the Domain API, and the repository pipeline. From a single builder run.
0
outdated API docs
50%
faster development through parallel teams
DOMAIN API
100%
API-code consistencyThe Domain API comes from the same source as the PHP code. What the interface describes, the builder implements.

Why Teams Adopt API-First with Jardis.

Because contracts should not be a documentation task. They should be a design principle.

> Contract-First

API Design Before Implementation

The Domain API is generated in the same builder run as the domain code. The interface is defined before the first line of business logic is written.

> Always Current

Docs That Cannot Go Stale

The API layer is not a separate document. It is generated output from the same schema as the PHP code. When the model changes, API and code change together.

> Parallel Development

Frontend and Backend Decoupled

The API layer is fixed by the model, with typed inputs and outputs. Backend teams fill the generated structures with business logic while the frontend knows the interface from the start. Both work simultaneously, without waiting on each other.

Ready to treat API design as a first-class principle?

Join the Waitlist

Frequently Asked Questions

Answers about API-First Architecture with Jardis.

The builder generates the Domain API: a typed facade per bounded context with commands and queries, typed DTOs and response objects. This interface is created alongside the PHP domain code in a single builder run. The transport to the outside, such as HTTP, you wire in the adapter.