Los desarrolladores de Go tienen un problema que suena ridículo una vez que lo escuchas: su código está atado a GitHub. La solución, según Iain Cambridge, es simple: usa tu propio dominio en su lugar.
Cambridge dirige un proyecto llamado Boneclone, y ha pasado años observando equipos enredarse en la forma en que Go maneja las dependencias. El lenguaje te permite importar código por su URL de alojamiento git, lo cual funciona bien hasta que quieres cambiar de host. Entonces tienes que reescribir cada línea de importación en cada archivo a través de cada proyecto que depende del tuyo. Es un desastre.
Su publicación, titulada «No acoples tu código Go a GitHub», explica por qué el enfoque estándar está roto y ofrece una solución. La idea principal es que el sistema de importación de Go debería apuntar a un nombre que controlas, no a un nombre controlado por un proveedor de alojamiento.
El problema con las URL de alojamiento de Git
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 describe un caso real en el que esto le sucedió a una empresa que utilizaba GitHub, GitLab y Azure Devops al mismo tiempo. Cambiar la ubicación del código fue tanto trabajo que la empresa decidió mantener las tres plataformas en funcionamiento. Continuaron pagando por tres servicios de alojamiento porque mover una sola URL de git rompió todo.
«Lo cual suena completamente loco, pero es algo que es prácticamente *defacto* en la comunidad de Go.»
Ese es el quid de la cuestión. El sistema de importación acopla tu código a un proveedor de alojamiento, y la sobrecarga de cambiar es tan alta que los equipos simplemente no se molestan. Permanecen bloqueados.
El caso de los dominios personalizados
La solución es romper ese acoplamiento. En lugar de importar desde una URL de alojamiento de git, importa desde un dominio que posees. De esta manera, puedes mover tu código a donde sea sin tocar ni una sola línea de importación.
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.
El beneficio es inmediato. Puedes cambiar de proveedor de alojamiento sin volver a escribir el código de producción. Puedes retirar un servidor antiguo sin romper a los consumidores posteriores. Incluso puedes ejecutar múltiples versiones de tu biblioteca lado a lado, sirviendo diferentes rutas bajo el mismo dominio.
Para equipos comerciales, Cambridge argumenta, esta es una forma sencilla de evitar un acoplamiento innecesario. Él dice que todos los equipos de desarrollo de software comercial que usan Go deberían adoptar dominios personalizados para sus bibliotecas e paquetes internos.
Cómo funciona la redirección
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.
Aquí es cómo la configuración de Nginx de Cambridge lo maneja:
«`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
«`
Esa configuración significa que la herramienta de Go puede encontrar su código en cualquier lugar, mientras que los humanos que navegan por el dominio ven un redireccionamiento amigable a GitHub.
Qué Sucede Cuando Se Traslada
La belleza de este sistema es que la mudanza es invisible para todos excepto para usted. Actualiza el dominio para que apunte a la nueva ubicación de alojamiento. El archivo HTML cambia para reflejar la nueva URL. La configuración de Nginx cambia para que apunte a la nueva ubicación.
Los clientes que ya descargaron su código siguen usando la versión almacenada en caché. Los clientes nuevos acceden al redireccionamiento y obtienen la ubicación actualizada. No hay tiempo de inactividad, no hay reconstrucciones, no hay búsquedas y reemplazos frenéticos en todo su código base.
El propio proyecto de Cambridge, Boneclone, existe para facilitar esto. Maneja la replicación de código esqueleto en múltiples plataformas de alojamiento de git al mismo tiempo, para que los equipos puedan reflejar sus repositorios sin volver a escribir las importaciones. Su experiencia construyéndolo surgió de observar cómo las empresas luchaban con el problema exacto que ahora resuelve.
Por Qué Esto Importa Ahora
Esto no es una preocupación hipotética. Cambridge vio a una empresa pagar por tres servicios de alojamiento porque no podía soportar el costo de cambiar una URL de git. Ese es un verdadero costo financiero por una decisión de diseño tomada hace años.
El problema es de facto en la comunidad de Go, escribe. Los equipos utilizan URL de alojamiento de git para importar sin pensar en las consecuencias. Asumen que el sistema de importación es una característica, no una trampa.
Es una trampa. La combinación es real, y cuesta dinero.
La conclusión
El consejo es directo. Si escribe código Go, considere usar un dominio personalizado para sus importaciones. Cuesta casi nada configurarlo, y lo protege de un error costoso.
La publicación de Cambridge es un recordatorio de que las decisiones de diseño de software tienen consecuencias en el mundo real. Una pequeña comodidad en una característica del lenguaje puede convertirse en una cadena para años. La solución, en este caso, es más simple que el problema que resuelve.
La secuencia de eventos en la historia:
| Evento | Detalle |
|---|---|
| Problema identificado | Las empresas que utilizan GitHub, GitLab y Azure Devops no podían cambiar las ubicaciones de git sin reescribir las importaciones. |
| Solución propuesta | Use custom domains like go.iain.rocks instead of git hosting URLs |
| Ejemplo dado | go.iain.rocks/boneclone redirects to github.com/thetrueares/boneclone |
| Costo descrito | Una empresa pagó por tres servicios de alojamiento porque no pudo cambiar una URL. |
| Herramienta construida. | Cambridge creó Boneclone para replicar código de esqueletos en múltiples plataformas. |
La conclusión es simple: no acoplen su código Go a GitHub. Utilicen su propio dominio en su lugar. Es un cambio pequeño, pero los libera de una trampa.
Material de origen: “Don't couple your Go code to GitHub,” iain.rocks.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.