Alai

Feltételezve, hogy elolvastad a Go projekt indítása bejegyzésemet, meg kell lennie a kiindulási pontnak egy minimális Go webszolgáltatáshoz. Az első projektedhez egyszerűbb, ha az összes kódodat egy mappában tartod, a projekted alapjában, de egy bizonyos ponton át akarod majd strukturálni a dolgokat, ezt több okból is megteheted:

• Az, hogy mindent egy mappában tartasz, sok egymásra utaltságot eredményez a kódban.
• A projekten kívüli újrafelhasználás nehézkes lehet, mivel a kódot csak egy csomagban való használatra tervezték.
• Nem lehet több bináris, mivel csak egy main metódusod lehet.

Ez a bejegyzés áttekintést ad arról a struktúráról, amit a Go projektjeimben követek, amikor webszolgáltatásokat építek.

Megjegyzés: Ha csak egy könyvtárat építesz, amit a szolgáltatásaidban használsz, vagy megosztasz másokkal, akkor rendben van, ha mindent a projekted alapmappájába teszel, erre példa a dynastore könyvtáram.

/cmd

Ez a mappa tartalmazza a projekt fő alkalmazás belépési pont fájljait, a könyvtár neve megegyezik a bináris fájl nevével. Tehát például cmd/simple-service ami azt jelenti, hogy a bináris, amit kiadunk, simple-service lesz.

/internal

Ez a csomag tartalmazza a szolgáltatásodban használt privát könyvtári kódot, ez a szolgáltatás működésére jellemző, és nem osztható meg más szolgáltatásokkal. Egy dolog, amit meg kell jegyezni, hogy ezt a magánéletet maga a fordítóprogram kényszeríti ki, további részletekért lásd a Go 1.4 release notes-t.

/pkg

Ez a mappa olyan kódot tartalmaz, amit más szolgáltatások nyugodtan fogyaszthatnak, ez tartalmazhat API klienseket, vagy segédfunkciókat, amelyek hasznosak lehetnek más projektek számára, de nem indokolják a saját projektet. Én személy szerint inkább ezt használom a internal helyett, főleg azért, mert szeretem a legtöbb projektben nyitva tartani a dolgokat az újrafelhasználásra.

Projektstruktúra

A projekt felépítése során van néhány nagyon fontos cél, amit figyelembe kell venned, amikor a csomagjaid felépítéséről van szó:

• Tartsd a dolgokat konzisztensnek
• Tartsd a dolgokat a lehető legegyszerűbbnek, de ne egyszerűbbnek
• Párosítsd lazán a szolgáltatás vagy az alkalmazás részeit
• Közösítsd a szolgáltatás vagy az alkalmazás részeit
• Törekedj arra, hogy könnyű legyen eligazodni benne

Az induláskor érdemes egy kicsit kísérletezni, próbálj ki néhány különböző ötletet az első felépítés során, és kérj visszajelzést a fenti célok alapján.

Az első számú cél az, hogy könnyen karbantartható, konzisztens és megbízható szoftvert építsen.

Példa

Az exituson ajánlom megnézni, hogyan strukturálom a projektjeimet, a kód nagy része a pkg mappa alatt van, minden almappában egy vagy több fájl található. A legfelső szintről elég világos, hogy az egyes csomagok mire vonatkoznak, és bár sovány a tesztekre, van néhány példa.

$ 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│ │ ├─ 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│ │ └── ügyfél.go│ ├─ szerver│ ├─ reflect.go│ └─ szerver.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

A cél az, hogy bemutassuk, hogyan lehet a projektet néhány fájlból egy nagyobb webes szolgáltatássá fejleszteni. Arra bátorítalak, hogy nézd át a github projekteket, és nézz utána, hogy más fejlesztők hogyan strukturálták a sajátjukat, és legfőképpen próbáld ki te magad!

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

Feedback

Feelly free to reach out via:

• @ me on Twitter
• Send me an Email

• Starting a Go Project
• Building a WLToys A979 donkey car
• Getting started with Cognito?
• Miért CDK?
• Kiszolgáló nélküli háttérmunkák 2. rész