Alai

Såfremt du har læst mit indlæg om at starte et Go-projekt, bør du have udgangspunktet for en minimal Go-webservice. For dit første projekt er det nemmere at holde al din kode i én mappe, i bunden af dit projekt, men på et tidspunkt vil du ønske at omstrukturere tingene, dette gøres af et par af grunde:

• Har du alt i én mappe, resulterer det i en masse indbyrdes afhængigheder i koden.
• Genbrug uden for projektet kan være vanskeligt, da koden kun er designet til at blive brugt i én pakke.
• Det er umuligt at have mere end én binær fil, da man kun kan have én main metode.

Dette indlæg vil give et overblik over den struktur, jeg følger i mine Go-projekter, når jeg bygger webtjenester.

Bemærk: Hvis du blot bygger et bibliotek til brug i dine tjenester eller deler det med andre, er det OK at lægge alt i basismappen i dit projekt, et eksempel på dette er mit dynastore-bibliotek.

/cmd

Denne mappe indeholder de vigtigste applikationsindgangspunktfiler for projektet, hvor mappenavnet passer til navnet på binærfilen. Så f.eks. cmd/simple-service betyder, at den binære fil, vi udgiver, vil være simple-service.

/internal

Denne pakke indeholder den private bibliotekskode, der bruges i din tjeneste, den er specifik for tjenestens funktion og deles ikke med andre tjenester. En ting at bemærke er, at denne fortrolighed håndhæves af selve compileren, se Go 1.4 release notes for flere detaljer.

/pkg

Denne mappe indeholder kode, som er OK for andre tjenester at forbruge, dette kan omfatte API-klienter eller hjælpefunktioner, som kan være praktiske for andre projekter, men som ikke berettiger deres eget projekt. Personligt foretrækker jeg at bruge dette frem for internal, primært fordi jeg kan lide at holde ting åbne for genbrug i de fleste projekter.

Projektstruktur

Når du opbygger dit projekt, er der nogle meget vigtige mål, du bør overveje, når det kommer til, hvordan du strukturerer dine pakker:

• Hold tingene konsistente
• Hold tingene så enkle som muligt, men ikke enklere
• Kobl dele af tjenesten eller applikationen løst sammen
• Sigte på at sikre, at det er let at navigere rundt

Overordnet set bør du, når du kommer i gang, eksperimentere lidt, prøve et par forskellige ideer, når du bygger din første og få noget feedback på baseret på ovenstående mål.

Det vigtigste mål er at du bygger let at vedligeholde, konsistent og pålidelig software.

Eksempel

Jeg anbefaler at tage et kig på exitus for at se hvordan jeg strukturerer mine projekter, det meste af koden ligger under mappen pkg med hver undermappe med en eller flere filer. Fra det øverste niveau er det ret klart, hvad hver pakke relaterer sig til, og selv om den er lean på tests, har den et par eksempler.

$ 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_kunde_projekter.down.sql│ ├─ 20190723044115_kunde_projekter.up.sql│ ├─ 20190726175158_problemer.down.sql│ ├─── 20190726175158_issues.up.sql│ ├─ 20190726201649_comments.down.sql│ ├─ 201907261758_issues.up.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│ go│ │ ├── sqlhooks.go│ │ ├── sqlhooks.go│ │ └─ transactions.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.go│ ├ ├─ issues.go│ ├─ issues_test.go│ ├─ migrate_test.go│ ├─ projects.go│ ├─ projects_test.go│ └─ store.go└─── README.md

Sigtet her er at illustrere, hvordan du kan udvikle dit projekt fra et par filer til en større webtjeneste. Jeg opfordrer dig til at kigge github-projekter igennem og undersøge, hvordan andre udviklere har struktureret deres projekter, og frem for alt at afprøve det selv!

• GopherCon EU 2018: Peter Bourgon – Best Practices for Industrial Programming
• Standard Go Project Layout
• GopherCon 2018: Cat Seeing – Hvordan strukturerer du dine Go Apps

Feedback

Føl dig velkommen til at kontakte os via:

• @ mig på Twitter
• Send mig en e-mail

• Start af et Go-projekt
• Bygning af en WLToys A979 æselbil
• Går du i gang med Cognito?
• Hvorfor CDK?
• Serverløse baggrundsopgaver del 2