Concepts

How Anetos works, and why.

• AI: How package ai connects language models to the app, and what it leaves to the providers.
• Application lifecycle: An Anetos application goes through five phases: New → Register → Boot → Run → Shutdown. Knowing which code runs in which phase tells you where to put configuration, wiring, connections and cleanup.
• Authentication and authorization: How Anetos knows who is making a request, and what they may do.
• Code generation: Queries in Anetos name columns with typed Go values, such as PostCols.Title, that anetos gen writes from your model structs. The compiler checks every column name and every value’s type, and nothing has to look a column up at query time.
• Configuration: Where settings come from, how they become typed Go structs, and why a bad setting stops the app before it serves a single request.
• HTTP request lifecycle: What happens between a request arriving and a response leaving, and where your code can hook in.
• Internationalization: How Anetos finds the words to show a user: where messages come from, how a request’s language is chosen, and how the language travels with work done for the user later.
• Migrations: Migrations are Go values compiled into your binary. The runner applies them in ID order, records each one in the migrations table with the batch it ran in, and wraps each in a transaction where the database allows it. A database lock keeps two instances from migrating at once.
• One binary: Your app builds to one binary that is both the server and its maintenance tool. app.Execute() reads the first argument and runs that command: run by default, or serve, migrate, routes:list and commands of your own. Code generation lives elsewhere, in the anetos developer tool, because it writes source code rather than running the app.
• Roles and permissions: How package auth/rbac decides what a user may do, and where it keeps what it needs.
• Runtime supervisor: Every Anetos application runs its long-lived work (HTTP servers, queue workers, pub/sub listeners, the scheduler, background tasks) as goroutines inside one process, managed by a supervisor. It decides what runs, what happens when something fails, and how everything stops.
• Server-rendered HTML: How pages are rendered, how a visitor’s state travels in an encrypted cookie, and how a failed form finds its way back to the page it came from.
• Testing model: What anetostest builds for a test, how it keeps tests from seeing each other’s data, how its client imitates a browser, and where a test run differs from production.
• The data layer: How the db package finds its connection, turns method calls into SQL, and why it works the way it does.
• Validation: How rules in struct tags become a cached plan, what web.H does with the result, and why validation works the way it does.