Go-Entwickler haben ein Problem, das lächerlich klingt, sobald man es hört: Ihr Code ist an GitHub gebunden. Die Lösung, so Iain Cambridge, ist einfach – nutzen Sie stattdessen Ihre eigene Domain.
Cambridge betreibt ein Projekt namens Boneclone, und er hat Jahre damit verbracht, Teams dabei zu beobachten, wie sie sich in die Art und Weise verfangen, wie Go Abhängigkeiten handhabt. Die Sprache ermöglicht es Ihnen, Code über die Git-Hosting-URL zu importieren, was großartig funktioniert, bis Sie den Hoster wechseln möchten. Dann müssen Sie jede Importzeile in jeder Datei über alle Projekte hinweg umschreiben, die von Ihrem Code abhängen. Es ist ein Chaos.
Sein Beitrag mit dem Titel „Don’t couple your Go code to GitHub“ erklärt, warum der Standardansatz fehlerhaft ist und bietet eine Lösung. Die Kernidee ist, dass Go’s Importsystem auf einen Namen verweisen sollte, den Sie kontrollieren, nicht auf einen Namen, der von einem Hosting-Anbieter kontrolliert wird.
Das Problem mit Git-Hosting-URLs
Go’s import system is clever. When you write import "github.com/thetrueares/boneclone" in your code, the compiler knows where to fetch the source. That is handy for finding bugs and distributing libraries without a central package manager. But it comes with a serious catch.
If you host your code at github.com/thetrueares/boneclone and later move it to gitlab.com/thetrueares/boneclone, your code stops working. Every client machine still reaches out to the old GitHub URL. The new version of the library never gets pulled down, and your software stays broken.
Cambridge beschreibt einen realen Fall, in dem dies einem Unternehmen geschah, das GitHub, GitLab und Azure Devops gleichzeitig nutzte. Die Änderung des Speicherorts des Codes war so viel Arbeit, dass das Unternehmen beschloss, alle drei Plattformen weiter zu betreiben. Sie zahlten weiterhin für drei Hosting-Dienste, weil das Verschieben einer einzigen Git-URL alles kaputt gemachte.
„Was völlig verrückt klingt, ist aber etwas, das im Go-Community de facto üblich ist.“
Das ist der Kern des Problems. Das Importsystem koppelt Ihren Code an einen Hosting-Anbieter, und der Aufwand für einen Wechsel ist so hoch, dass Teams es einfach nicht tun. Sie bleiben gefangen.
Das Argument für benutzerdefinierte Domains
Die Lösung ist, diese Kopplung zu unterbrechen. Anstatt von einer Git-Hosting-URL zu importieren, importieren Sie von einer Domain, die Sie besitzen. So können Sie Ihren Code überallhin verschieben, ohne eine einzige Importzeile ändern zu müssen.
Cambridge points to examples like go.iain.rocks, go.uber.org, and go.mongodb.org. These domains act as pointers. When you import go.iain.rocks/boneclone, the server behind that domain tells Go where to actually fetch the code. If you later move the code to GitLab, you just change where the domain points. The import line stays the same, and clients keep working.
Der Vorteil ist sofort erkennbar. Sie können Hosting-Anbieter wechseln, ohne Produktionscode umschreiben zu müssen. Sie können einen alten Server abschalten, ohne nachgelagerte Konsumenten zu beeinträchtigen. Sie können sogar mehrere Versionen Ihrer Bibliothek nebeneinander betreiben und dabei unterschiedliche Pfade unter derselben Domain bedienen.
Für kommerzielle Teams ist dies, so Cambridge, ein einfacher Weg, um sinnlose Kopplungen zu vermeiden. Er sagt, dass jedes kommerzielle Softwareentwicklungsteam, das Go verwendet, benutzerdefinierte Domains für seine internen Bibliotheken und Pakete übernehmen sollte.
Wie die Weiterleitung funktioniert
The trick works through HTTP redirects. When a Go client asks for go.iain.rocks/boneclone, the server responds with a redirect to the actual git hosting URL. If the request includes the ?go-get=1 parameter — meaning the Go tool itself is asking — the server serves an HTML file with metadata. Without that parameter, it redirects the human visitor to GitHub.
Hier ist dargestellt, wie Cambridges Nginx-Konfiguration dies handhabt:
„`nginx server { server_name go.iain.rocks; root /var/www/go.iain.rocks; index index.html;
location / {
if ($args !~ go-get=1) {
return 301 https://github.com/that-guy-iain$request_uri;
}
try_files $uri $uri/ =404;
}
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/letsencrypt/live/go.iain.rocks/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/go.iain.rocks/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
server { listen 80; listen [::]:80; server_name go.iain.rocks; return 301 https://$host$request_uri; } „`
The index.html file contains the metadata that Go needs to resolve the import. It includes a go-import meta tag pointing to the git hosting URL and a go-source tag with the repository’s tree and blob URLs.
„`html
„`
Diese Konfiguration bedeutet, dass das Go-Tool Ihren Code überall finden kann, während Besucher der Domain auf eine freundliche Weiterleitung zu GitHub gelangen.
Was passiert, wenn Sie umziehen
Die Schönheit dieses Systems ist, dass der Umzug für alle außer Ihnen unsichtbar ist. Sie aktualisieren die Domain, um auf den neuen Hosting-Speicherort zu verweisen. Die HTML-Datei ändert sich, um die neue URL widerzuspiegeln. Die Nginx-Konfiguration ändert sich, um auf den neuen Speicherort zu verweisen.
Clients, die Ihren Code bereits abgerufen haben, verwenden weiterhin die zwischengespeicherte Version. Neue Clients erreichen die Weiterleitung und erhalten den aktualisierten Speicherort. Es gibt keine Ausfallzeiten, keine Neukonstruktionen, keine hektische Suche und Ersetzung im gesamten Codebasis.
Cambridges eigenes Projekt, Boneclone, dient dazu, dies zu vereinfachen. Es handhabt die Replikation von Skelettcode über mehrere Git-Hosting-Plattformen gleichzeitig, sodass Teams ihre Repositorys spiegeln können, ohne Imports neu zu schreiben. Seine Erfahrung beim Aufbau dieses Projekts entstand durch die Beobachtung, wie Unternehmen mit dem Problem zu kämpfen hatten, das er jetzt lösen möchte.
Warum das jetzt wichtig ist
Dies ist kein hypothetisches Problem. Cambridge sah ein Unternehmen drei Hosting-Dienste bezahlen, weil es nicht die Kosten für die Änderung einer Git-URL tragen konnte. Das ist eine echte finanzielle Strafe für eine Designentscheidung, die vor Jahren getroffen wurde.
Das Problem ist de facto in der Go-Community vorhanden, schreibt er. Teams verwenden Git-Hosting-URLs für Imports, ohne über die Konsequenzen nachzudenken. Sie gehen davon aus, dass das Importsystem eine Funktion und nicht eine Falle ist.
Es ist eine Falle. Die Verknüpfung ist real und kostet Geld.
Der Takeaway
Der Rat ist unkompliziert: Wenn Sie Go-Code schreiben, sollten Sie eine benutzerdefinierte Domain für Ihre Imports in Betracht ziehen. Es kostet fast nichts, sie einzurichten, und es schützt Sie vor einem kostspieligen Fehler.
Cambridges Beitrag ist eine Erinnerung daran, dass Software-Designentscheidungen reale Auswirkungen haben. Ein kleiner Komfort in einer Sprachfunktion kann zu Fesseln für viele Jahre werden. Die Lösung ist in diesem Fall einfacher als das Problem, das sie löst.
Die Abfolge der Ereignisse in der Geschichte:
| Ereignis | Detail |
|---|---|
| Problem identifiziert | Unternehmen, die GitHub, GitLab und Azure Devops verwenden, konnten die Git-Speicherorte nicht ändern, ohne Imports umzuschreiben. |
| Lösung vorgeschlagen | Use custom domains like go.iain.rocks instead of git hosting URLs |
| Beispiel genannt | go.iain.rocks/boneclone redirects to github.com/thetrueares/boneclone |
| Kosten beschrieben | Ein Unternehmen zahlte für drei Hosting-Dienste, da es eine URL nicht ändern konnte. |
| Tool erstellt | Cambridge entwickelte Boneclone, um Skelettcode über mehrere Plattformen zu replizieren. |
Die Quintessenz ist einfach: Koppeln Sie Ihren Go-Code nicht an GitHub. Verwenden Sie stattdessen Ihre eigene Domain. Es ist eine kleine Änderung, die Sie jedoch vor einer Falle befreit.
Quellenmaterial: „Don’t couple your Go code to GitHub“, iain.rocks.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.