Hallo Golo, vielen Dank für die tolle Erklärung. Was mir bisher völlig unbekannt war, wie ich mehr als eine main Funktion in meinem Modul unterbringe. Danke!
Danke für das Video! Den Aufbau von Modulen und Paketen finde ich aus technischer Sicht noch relativ einfach. Die Kunst ist hier eher die richtige Ordnung innerhalb des Moduls zu finden. Dazu hast du ja auch schon öfter etwas in deinen Videos gesagt. Etwas länger habe ich gebraucht, um das Konzept der Workspaces zu verstehen und zu nutzen.
Gerne - und ebenfalls danke 😊 Mit den Workspaces habe ich tatsächlich noch nie gearbeitet, bislang gilt bei uns: Ein Modul entspricht einem Repository. Auch wenn das manchmal etwas umständlich ist, aber so ist es relativ sauber strukturiert.
Danke für die Zusammenfassung. Mich hätte noch eure Empfehlung für das Modul-Setup in einem Monorepo mit Shared Code für die Go basierten Microservices interessiert.
Das kann ich Dir leider nicht beantworten, da wir keine nativen UIs bauen. Bei uns ist Go *immer* das Backend beziehungsweise ein Service, worauf per HTTP zugegriffen wird - und die UI dementsprechend dann eine Webseite. Native Lösungen gibt es zwar einige (einfach mal nach "go ui" googlen), aber empfehlen kann ich mangels Erfahrung damit leider keine.
Moin Golo, und danke für den tollen Beitrag. Ich bin seit deinem "Warum GO?" Video an der Sprache interessiert (ok, fasziniert wohl eher) und habe auch schon ein etwas größeres und einige kleinere Projekte (im privaten Umfeld) umgesetzt. Ich bin ein großer Freund des Konzepts der hexagonalen Architektur und habe mich bei dem größeren Projekt auch daran orientiert -- mit Erfolg wie ich finde. Nun legt diese Idee natürlich erstmal eine etwas "verzweigtere" Strukturierung der Packages nahe, was für mich zwar irgendwie umsetzbar war, sich dabei aber nicht richtig anfühlte -- eher wie ein Missbrauch. Die Ankündigung deines Videos hat mich daher direkt angefixt und ich hatte recht fest erwartet, hier eine Verbesserung der Unterstützung solcher eher baumartigen Strukturierung von Packages präsentiert zu bekommen. Weit gefehlt, im Gegenteil: Meine bisherige Vorgehensweise wird in dem Misuse-Gefühl bestätigt. Ich finde: Gut so. Warum? Ich denke ich habe die Skalierungsmöglichkeit über Module völlig ignoriert. Und die Empfehlung, die Packagestruktur flach zu halten ist hier ein willkommener Augenöffner, die einzelnen Module nicht zu wild wachsen zu lassen. Ich werde beizeiten (im Job hab ich's leider nur mit Java/ Spring zu tun) mal versuchen, die Adapter im (Kontext der Hexagonalen Architektur) nicht mehr als Packages, sondern als Module innerhalb des Workspaces zu designen. Vielleicht (und wenn gewünscht) berichte ich mal 😉 Vielen Dank, mach so weiter und beste Grüße
Im Grund handhabe ich meine Module genau wie im Video beschrieben. Wir haben allerdings von einem anderen Dienstleister Module im Kundenprojekt übernommen und dort gibt es `pkg`-Verzeichnisse, einmal im Root-Verzeichnis und dann nochmals als `internal/pkg` dort waren/sind über OpenAPI automatisch generierte Clients enthalten. Beide Verzeichnisse werden nach und nach aufgelöst... und automatisch generierte Clients werden in ein separates Modul verschoben, wenn diese keine internen Clients sind. Ein `pkg`-Verzeichnis wird man bei mir also in Greenfield-Projekten nirgendwo mehr entdecken können. Eine Anmerkung habe ich noch: Auch wenn man in Go seine Module im Dateisystem hierarchisch ablegen kann, so sind die Paketnamen nicht hierarchisch, deshalb sind auch Paketnamen wie `model`, `util`, `common`, etc. keine gute Idee. Gerade Java-Entwickler, die noch nicht so viel in Go entwickelt haben, haben damit ein Problem...
Danke für Deinen Erfahrungsbericht 😊 Das mit den allgemeinen Package-Namen ist ein sehr, sehr guter Hinweis - daran sollte man auf jeden Fall denken, denn so etwas wie "util" ist tatsächlich nicht besonders aussagekräftig, oder Dinge kollidieren unter Umständen auch schnell mit Go-internen Packages.
Danke für die Zusammenfassung. Was mir immer noch nicht klar ist: gibt es sinnvolle Gründe mehr als eine go Datei ( den jeweiligen Test Mal nicht betrachtet) mit in ein Modul zu packen? Würde man in einem Modul und Verzeichnis namens "user" neben user.go vielleicht noch Login. Gob finden ? Oder vielleicht eher ein anderes Beispiel, würde man in user neben user.go auch user_verigikeyion finden? Oder wäre das eher in einem separaten Modul namens user_verifikation zu finden?
Hi Golo, sprichst Du Deine Videos frei ein oder liest Du Wort für Wort von einem Skript ab? Ich würde gern einen TH-cam-Kanal zu einem anderen Thema starten, bin mir aber bezüglich der Narration noch unsicher. Danke!
Bin zwar nicht Golo aber ein Konsument: Golo, vermute ich, hat eine Outline mit den grundsaetzlichen Themen und Punkten die er im besonderen Ansprechen will, traegt aber ansonsten frei vor. Ein (gut gemachter) freier Vortrag suggeriert natuerlich, dass man im Thema drin ist (und die dynamik ist auch eine andere als bei einem abgelesenen Skript). Positive beispiele waeren z.B.: Hussein Nasser, H I Sutton, Lindybeige oder Wendigoon. Es gibt aber auch guten gescripteten Content hier, wie z.B. Fireship, No Boilerplate, Barely Sociable, braintruffle oder Fredrik Knudsen... Lange Rede kurzer Sinn: Mach das was dir am besten liegt (und am meisten Spass macht) und zu der Art content passt den du verbreiten willst.
Ich würde eine Krise bekommen wenn alle Packages im root Verzeichnis liegen. Beispiele für solche Repos wie Gitea oder HUGO - da findet man garnichts wieder.
Solchen PHP Code bin ich leider mehrfach im Leben begegnet. HTML, CSS, JS, PHP und SQL alles Inline und zusammen gemischt. Man kann 3 24 zoll Monitore haben und trotzdem noch zur Seite scrollen. Und die Verzweiflung ist tatsächlich sehr groß. Nur die Leitung sieht es nicht ein. So ist halt der Industriecode ...
Hallo Golo, vielen Dank für die tolle Erklärung. Was mir bisher völlig unbekannt war, wie ich mehr als eine main Funktion in meinem Modul unterbringe. Danke!
Das freut mich, dass Dir das Video geholfen hat! Und vielen Dank für das tolle Feedback 😊
Danke für das Video!
Den Aufbau von Modulen und Paketen finde ich aus technischer Sicht noch relativ einfach. Die Kunst ist hier eher die richtige Ordnung innerhalb des Moduls zu finden. Dazu hast du ja auch schon öfter etwas in deinen Videos gesagt. Etwas länger habe ich gebraucht, um das Konzept der Workspaces zu verstehen und zu nutzen.
Gerne - und ebenfalls danke 😊
Mit den Workspaces habe ich tatsächlich noch nie gearbeitet, bislang gilt bei uns: Ein Modul entspricht einem Repository. Auch wenn das manchmal etwas umständlich ist, aber so ist es relativ sauber strukturiert.
Danke für die Zusammenfassung. Mich hätte noch eure Empfehlung für das Modul-Setup in einem Monorepo mit Shared Code für die Go basierten Microservices interessiert.
Ciao Golo, deine Videos sind wirklich sehr verständlich und sachlich. Was für eine UI empfiehlst du mit Go?
Das kann ich Dir leider nicht beantworten, da wir keine nativen UIs bauen. Bei uns ist Go *immer* das Backend beziehungsweise ein Service, worauf per HTTP zugegriffen wird - und die UI dementsprechend dann eine Webseite. Native Lösungen gibt es zwar einige (einfach mal nach "go ui" googlen), aber empfehlen kann ich mangels Erfahrung damit leider keine.
Moin Golo, und danke für den tollen Beitrag.
Ich bin seit deinem "Warum GO?" Video an der Sprache interessiert (ok, fasziniert wohl eher) und habe auch schon ein etwas größeres und einige kleinere Projekte (im privaten Umfeld) umgesetzt.
Ich bin ein großer Freund des Konzepts der hexagonalen Architektur und habe mich bei dem größeren Projekt auch daran orientiert -- mit Erfolg wie ich finde. Nun legt diese Idee natürlich erstmal eine etwas "verzweigtere" Strukturierung der Packages nahe, was für mich zwar irgendwie umsetzbar war, sich dabei aber nicht richtig anfühlte -- eher wie ein Missbrauch.
Die Ankündigung deines Videos hat mich daher direkt angefixt und ich hatte recht fest erwartet, hier eine Verbesserung der Unterstützung solcher eher baumartigen Strukturierung von Packages präsentiert zu bekommen. Weit gefehlt, im Gegenteil: Meine bisherige Vorgehensweise wird in dem Misuse-Gefühl bestätigt.
Ich finde: Gut so. Warum? Ich denke ich habe die Skalierungsmöglichkeit über Module völlig ignoriert. Und die Empfehlung, die Packagestruktur flach zu halten ist hier ein willkommener Augenöffner, die einzelnen Module nicht zu wild wachsen zu lassen.
Ich werde beizeiten (im Job hab ich's leider nur mit Java/ Spring zu tun) mal versuchen, die Adapter im (Kontext der Hexagonalen Architektur) nicht mehr als Packages, sondern als Module innerhalb des Workspaces zu designen. Vielleicht (und wenn gewünscht) berichte ich mal 😉
Vielen Dank, mach so weiter und beste Grüße
Super video jedes mal.
Gibt es eigentlich eine Lösung in go wenn ich meinen modul nur als binary biblliothek rausgeben will?
Im Grund handhabe ich meine Module genau wie im Video beschrieben. Wir haben allerdings von einem anderen Dienstleister Module im Kundenprojekt übernommen und dort gibt es `pkg`-Verzeichnisse, einmal im Root-Verzeichnis und dann nochmals als `internal/pkg` dort waren/sind über OpenAPI automatisch generierte Clients enthalten. Beide Verzeichnisse werden nach und nach aufgelöst... und automatisch generierte Clients werden in ein separates Modul verschoben, wenn diese keine internen Clients sind. Ein `pkg`-Verzeichnis wird man bei mir also in Greenfield-Projekten nirgendwo mehr entdecken können. Eine Anmerkung habe ich noch: Auch wenn man in Go seine Module im Dateisystem hierarchisch ablegen kann, so sind die Paketnamen nicht hierarchisch, deshalb sind auch Paketnamen wie `model`, `util`, `common`, etc. keine gute Idee. Gerade Java-Entwickler, die noch nicht so viel in Go entwickelt haben, haben damit ein Problem...
Danke für Deinen Erfahrungsbericht 😊
Das mit den allgemeinen Package-Namen ist ein sehr, sehr guter Hinweis - daran sollte man auf jeden Fall denken, denn so etwas wie "util" ist tatsächlich nicht besonders aussagekräftig, oder Dinge kollidieren unter Umständen auch schnell mit Go-internen Packages.
Da fällt mir Adminer ein, alles in einer Datei ;-D
Danke für die Zusammenfassung. Was mir immer noch nicht klar ist: gibt es sinnvolle Gründe mehr als eine go Datei ( den jeweiligen Test Mal nicht betrachtet) mit in ein Modul zu packen?
Würde man in einem Modul und Verzeichnis namens "user"
neben user.go vielleicht noch Login. Gob finden ? Oder vielleicht eher ein anderes Beispiel, würde man in user neben user.go auch user_verigikeyion finden? Oder wäre das eher in einem separaten Modul namens user_verifikation zu finden?
Hi Golo, sprichst Du Deine Videos frei ein oder liest Du Wort für Wort von einem Skript ab?
Ich würde gern einen TH-cam-Kanal zu einem anderen Thema starten, bin mir aber bezüglich der Narration noch unsicher.
Danke!
Bin zwar nicht Golo aber ein Konsument:
Golo, vermute ich, hat eine Outline mit den grundsaetzlichen Themen und Punkten die er im besonderen Ansprechen will, traegt aber ansonsten frei vor.
Ein (gut gemachter) freier Vortrag suggeriert natuerlich, dass man im Thema drin ist (und die dynamik ist auch eine andere als bei einem abgelesenen Skript). Positive beispiele waeren z.B.: Hussein Nasser, H I Sutton, Lindybeige oder Wendigoon.
Es gibt aber auch guten gescripteten Content hier, wie z.B. Fireship, No Boilerplate, Barely Sociable, braintruffle oder Fredrik Knudsen...
Lange Rede kurzer Sinn: Mach das was dir am besten liegt (und am meisten Spass macht) und zu der Art content passt den du verbreiten willst.
@@MegaHarko danke! Sowas hatte ich auch vermutet.
Ich würde eine Krise bekommen wenn alle Packages im root Verzeichnis liegen. Beispiele für solche Repos wie Gitea oder HUGO - da findet man garnichts wieder.
OK! Unübersichtlichen Code schreiben, damit ich nie entlassen werden kann :D
Solchen PHP Code bin ich leider mehrfach im Leben begegnet. HTML, CSS, JS, PHP und SQL alles Inline und zusammen gemischt. Man kann 3 24 zoll Monitore haben und trotzdem noch zur Seite scrollen. Und die Verzweiflung ist tatsächlich sehr groß. Nur die Leitung sieht es nicht ein. So ist halt der Industriecode ...