modular_api

Every operation is a UseCase — typed Input, typed Output, a validate() step and an execute() step. Validation, business logic and HTTP stay apart because the framework has no layer that mixes them.

CQRS is structural: commands travel over REST, queries over GraphQL. The OpenAPI specification and the GraphQL schema are generated from the use cases.

Every server ships these, with no configuration:

/docs

Browsable documentation, generated from the use cases.

/health

Liveness, with no configuration.

/openapi.json

The specification, as a consequence of the code.

/openapi.yaml

The same, for readers who prefer it.

/metrics

Opt-in.

Dart below. The same model is available in TypeScript and Python.

dependencies:
  modular_api: ^1.0.0

import 'package:modular_api/modular_api.dart';

Future<void> main() async {
  final api = ModularApi(
    basePath: '/api',
    title: 'My App',
    version: '1.0.0',
  );

  api.module('clients', (m) {
    m.usecase('create', CreateClient.fromJson);
    m.usecase('list',   ListClients.fromJson);
  });

  await api.serve(port: 8080);
}

# Commands travel over REST
curl -X POST http://localhost:8080/api/clients/create \
  -H "Content-Type: application/json" \
  -d '{"name":"Acme"}'

# Queries travel over GraphQL, generated from the same use cases
# Docs   http://localhost:8080/docs
# Spec   http://localhost:8080/openapi.json