Tour of your project

apps/, packages/, root config — what every folder is for.

8 mineasy

You have a project. Now let's walk through every top-level folder so you know what goes where before you write a single line of code.

The 30-second map

my-first-grit/
my-first-grit/
├── apps/
│ ├── api/ # Go API (Gin + GORM)
│ ├── web/ # Next.js public site
│ └── admin/ # Next.js admin panel
├── packages/
│ └── shared/ # Zod schemas + TS types (used by web + admin)
├── docker-compose.yml # Postgres, Redis, MinIO, Mailhog
├── docker-compose.prod.yml
├── grit.json # Project metadata grit reads
├── package.json # Root pnpm workspace
├── pnpm-workspace.yaml # Workspace member list
├── turbo.json # Turborepo task pipeline
├── .env # Secrets + URLs (gitignored)
├── .env.example # Template for new collaborators
└── README.md # Project-specific readme

apps/api — the Go backend

This is the engine. Open it up:

apps/api/
apps/api/
├── cmd/server/main.go # Entry point — where the API starts
├── internal/
│ ├── config/ # Loads .env into a typed Config struct
│ ├── database/ # Postgres connection + AutoMigrate
│ ├── handlers/ # HTTP handlers (Gin)
│ ├── middleware/ # Auth, CORS, security, etc.
│ ├── models/ # GORM structs
│ ├── routes/routes.go # Mounts every handler on a route
│ └── services/ # Business logic, called by handlers
├── .air.toml # Hot-reload config (if you use air)
├── Dockerfile
└── go.mod

The pattern is handler → service → model. Handlers are thin (parse input, return response). Services contain the business logic. Models are the data layer. We'll cover this in depth in chapter 3.

apps/web — the public Next.js app

Next.js 14 App Router. Standard layout: app/ for routes, components/ for reusable components, lib/ for the API client. Nothing surprising if you've used Next.js before.

apps/admin — the Filament-style admin panel

Also Next.js, but configured as an admin dashboard. The killer file is app/resources/ — every model gets a defineResource() call that auto-builds a CRUD page. We'll see this in chapter 4.

packages/shared — the type bridge

Zod schemas + TypeScript types that web and admin both import. When you run grit sync (chapter 4), Go structs get translated to TS types here — so the types in your React code always match the Go reality.

The folder structure is the same for every Grit project. Once you learn it, you know your way around any Grit codebase — yours, someone else's, an open-source one.

The root config files

  • grit.json — tells grit this is a Grit project. Includes the project name + architecture mode for diagnostics.
  • docker-compose.yml — the dev infrastructure (Postgres, Redis, MinIO for S3-compatible storage, Mailhog for email testing).
  • turbo.json — Turborepo task definitions for build, dev, test.
  • .env — generated with crypto-random secrets (you've seen these in past lessons).

Quick check

A teammate asks: 'Where do I put the business logic for handling refunds?' What's your answer?

Try it

Open apps/api/internal/handlers/. List the files you see. Pick one, open it, and answer in notes.md:

  • What model does it handle?
  • How many functions does it expose?
  • Does it import a service?

What's next

Tour done. Next lesson — fire up the dev servers. You'll have Postgres, Redis, the API, web, and admin all running together in under 5 minutes.

Spot a typo? Have an idea?

Help us improve this lesson. One click opens a GitHub issue with the lesson URL pre-filled — suggest clearer wording, report a bug, or request more depth. The course keeps improving thanks to learners like you.

Suggest an improvement on GitHub