Application patterns¶
Use a pattern to study how models and API actions fit together. For your first working application, follow the Ticket Desk tutorial: it supplies the identity adapter, migrations, and positive/negative tests that these older domain examples do not.
| What you want to learn | Example | Boundary |
|---|---|---|
| Related content and explicit state changes | Blog | Post and Comment; local domain demonstration, not a complete protected publishing application. |
| Customer relationships and sales actions | CRM | Customer, Deal and Activity; illustrative pipeline logic, not a production CRM or accounting system. |
| Authenticated tenant isolation | Ticket Desk tenancy | The recommended path, with server-owned tenant identity and restricted-role PostgreSQL RLS. |
| Historical tenant middleware design | Multitenant example | Known resolver defect; retained for inspection, not an isolation reference. |
Templates and examples are different starting points¶
aksara templates list lists basic, blog, crm, and multitenant.
The default basic template generates a project shell with commented model/API
examples, a project configuration, and setup guidance. The three domain templates
copy their bundled example files into a flat directory. They do not have the
same layout or defaults as basic.
Use Choosing a starting point before generating
a project. Follow the specific pattern page's commands for domain templates:
older CLI output can suggest the basic layout for every template. In particular,
do not assume an app/ package,
pyproject.toml, or .env exists.
Adapt a pattern deliberately¶
Start with the domain model, then decide which operations each actor may perform. A publish flag or deal stage is application state, not a Durable Operation. An API-key helper does not by itself establish the Principal used by generated write permissions. Custom HTTP actions also need explicit authorization checks; see the action contract before exposing one.
Use the checked references when adapting an example:
- Relations for foreign-key storage and eager loading.
- Serializers for input validation and output shaping.
- Authentication and permissions for identity and allowed operations.
- Durable actions when a delayed or retried mutation needs current authorization and recovery.
- MCP client tutorial for an authenticated tool consumer. Model metadata alone does not mount a safe protocol endpoint.
Optional Studio and AI settings in historical examples are experimental. Their presence is not a requirement for an ordinary backend, nor evidence of a tested provider integration.