Når botterne tager over: En bedre vej for Git-hosting

Lad os ikke joke med det — internettet flyder over med bots. Scrapere, crawlers og automatiserede scripts hamrer løs på websites døgnet rundt, og Git-hostingudbydere har på ingen måde været forskånet. Den klassiske løsning fra pressede sysadmins har været værktøjer som Anubis, der bruger proof-of-work til at sortere skraldet fra. Det virker. Teknisk set. Men det er en klodset løsning, der straffer alle.

Hvorfor det føles som straf

Proof-of-work systemer tvinger klienter til at løse regneopgaver, før de overhovedet må se indholdet. Det er samme energi-slugende tilgang, som Bitcoin og Ethereum har fået kritik for — arbejde der smides væk i det øjeblik, det er færdigt. For udviklere der bare prøver at browse et repository eller hente noget kode, føles det som en straf at vente på, at browseren arbejder sig igennem opgaver.

Vi har brugt årtier på at optimere webydelse. Hver millisekund tæller. Connection-tider presses ned til deres teoretiske grænser. Og så introducerer vi bevidst kunstige forsinkelser, fordi bots er irriterende? Det føles som at smide årtiers fremskridt ud af vinduet.

Tænk hvis vi vendte det hele på hovedet

Her kommer "do-the-work" ind i billedet — et koncept der inverterer den traditionelle klient-server-relation på en overraskende elegant måde. I stedet for at serveren gør alt arbejdet, mens klienterne sejler igennem, betaler klienten faktisk den regnemæssige pris for at tilgå information.

Det lyder måske skørt, men det giver mening, når vi taler om Git-repositories. Git gemmer alt som objekter — commits, trees, blobs, tags. Hver eneste del af data, du ser i en Git-viewer, er blot en beregning væk fra disse byggesten. Har du objekterne, har du alt.

Browseren som din Git-klient

Det geniale ved denne tilgang er, at moderne browsere absolut kan klare opgaven. En udvikler ved navn legoktm byggede en fuldt client-side Git-repository viewer, der kører udelukkende i browseren. Serveren? Den leverer bare statiske filer — bare repositories over HTTP. Ingen CGI-scripts, ingen database, ingen kompleks backend. Bare Apache med lidt rewrite rules.

Browseren downloader objekter efter behov, gemmer dem i IndexedDB, og beregner diffs, filindhold og commit-log lokalt. Det er i bund og grund en partial git clone on-demand, der henter manglende objekter, mens du browser. Serverens opgave bliver nærmest grinende simpel — bare servér filerne.

Hvorfor det her batter for udviklere og startups

Hvis du driver en startup eller administrerer et lille udviklerhus, har denne tilgang nogle klare fordele:

Båndbredde bliver din eneste reelle bekymring. Fordi du serverer statisk indhold, kan du sætte en CDN foran uden besvær. Din repository viewer bliver virtuelt uendeligt skalerbar med næsten nul backend-kompleksitet.

Privacy følger med næsten gratis. Når først din browser har cached objekterne, behøver efterfølgende besøg ikke hente noget, hvis intet er ændret. Du kan teoretisk set browse et repository fuldt offline efter første load. Ingen server, der tracker dine vaner gennem side-navigation.

Deployment bliver absurd simpelt. Statisk hosting virker overalt. GitHub Pages, Netlify, Cloudflare Pages, eller bare en basic object storage bucket — din Git viewer bliver infrastruktur, der stort set passer sig selv.

Forbindelsen til AI-kodning

Her bliver det interessant for AI-assisteret udvikling. Efterhånden som flere kodeværktøjer baseret på kunstig intelligens vinder indpas, vil vi se mere genereret kode, flere repositories og større efterspørgsel efter letvægts hostingløsninger. Systemer som dette peger mod en fremtid, hvor din udviklingsinfrastruktur ikke behøver at være en kompliceret managed service — det kan være simpelt, statisk og overraskende kraftfuldt.

Regnekraften i brugernes browser er i bund og grund gratis compute, du kan udnytte. I stedet for at betale for server-side rendering, høster du client-side compute. For offentlige repositories med høj trafik kunne det betyde massive besparelser.

Er det her fremtiden?

Det er stadig tidlige dage — tænk på det som et proof-of-concept, der viser hvad der er muligt, snarere end en produktionsklar løsning til alle. Men den grundlæggende idé er sund: lad klienten klare arbejdet, så serveren kan forblive slank og effektiv.

For Git-hosting specifikt, hvis du ikke har brug for den fulde forge-oplevelse — issue tracking, pull requests, CI/CD — og bare vil browse kode, kunne denne tilgang erstatte cgit-installationer med noget langt mere skalerbart og privacy-respektfuldt.

Næste gang du overvejer, hvordan du beskytter dine services mod scrapere uden at gøre livet surt for legitime brugere, så tænk på do-the-work tilgangen. Dine brugeres browsere har ledige kræfter. Dine servere har begrænsede ressourcer. Lad browserne regne.

Nogle gange er den bedste løsning på et skaleringsproblem ikke at smide mere serverkraft efter det — det er at distribuere arbejdet derhen, hvor computerkraften allerede findes.