DocsEcosystems

Multi-Ecosystem

Compose one Better Fullstack project from frontend, backend, database, and mobile parts across ecosystems.

Multi-Ecosystem mode models a project as connected stack parts instead of one flat ecosystem selection. Use it when a product spans languages: a TypeScript frontend, a Go API, a shared PostgreSQL database, and a React Native app in one workspace. Open it in the Stack Builder or pass repeated --part flags.

Stack parts

Each part has the shape role:ecosystem:tool, or owner.role:ecosystem:tool when the role attaches to a parent part:

Example	Meaning
`frontend:typescript:next`	Generate a TypeScript Next.js frontend.
`backend:go:gin`	Generate a Go Gin backend.
`backend.orm:go:gorm`	Attach GORM to that backend.
`backend.api:rust:tonic`	Attach Tonic gRPC to a Rust backend.
`database:universal:postgres`	Add a shared PostgreSQL database part.
`mobile:kotlin:jetpack-compose`	Generate a Kotlin Jetpack Compose app.
`mobile:swift:swiftui`	Generate a SwiftUI app.
`frontend:dotnet:blazor-webassembly`	Generate a standalone Blazor WebAssembly frontend.

Top-level roles describe generated apps or shared infrastructure. Owned roles attach capabilities such as ORM, API, auth, or libraries to their owner.

Scripted example

npm create better-fullstack@latest my-mixed-app -- \  --part frontend:typescript:next \  --part backend:go:gin \  --part backend.orm:go:gorm \  --part backend.auth:go:jwt \  --part database:universal:postgres \  --part mobile:kotlin:compose-multiplatform \  --part mobile.libraries:kotlin:ktor-client \  --part workspaceRunner:universal:turborepo \  --part containerOrchestration:universal:docker-compose

Source of truth

Multi-ecosystem projects write stackParts to bts.jsonc, and those parts drive generated structure, history, and reproducible commands. Legacy flat fields may still appear as compatibility views derived from the graph. The generated command preserves the graph as repeated --part flags, so nothing depends on hidden builder state.

The builder's Multi-Ecosystem flow walks through frontend, backend, database, mobile/apps, then finalize (tooling, AI docs, install, Git, version settings).

Compatibility

Owned capability parts must reference an owner, and their ecosystem generally must match it.
Primary services can take an explicit stable ID as a fourth segment, such as backend:go:gin:api; capabilities then target that ID with api.orm:go:gorm.
Repeatable named backends render under services/<id> when their adapters support independent output; the checker rejects repeated projections it cannot render safely.
Universal database parts can be shared across ecosystems.
Some tools imply parts, for example a backend that assumes routing, and those appear in generated stackParts.
The compatibility validator runs before generation and reports owner, duplicate, and unsupported-tool issues.

Multiple named services

npm create better-fullstack@latest services-app -- \  --part frontend:typescript:next \  --part backend:go:gin:api \  --part backend:go:echo:admin \  --part api.orm:go:gorm \  --part admin.orm:go:sqlc \  --part database:universal:postgres

Stable IDs make ownership unambiguous and keep generated service paths reproducible.