Choose a framework

The Apso CLI implements generators for three standard backend stacks. The .apsorc schema is language-independent, while each generator writes framework-native models, handlers, validation, services, and migration support.

Framework outputsOne contract, three familiar stacks.

Standard tooling

.apsorcentities • relationships • auth • scope

TypeScript

NestJS + TypeORM

REST API, OpenAPI, migrations, validation, and extension boundaries.

npm run build

Python

FastAPI + SQLAlchemy

REST API, OpenAPI, migrations, validation, and extension boundaries.

pytest

Gin + GORM

REST API, OpenAPI, migrations, validation, and extension boundaries.

go test ./...

Pick the framework your team already knows. The generated project uses its normal build, test, package, and deployment conventions.

Available frameworks

NestJS, TypeORM, class-validator, Jest, and OpenAPI

TypeScript with NestJS

FastAPI, SQLAlchemy 2, Pydantic 2, Alembic, and pytest

Python with FastAPI

Gin, GORM, validator, Goose migrations, and Go tests

Go with Gin

Create a project


# TypeScript
apso init --name my-api --language typescript --skip-platform
 
# Python
apso init --name my-api --language python --skip-platform
 
# Go
apso init --name my-api --language go --skip-platform

After editing .apsorc, run the same generation command in each project:


apso generate

Compare the stacks

Language	HTTP framework	Data layer	Validation	Migrations	Generated directory
TypeScript	NestJS	TypeORM	class-validator	TypeORM	`src/autogen/`
Python	FastAPI	SQLAlchemy 2	Pydantic 2	Alembic	`app/autogen/`
Go	Gin	GORM	go-playground/validator	Goose	`autogen/`

Choose a language

Choose TypeScript for NestJS conventions, decorators, dependency injection, and a shared language with a JavaScript frontend.
Choose Python for FastAPI, Pydantic models, async SQLAlchemy, and Python-based application logic.
Choose Go for a compact compiled service with Gin handlers and GORM models.

Switching languages creates a new project from the same .apsorc schema. Custom extension code is framework-specific and must be ported separately.

Shared generation boundary

Every template separates generated and custom code:

Area	Ownership
`autogen/`	Rewritten by `apso generate`
`extensions/`	Written and maintained by your team
`.apsorc`	Version-controlled source of truth

Keep application rules in extensions/ so schema regeneration remains a routine part of development.