Angenommen, Sie haben meinen Beitrag Start eines Go-Projekts gelesen, dann sollten Sie den Ausgangspunkt für einen minimalen Go-Webdienst haben. Für Ihr erstes Projekt ist es einfacher, den gesamten Code in einem Ordner zu halten, in der Basis Ihres Projekts, aber irgendwann werden Sie die Dinge umstrukturieren wollen, und zwar aus mehreren Gründen:
- Alles in einem Ordner zu haben, führt zu einer Menge Abhängigkeiten im Code.
- Die Wiederverwendung außerhalb des Projekts kann schwierig sein, da der Code nur für die Verwendung in einem Paket vorgesehen ist.
- Es ist unmöglich, mehr als eine Binärdatei zu haben, da man nur eine
mainMethode haben kann.
Dieser Beitrag gibt einen Überblick über die Struktur, der ich in meinen Go-Projekten folge, wenn ich Webdienste baue.
Hinweis: Wenn Sie nur eine Bibliothek bauen, um sie in Ihren Diensten zu verwenden oder mit anderen zu teilen, ist es in Ordnung, alles in den Basisordner Ihres Projekts zu legen, ein Beispiel dafür ist meine Dynastore-Bibliothek.
/cmd
Dieser Ordner enthält die Hauptdateien für den Anwendungseinstieg in das Projekt, wobei der Verzeichnisname dem Namen der Binärdatei entspricht. So bedeutet zum Beispiel cmd/simple-service, dass die von uns veröffentlichte Binärdatei simple-service sein wird.
/internal
Dieses Paket enthält den privaten Bibliothekscode, der in Ihrem Dienst verwendet wird, er ist spezifisch für die Funktion des Dienstes und wird nicht mit anderen Diensten geteilt. Eine Sache, die zu beachten ist, ist, dass diese Vertraulichkeit vom Compiler selbst erzwungen wird, siehe die Go 1.4 Release Notes für weitere Details.
/pkg
Dieser Ordner enthält Code, der von anderen Diensten verwendet werden darf, dies kann API-Clients oder Utility-Funktionen beinhalten, die für andere Projekte nützlich sein können, aber kein eigenes Projekt rechtfertigen. Ich persönlich ziehe diesen Ordner internal vor, vor allem, weil ich Dinge zur Wiederverwendung in den meisten Projekten offen halten möchte.
Projektstruktur
Während du dein Projekt aufbaust, gibt es einige sehr wichtige Ziele, die du berücksichtigen solltest, wenn es darum geht, wie du deine Pakete strukturierst:
- Behalten Sie die Dinge konsistent
- Behalten Sie die Dinge so einfach wie möglich, aber nicht einfacher
- Koppeln Sie die Abschnitte des Dienstes oder der Anwendung locker miteinander
- Zielen Sie darauf ab, dass man sich leicht zurechtfindet
Insgesamt sollten Sie am Anfang ein wenig experimentieren, ein paar verschiedene Ideen ausprobieren, wenn Sie Ihr erstes Projekt aufbauen und sich ein Feedback zu den oben genannten Zielen einholen.
Das oberste Ziel ist es, einfach zu wartende, konsistente und zuverlässige Software zu erstellen.
Beispiel
Ich empfehle einen Blick auf exitus zu werfen, um zu sehen, wie ich meine Projekte strukturiere, der meiste Code befindet sich unter dem Ordner pkg mit jedem Unterordner mit einer oder mehreren Dateien. Von der obersten Ebene aus ist es ziemlich klar, worauf sich jedes Paket bezieht, und obwohl es sich auf Tests beschränkt, gibt es ein paar Beispiele.
$ 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_Kundenprojekte.down.sql│ ├─ 20190723044115_Kundenprojekte.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│ │ └─ 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
Das Ziel ist es, zu veranschaulichen, wie man sein Projekt von ein paar Dateien zu einem größeren Webdienst ausbaut. Ich ermutige Sie, Github-Projekte zu durchforsten und herauszufinden, wie andere Entwickler ihre Projekte strukturiert haben, und vor allem, es selbst auszuprobieren!
- GopherCon EU 2018: Peter Bourgon – Best Practices for Industrial Programming
- Standard Go Project Layout
- GopherCon 2018: Cat Seeing – Wie strukturieren Sie Ihre Go Apps
Feedback
Fühlen Sie sich frei, uns zu kontaktieren:
- @ me on Twitter
- Send me an Email
- Starting a Go Project
- Building a WLToys A979 donkey car
- Getting started with Cognito?
- Warum CDK?
- Serverlose Hintergrundaufträge Teil 2