MaleusMaleus

A modular, secure-by-default API

See how the foundation structures the API, closes routes by default, and separates functional modules from technical building blocks.

In the appApplication · BackendUpdated September 19, 2026
On this page

The backend delivered with a Maleus application is not a collection of routes generated on the fly. It starts as a modular monolith: a single unit that is simple to deploy, divided into functional modules that isolate responsibilities, data, and dependencies.

Security starts with a closed route

An authentication guard applies globally. Each route must explicitly declare one of the following two contracts:

  • @Auth, with the required action or capability;
  • @PublicApi, for an intentionally public route.

A route with no configuration is rejected. So is a route marked as both private and public. This rule turns a security oversight into a visible error instead of silently exposing an endpoint.

Inputs are validated with Zod schemas. The same contracts feed the OpenAPI documentation and generated clients. HTTP errors follow a shared format, cookies are signed, request body sizes are limited, and cross-origin SDK routes are isolated in an explicit list without browser credentials.

The frontend improves the experience by hiding or blocking unavailable actions. The API always performs the check again: it remains the security boundary.

A modular monolith, not an undifferentiated block

A feature generally follows four areas:

  1. presentation receives and validates requests;
  2. services implements use cases and business rules;
  3. data contains tables and repositories;
  4. tests lock in expected behavior.

The shared core brings together identity, tenants, groups, security, the database, SSO, and API keys. Business domains live in their own modules. Infrastructure clients, such as PostgreSQL, RabbitMQ, S3, or a third-party API, are injected behind interfaces.

This separation lets you replace an integration, test a service without its real provider, and evolve a module without spreading its logic throughout the application.

01HTTP contractAuthentication, validation, actions, and normalized errors
02Use casesBusiness rules and orchestration inside each functional module
03DataTenant-aware repositories, transactions, and migrations
04InfrastructurePostgreSQL, S3, RabbitMQ, Redis, and third-party APIs
One deployable backend, separated into functional and technical modules.

Contracts across the entire stack

A request schema does more than reject an invalid value. It becomes a connection point between:

  • the HTTP controller;
  • runtime validation;
  • the OpenAPI contract;
  • the TypeScript client;
  • contract tests.

To add a business operation, you therefore describe its input, output, security action, and owning module. The frontend client then consumes a typed API rather than URLs and objects rebuilt by hand.

Reusable primitives around the modules

The foundation also provides shared libraries for needs that recur from one application to another:

  • authentication and session rotation;
  • OIDC and SAML SSO;
  • application-level encryption;
  • S3 storage and presigned URLs;
  • transactions, repositories, and migrations;
  • structured logs and normalized errors.

These building blocks speed up a new domain without deciding its business model, retention, or access rules.