Alai

Aannemende dat je mijn Go Project Starten post hebt gelezen, dan zou je het beginpunt moeten hebben voor een minimale go web service. Voor uw eerste project is het makkelijker om al uw code in één map te houden, in de basis van uw project, maar op een gegeven moment zult u dingen willen herstructureren, dit wordt gedaan om een paar redenen:

• Het hebben van alles in één map resulteert in een heleboel onderlinge afhankelijkheden in de code.
• Hergebruik buiten het project kan moeilijk zijn, omdat de code alleen is ontworpen om in één package te worden gebruikt.
• Het is onmogelijk om meer dan één binary te hebben, omdat je maar één main methode kunt hebben.

Deze post zal een overzicht geven van de structuur die ik volg in mijn Go projecten bij het bouwen van web services.

Note: Als je gewoon een bibliotheek bouwt om te gebruiken in je services, of om te delen met anderen, is het OK om alles in de basis map van je project te zetten, een voorbeeld hiervan is mijn dynastore bibliotheek.

/cmd

Deze map bevat de belangrijkste entry point bestanden voor het project, waarbij de naam van de map overeenkomt met de naam van de binary. Dus bijvoorbeeld cmd/simple-service wat betekent dat de binary die we publiceren simple-service zal zijn.

/internal

Dit pakket bevat de private bibliotheek code die gebruikt wordt in uw service, het is specifiek voor de functie van de service en wordt niet gedeeld met andere services. Een ding om op te merken is dat deze privacy wordt afgedwongen door de compiler zelf, zie de Go 1.4 release notes voor meer details.

/pkg

Deze map bevat code die OK is voor andere services om te consumeren, dit kan API clients bevatten, of utiliteitsfuncties die handig kunnen zijn voor andere projecten maar geen eigen project rechtvaardigen. Persoonlijk gebruik ik dit liever dan internal, vooral omdat ik dingen open wil houden voor hergebruik in de meeste projecten.

Project Structuur

Terwijl je je project opbouwt zijn er enkele zeer belangrijke doelen die je moet overwegen als het gaat om hoe je je pakketten structureert:

• Dingen consistent houden
• Dingen zo eenvoudig mogelijk houden, maar niet eenvoudiger
• Loskoppel secties van de service of applicatie
• Zorg ervoor dat het gemakkelijk is om je weg te vinden

Over het algemeen wanneer je begint moet je een beetje experimenteren, een paar verschillende ideeën proberen bij het uitbouwen van je eerste en wat feedback krijgen op basis van de bovenstaande doelen.

Het belangrijkste doel is om eenvoudig te onderhouden, consistente en betrouwbare software te bouwen.

Voorbeeld

Ik raad je aan om een kijkje te nemen bij exitus om te zien hoe ik mijn projecten structureer, de meeste code staat onder de pkg map met elke submap een of meer bestanden. Vanaf het hoogste niveau is het vrij duidelijk waar elk pakket betrekking op heeft, en hoewel het weinig tests bevat, heeft het een paar voorbeelden.

$ 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│ ├── gen.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│ │ ├── jwt.go│ │ └── 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

The aim here is to illustrate how you grow your project from a couple of files, to a larger web service. I encourage you to trawl through github projects and dig into how other developers have structured theirs, and most of all try it out yourself!

• GopherCon EU 2018: Peter Bourgon – Best Practices for Industrial Programming
• Standard Go Project Layout
• GopherCon 2018: Kat Zien – How Do You Structure Your Go Apps

Feedback

Feel free to reach out via:

• @ mij op Twitter
• stuur me een e-mail

• Start een Go Project
• Bouwen van een WLToys A979 ezelsauto
• Aan de slag met Cognito?
• Waarom CDK?
• Serverloze achtergrond taken deel 2