En supposant que vous ayez lu mon post Démarrer un projet Go, vous devriez avoir le point de départ d’un service web go minimal. Pour votre premier projet, il est plus facile de garder tout votre code dans un seul dossier, dans la base de votre projet, mais à un moment donné, vous voudrez restructurer les choses, ceci pour quelques raisons :
- Avoir tout dans un seul dossier résulte en beaucoup d’inter dépendances dans le code.
- La réutilisation en dehors du projet peut être difficile car le code n’est conçu que pour être utilisé dans un seul paquet.
- Il est impossible d’avoir plus d’un binaire, car vous ne pouvez avoir qu’une seule méthode
main.
Ce post fournira une vue d’ensemble de la structure que je suis dans mes projets Go lors de la construction de services web.
Note : Si votre juste construction d’une bibliothèque pour utiliser dans vos services, ou partager avec d’autres, il est OK de tout mettre dans le dossier de base de votre projet, un exemple de ceci est ma bibliothèque dynastore.
/cmd
Ce dossier contient les principaux fichiers du point d’entrée de l’application pour le projet, le nom du répertoire correspondant au nom pour le binaire. Donc par exemple cmd/simple-service signifiant que le binaire que nous publions sera simple-service.
/internal
Ce paquet contient le code de bibliothèque privé utilisé dans votre service, il est spécifique à la fonction du service et n’est pas partagé avec d’autres services. Une chose à noter est que cette confidentialité est appliquée par le compilateur lui-même, voir les notes de version de Go 1.4 pour plus de détails.
/pkg
Ce dossier contient du code qui est OK pour d’autres services à consommer, cela peut inclure des clients API, ou des fonctions utilitaires qui peuvent être pratiques pour d’autres projets mais ne justifient pas leur propre projet. Personnellement, je préfère utiliser ceci plutôt que internal, principalement parce que j’aime garder les choses ouvertes pour la réutilisation dans la plupart des projets.
Structure du projet
Au fur et à mesure que vous construisez votre projet, il y a des objectifs très importants que vous devriez considérer quand il s’agit de la façon dont vous structurez vos paquets :
- Maintenir les choses cohérentes
- Maintenir les choses aussi simples que possible, mais pas plus simples
- Coupler librement les sections du service ou de l’application
- Assurer qu’il est facile de s’y retrouver
En général, lorsque vous commencez, vous devriez expérimenter un peu, essayer quelques idées différentes lors de la construction de votre premier et obtenir des commentaires sur la base des objectifs ci-dessus.
L’objectif numéro un est de vous construire un logiciel facile à maintenir, cohérent et fiable.
Exemple
Je recommande de jeter un coup d’œil à exitus pour voir comment je structure mes projets, la plupart du code est sous le dossier pkg avec chaque sous-dossier ayant un ou plusieurs fichiers. Du niveau supérieur, il est assez clair ce que chaque paquet se rapporte à, et bien que maigre sur les tests, il a quelques exemples.
$ 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_projets_clients.down.sql│ ├─ 20190723044115_projets_clients.up.sql│ ├─ 201907261758_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│ ├── serveur│ ├─ reflect.go│ └─ serveur.go│ └─ store│ ├── commentaires.go│ ├── commentaires_test.go│ ├─ clients.go│ ├─ clients_test.go│ ├─ issues.go│ ├─ issues_test.go│ ├─ migrate_test.go│ ├─ projects.go│ ├─ projects_test.go│ └─ store.go└── README.md
Le but ici est d’illustrer comment vous faites évoluer votre projet d’un couple de fichiers, à un plus grand service web. Je vous encourage à parcourir les projets github et à creuser la façon dont les autres développeurs ont structuré les leurs, et surtout à l’essayer vous-même !
- GopherCon EU 2018 : Peter Bourgon – Meilleures pratiques pour la programmation industrielle
- Mise en page standard des projets Go
- GopherCon 2018 : Cat Seeing – Comment structurez-vous vos applications Go
Feedback
N’hésitez pas à nous contacter via :
- @ moi sur Twitter
- Envoyez-moi un courriel
- Démarrer un projet Go
- Construire une voiture d’âne WLToys A979
- Démarrer avec Cognito ?
- Pourquoi CDK ?
- Travaux de fond sans serveur partie 2
.