Amikor a böngésződ végzi el a munkát: a Git új korszaka

A probléma, amit senki sem vesz komolyan

Lássuk be — az internetet elárasztották a botok. Scraperek, crawler-ek, automatizált szkriptek ezrei kopogtatnak folyamatosan a szervereken, és a Git-tárhelyek sem élvezhetik a kivételezettséget. A sysadmin-ok rémálma ez, és sokan az Anubis-hoz hasonló eszközökkel próbálnak védekezni. Ezek proof-of-work rendszerekre épülnek — vagyis a felhasználónak bonyolult számítási feladatokat kell megoldania, mielőtt hozzáférhetne az adatokhoz.

Működik? Technikailag igen. De az a megoldás igazi szenvedés mindenki számára.

Mi a gond a proof-of-work-kal?

A proof-of-work rendszerek lényege: a kliens oldalon kell számítási feladatokat megoldani, mielőtt a szerver kiszolgálná a tartalmat. Ez ugyanaz az energiaigényes megközelítés, amit a Bitcoin és az Ethereum környezeti lábnyoma miatt már sokan kritizáltak — értéktelen munka, amit a pillanat alatt eldobunk.

Fejlesztőként csak arra vágyol, hogy megnézd egy repository tartalmát vagy letölts valamit. Ehelyett a böngésződnek percekig kell számolnia, te meg ülsz és vársz. Ez olyan, mintha büntetést kapnál azért, hogy ember vagy.

Évtizedek óta optimalizáljuk a webes teljesítményt. Minden milliszekundum számít. A kapcsolatfelépülési idők oda csökkentek, ahol elméletileg lehetnek. És akkor mi szándékosan késleltetést építünk be, mert a botok zavaróak? Ez mintha dobálnánk az összes eddigi munkát.

Fordítsuk meg a logikát!

Itt jön képbe a "do-the-work" koncepció — ez gyökeresen megfordítja a hagyományos kliens-szerver viszonyt. A lényeg egyszerű: ne a szerver dolgozzon, hanem a kliens fizesse meg a hozzáférés computációs költségét.

Hangzik vadul? Pedig Git repository-knál ez különösen jól működik. A Git objektumokból építkezik — commit-okból, tree-kből, blob-okból, tag-ekből. Minden, amit egy Git nézőben látsz, tulajdonképpen ezekből az alapelemekből van kiszámítva. Ha megvannak az objektumok, megvan minden.

A kliens-oldali Git viewer forradalma

A zseniális az, hogy a modern böngészők tökéletesen alkalmasak erre. Van már teljesen kliens-oldali Git repository viewer, ami kizárólag a böngészőben fut. A szerver szerepe? Gyakorlatilag csak fájlokat szolgál ki — bare repository-kat HTTP-n. Semmi CGI, semmi adatbázis, semmi komplex backend. Csak Apache rewrite szabályok.

A böngésző letölti a szükséges objektumokat, tárolja őket IndexedDB-ben, és helyileg számítja ki a diff-eket, fájltartalmakat, commit logokat. Olyan, mintha részleges git clone történne igény szerint, folyamatosan pótolva a hiányzó objektumokat böngészés közben. A szerver feladata nevetségesen egyszerűvé válik.

Miért jó ez fejlesztőknek és startup-oknak?

Ha startup-ot viszel vagy kisebb fejlesztői csapatot irányítasz, ennek a megközelítésnek komoly előnyei vannak:

A sávszélesség lesz az egyetlen valódi korlát. Mivel statikus tartalmat szolgálsz ki, gond nélkül tehetsz CDN-t a rendszered elé. A repository viewer gyakorlatilag korlátlanul skálázódik, minimális backend komplexitással.

A privacy szinte mellékesen javul. Miután a böngésződ eltárolta az objektumokat, a későbbi látogatásoknál nem kell semmit letölteni, ha nem változott semmi. Elvileg teljesen offline böngészheted a repository-t az első betöltés után. A szerver nem figyeli, mit nézel.

A deploy gyerekjáték lesz. Statikus hosting mindenhol működik. GitHub Pages, Netlify, Cloudflare Pages, vagy akár egy egyszerű object storage bucket — a Git viewer gyakorlatilag önmenedzselő infrastruktúra.

Az AI-kódolás kapcsolata

És itt válik igazán érdekessé a dolog azok számára, akik az AI-asszisztált fejlesztésben látják a jövőt. Ahogy egyre több kódot generálnak a mesterséges intelligencia eszközök, egyre több repository jön létre, és egyre nagyobb az igény a könnyű súlyú hosting megoldásokra. Az ilyen rendszerek afelé mutatnak, hogy a fejlesztői infrastruktúra nem feltétlenül bonyolult managed service kell legyen — lehet egyszerű, statikus és meglepően erős.

A felhasználó böngészőjében lévő számítási kapacitás lényegében ingyenesen használható erőforrás. Nem szerver-oldali renderelésre költesz, hanem a kliens oldali computét használod. Nagy forgalmú publikus repository-knál ez hatalmas költségmegtakarítást jelenthet.

Ez lenne a jövő?

Még korai fázisban vagyunk — ezt inkább proof-of-conceptnek tekintsük, ami megmutatja, mi lehetséges, nem pedig production-ready megoldásnak mindenkinek. De az alapötlet solid: ha a kliens végzi a munkát, a szerver karcsú és hatékony maradhat.

Git hosting esetében, ha nincs szükséged a teljes forge élményre — issue tracking, pull request-ek, CI/CD — és csak kódot akarsz böngészni, ez a megközelítés válthatja a cgit telepítéseket valamivel sokkal skálázhatóbbá és privacy-barátabbá.

A következő alkalommal, amikor az jár a fejedben, hogyan védd a szolgáltatásaidat a scraperek ellen anélkül, hogy elriasztanád a valódi felhasználókat, gondolj a do-the-work megközelítésre. A felhasználók böngészőiben van szabad kapacitás. A szervereiden korlátozottak az erőforrások. Engedd, hogy a böngésző számoljon.

Néha a legjobb megoldás egy skálázási problémára nem az, hogy több szervert dobsz rá — hanem az, hogy a munkát odaviszed, ahol a compute már létezik.