Skip to content

Overview

Terminalsh
dygo new shop # one folder per module, see the layout below
dygo new shop -security # secure from the start: runs dygo g security
dygo new shop -security -oidc # the same, with login at Keycloak, Auth0, ... (dygo g security -oidc)
dygo new shop -db postgres # with a database (or -db mysql): see "Database" below
cd shop && go run . # http://localhost:9900, docs at /docs

Apps listen on port 9900 by default (PORT in .env). Every project gets a .env with your local settings, ready to run, and a .env.example with the same settings to commit. Every setting has a comment saying what it does and which values it takes. .env is git ignored, so after a fresh clone run cp .env.example .env.

A project is split by module. The two files that start the app sit at the top, and everything else is a folder:

shop/
main.go load config, create the app, listen
app.module.go AppModule (the root module) and AppOptions
app_test.go e2e tests: wiring check and a boot of the whole app
src/
config/ typed configuration (env and .env); a global module
database/ the connection, a global module; *sql.DB shaped placeholder (a real pool with -db)
health/ /health/live and /health/ready, pinging the database
common/ types shared by features (Pagination)
modules/ feature modules: users/, orders/, ... (dygo g resource adds them)
dygo.json tells dygo where features go
Dockerfile .env .env.example README.md

main.go and app.module.go are both package main, so the root module is one file you can open, not a package. The other packages sit in src/. Unlike internal/, Go does not stop other modules from importing src/ packages; for an application nobody imports, that makes no difference. While dygo is unpublished, -replace ../dygo-framework points the project at a local checkout.

{"layout": "modular", "main": ".", "featuresDir": "src/modules", "rootModuleDir": "."}

layout is always modular. main is the default package for routes, graph, check, info and start at the project root. featuresDir is where dygo g puts a feature when run from the root, and rootModuleDir is where it is registered (in the module named app) when no closer module exists.