Architecture

On This Page

Mateu’s architecture is intentionally simple.

At a high level, it has three pieces:

1. UI definition lives in the backend

You define your UI using backend code.

In Java, that usually means classes, annotations, fields, and actions.

The frontend does not need a hand-built application-specific API.

Instead, Mateu exposes a small, generic protocol that the renderer can consume.

A frontend renderer converts the backend definition into visible components in the browser.

That renderer can produce forms, layouts, tables, actions, and more.

One of Mateu’s most important architectural decisions is that the UI interaction model is stateless.

That makes it a strong fit for:

Because frontend and backend communicate through a simple API, both sides can evolve independently.

That means you can:

A practical way to use Mateu is to let each microservice own both its domain logic and the UIs related to that domain.

For example, a users service can expose its own routes, menus, and CRUD screens, while other services expose different UI fragments.

Those services can still communicate through protocols such as gRPC, while Mateu keeps the UI definition close to the backend that owns the behavior.

Mateu does not require flattening your backend into UI-driven code.

A CRUD can sit on top of:

That means you can keep a clean architectural separation while still generating the UI declaratively.

Mateu turns backend objects into real UIs through a simple API and a pluggable renderer.