Overview
dygo new shop # one folder per module, see the layout belowdygo new shop -security # secure from the start: runs dygo g securitydygo 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" belowcd shop && go run . # http://localhost:9900, docs at /docsApps 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.mdmain.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.
dygo.json
Section titled “dygo.json”{"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.