Waarom We Het Probleem Met Git-scrapers Helemaal Verkeerd Aanpakken

Laten we eerlijk zijn: het internet verdrinkt in bots. Scrapers, crawlers en geautomatiseerde scripts beuken constant op websites in, en git repository-hosters hebben hier flink onder te lijden. De standaardreactie van overbelaste sysadmins? Meestal een proof-of-work systeem. Technisch werkt het. Maar het is een onhandige oplossing die iedereen treft.

Waarom Oneerlijk Verdelen Van Last Geen Goede Oplossing Is

Proof-of-work systemen dwingen browsers om rekenpuzzels op te lossen voordat ze toegang krijgen tot content. Hetzelfde energievretende gedoe waar Bitcoin en Ethereum al jaren op kritiek krijgen — werk dat wordt weggegooid zodra het klaar is. Voor developers die gewoon een repository willen bekijken of code willen pullen, voelt wachten tot je browser cijfers heeft berekend als een boete voor het mens zijn.

We hebben decennia besteed aan het optimaliseren van webprestaties. Elke milliseconde telt. Connectietijden worden tot hun theoretische limieten uitgeknepen. En dan introduceren we kunstmatige vertragingen omdat bots vervelend zijn? Dat voelt als al die vooruitgang weggooien.

En Als We De Rollen Nu Eens Omdraaien?

Hier komt "do-the-work" om de hoek kijken — een concept dat de traditionele client-server relatie op een verrassend elegante manier omkeert. In plaats van dat de server al het zware werk doet terwijl clients alleen meelezen, betaalt de client nu zelf de rekenkosten voor toegang tot informatie.

Dit is minder gek dan het klinkt, vooral bij git repositories. Git slaat alles op als objecten — commits, trees, blobs, tags. Elk stukje data dat je in een Git viewer ziet, is slechts een berekening verwijderd van deze bouwstenen. Heb je de objecten, dan heb je alles.

De Client-Side Git Viewer Revolutie

Het geniale aan deze aanpak is dat moderne browsers hier prima toe in staat zijn. Een developer genaamd legoktm bouwde een volledig client-side Git repository viewer die volledig in je browser draait. De server? Die serveert alleen maar statische bestanden — bare repositories over HTTP. Geen CGI-scripts, geen database, geen ingewikkelde backend. Gewoon Apache met wat rewrite rules.

De browser downloadt objecten wanneer nodig, slaat ze op in IndexedDB, en berekent diffs, bestandsinhoud en commit logs lokaal. Het draait in wezen een gedeeltelijke git clone on-demand, waarbij ontbrekende objecten worden aangevuld terwijl je surft. De taak van de server wordt bijna belachelijk eenvoudig — gewoon bestanden serveren.

Waarom Dit Belangrijk Is Voor Developers En Startups

Als je een startup runt of een klein development team beheert, heeft deze aanpak serieuze voordelen:

Bandwidth wordt je enige echte zorg. Omdat je statische content serveert, kun je zonder problemen een CDN ervoor zetten. Je repository viewer wordt virtueel oneindig schaalbaar met vrijwel geen backend-complexiteit.

Privacy verbetert bijna vanzelf. Zodra je browser de objecten heeft gecacht, hoeven vervolgbezoeken niets meer op te halen als er niets is veranderd. Je zou theoretisch een repository volledig offline kunnen browsen na de eerste keer laden. Geen server die je browsegedrag volgt via paginatie-requests.

Deployen wordt absurd simpel. Statische hosting werkt overal. GitHub Pages, Netlify, Cloudflare Pages, of zelfs een standaard object storage bucket — je Git viewer wordt infrastructuur die vrijwel zichzelf beheert.

De Verbinding Met AI Coding

Hier wordt het interessant voor de vibe coding crowd. Naarmate AI-gestuurde ontwikkeltools populairder worden, zien we meer code gegenereerd, meer repositories aangemaakt, en meer vraag naar lichte hosting-oplossingen. Systemen als dit wijzen naar een toekomst waarin je ontwikkelinfrastructuur geen ingewikkeld managed service hoeft te zijn — het kan simpel, statisch en verrassend krachtig zijn.

De rekenkracht in de browser van een gebruiker is in wezen gratis rekenwerk waar je gebruik van kunt maken. In plaats van te betalen voor server-side rendering, oogst je client-side compute. Voor drukbezochte publieke repositories kan dit enorme kostenbesparingen opleveren.

Is Dit De Toekomst?

Het is nog pril — beschouw dit als een proof-of-concept dat laat zien wat mogelijk is, in plaats van een productieklare oplossing voor iedereen. Maar het kernidee is solide: laat de client het werk doen, en de server kan rank en lean blijven.

Voor Git hosting specifiek: als je de full forge-ervaring niet nodig hebt — issue tracking, pull requests, CI/CD — en je wilt alleen code browsen, dan zou deze aanpak cgit installaties kunnen vervangen door iets veel schaalbaarder en privacy-vriendelijker.

De volgende keer dat je nadenkt over hoe je je services beschermt tegen scrapers zonder het leven zuur te maken voor legitieme gebruikers, denk dan aan de do-the-work aanpak. De browsers van je gebruikers hebben spare cycles. Je servers hebben beperkte resources. Laat de browsers het rekenwerk doen.

Soms is de beste manier om een schaalbaarheidsprobleem op te lossen niet door meer serverkracht toe te voegen — maar door het werk te verdelen naar waar de compute al aanwezig is.