Assumendo che abbiate letto il mio post Starting a Go Project dovreste avere il punto di partenza per un servizio web Go minimo. Per il tuo primo progetto è più facile tenere tutto il tuo codice in una cartella, nella base del tuo progetto, ma ad un certo punto vorrai ristrutturare le cose, questo viene fatto per alcune ragioni:
- Avere tutto in una cartella comporta un sacco di interdipendenze nel codice.
- Riutilizzare al di fuori del progetto può essere difficile, poiché il codice è progettato per essere usato solo in un pacchetto.
- È impossibile avere più di un binario, poiché si può avere solo un metodo
main.
Questo post fornirà una panoramica della struttura che seguo nei miei progetti Go quando costruisco servizi web.
Nota: Se stai solo costruendo una libreria da usare nei tuoi servizi, o da condividere con altri, va bene mettere tutto nella cartella base del tuo progetto, un esempio di questo è la mia libreria dynastore.
/cmd
Questa cartella contiene i principali file del punto di ingresso dell’applicazione per il progetto, con il nome della directory corrispondente al nome del binario. Così per esempio cmd/simple-service significa che il binario che pubblichiamo sarà simple-service.
/internal
Questo pacchetto contiene il codice privato della libreria usato nel tuo servizio, è specifico per la funzione del servizio e non è condiviso con altri servizi. Una cosa da notare è che questa privacy è applicata dal compilatore stesso, vedi le note di rilascio di Go 1.4 per maggiori dettagli.
/pkg
Questa cartella contiene codice che può essere utilizzato da altri servizi, questo può includere client API, o funzioni di utilità che possono essere utili per altri progetti ma non giustificano un progetto proprio. Personalmente preferisco usare questo rispetto a internal, principalmente perché mi piace tenere le cose aperte per il riutilizzo nella maggior parte dei progetti.
Struttura del progetto
Come costruisci il tuo progetto ci sono alcuni obiettivi molto importanti che dovresti considerare quando si tratta di come strutturi i tuoi pacchetti:
- Mantenere le cose coerenti
- Mantenere le cose il più semplici possibile, ma non più semplici
- Accoppiare liberamente le sezioni del servizio o dell’applicazione
- Fare in modo che sia facile orientarsi
In generale quando si inizia si dovrebbe sperimentare un po’, provare alcune idee diverse quando si costruisce il primo e ottenere alcuni feedback sulla base degli obiettivi di cui sopra.
L’obiettivo numero uno è quello di costruire un software facile da mantenere, coerente e affidabile.
Esempio
Consiglio di dare un’occhiata a exitus per vedere come strutturo i miei progetti, la maggior parte del codice è sotto la cartella pkg con ogni sotto cartella che ha uno o più file. Dal livello superiore è abbastanza chiaro a cosa si riferisce ogni pacchetto, e anche se magro sui test ha alcuni esempi.
$ tree exitus/ exitus/├── cmd│ ├── authtest│ │ └── main.go│ ├── backend│ │ └── main.go│ └─ client│ └─ main.go├─ dev│ ├─ add_migration.sh│ └─ docker-compose.yml├─ Dockerfile├─ go.mod├─ go.sum│ ├─ 20190721131113_extensions.down.sql│ ├─ 20190721131113_extensions.up.sql│ ├─ 20190723044115_customer_projects.down.sql│ ├─ 20190723044115_customer_projects.up.sql│ ├─ 20190726175158_issues.down.sql│ ├── 20190726175158_issues.up.sql│ ├─ 20190726201649_comments.down.sql│ ├─ 20190726201649_comments.up.sql│ ├─ bindata.go│ ├── migrations_test.go│ └─ README.md├── pkg│ ├─ api│ │ ├─ exitus.gen.go│ │ ├─ exitus.yml│ └─ gen.go│ ├── auth│ │ ├─ scopes.go│ └─ user.go│ ├─ conf│ │ ├─ conf.go│ │ └─ conf_test.go│ ├── db│ │ ├─ db.go│ │ ├─ dbtesting.go│ │ ├── migrate.go│ │ ├── sqlhooks.go│ │ └─ transaction.go│ ├── env│ │ └── env.go│ ├─ healthz│ │ ├─ healthz.go│ │ └── healthz_test.go│ ├── jwt│ │ └── jwt.go│ ├── metrics│ │ └── metrics.go│ ├── middleware│ │ └── middleware.go│ ├─ oidc│ │ └── client.go│ ├── server│ ├─ reflect.go│ └─ server.go│ └─ store│ ├── comments.go│ ├── comments_test.go│ ├─ customers.go│ ├─ customers_test.├─ issues.go│ ├─ issues_test.go│ ├─ migrate_test.go│ ├─ projects.go│ ├─ projects_test.go│ └─ store.go└── README.md
Lo scopo qui è di illustrare come si fa crescere il progetto da un paio di file, a un servizio web più grande. Ti incoraggio a tracciare i progetti github e a scavare in come altri sviluppatori hanno strutturato i loro, e soprattutto a provarlo tu stesso!
- GopherCon EU 2018: Peter Bourgon – Best Practices per la programmazione industriale
- Standard Go Project Layout
- GopherCon 2018: Cat Seeing – How Do You Structure Your Go Apps
Feedback
Sentitevi liberi di contattare via:
- @ me su Twitter
- Mandami una Email
- Iniziare un progetto Go
- Costruire una macchina asino WLToys A979
- Iniziare con Cognito?
- Perché CDK?
- Lavori in background senza server parte 2