ENTITY_NAME in a path is a placeholder for your generated entity directory, for example product for Product. EntityName denotes its code type. Replace these with actual project names; the Article examples below illustrate an entity rather than a required project module.
These decisions determine where to make changes and which dependencies to maintain. Each has a benefit and a tradeoff: what generation simplifies and what remains your responsibility.
Modular monolith
Application use cases are separate packages assembled into one backend. This reduces inter-service infrastructure. Independent module releases or scaling require changes to architectural boundaries; adding a folder is not enough.
backend/internal/app/<entity>/
Consumer-owned interfaces
App declares Repository and Hooks; bootstrap supplies implementations. Use cases do not depend on a specific PostgreSQL adapter. This separation requires explicit interfaces and composition code kept consistent with one another.
app/ENTITY_NAME/service.go
generated/bootstrap/app.go
Explicit SQL and pgx
SQL queries and row mapping are visible in source without an ORM layer. You can inspect their behavior directly. PostgreSQL-specific features and complex queries still require SQL and database knowledge.
adapters/postgres/generated/ENTITY_NAME_repository.go
ENTITY_NAME_queries.sql
UI beside its entity
Article forms, lists, types and custom components belong to one feature. Shared code is reused through shared. Cross-entity workflows need explicit coordination rather than arbitrary mutual imports.
admin/src/features/ENTITY_NAME/
Preserved custom files
seed_if_missing creates a file only if absent and preserves an existing implementation. The contract can still change with the model. Developers check and maintain extension and full-page replacement compatibility.
backend/internal/custom/
features/ENTITY_NAME/custom/
SQL history grows through new steps
Schema changes become subsequent migrations rather than rewrites of earlier files. The history shows transitions between database states. Complex data transformations and recovery still need a separate plan.
backend/migrations/
One declarative model
Backend, standard UI and OpenAPI come from one description. Configure standard capabilities through Generator UI or CLI; implement application-specific behavior in custom. Generation is repeatable within the capabilities supported by the model.
.admingen/project.yaml
In the generator: internal/domain/normalized/ and templates/