Boty zalewają GitHuba? Jest na to sposób

Przyznajmy się szczerze — internet jest zalewany przez boty. Scrapery, crawleery, automatyczne skrypty bombardują stronyrequestami dzień i noc. Operatorzy hostingów Git nie są od tego wolni. Standardowa odpowiedź przepracowanych adminów? Wdrożenie narzędzi typu Anubis, które wykorzystuje proof-of-work do filtrowania niechcianych odwiedzających. Technicznie działa. Ale kurczę, to toporny sposób, który utrudnia życie wszystkim.

Proof-of-work — cierpienie dla użytkowników

Systemy proof-of-work zmuszają przeglądarki do rozwiązywania zagadek obliczeniowych, zanim pozwolą im cokolwiek zobaczyć. Ta sama energochłonna metoda, za którą Bitcoin i Ethereum są krytykowane — praca, która idzie do kosza w momencie ukończenia. Dla programisty próbującego tylko przejrzeć repozytorium, czekanie aż przeglądarka policzy jakieś numery wygląda jak kara za bycie człowiekiem.

Przez dekady optymalizowaliśmy wydajność internetu. Każda milisekunda się liczy. Czasy połączeń zostają zredukowane do teoretycznego minimum. A potem celowo wprowadzamy sztuczne opóźnienia, bo boty są uciążliwe? To jak wyrzucanie całej tej pracy do kosza.

A gdyby tak odwrócić role?

Tu pojawia się koncepcja "do-the-work" — podejście, które w zaskakująco elegancki sposób odwraca tradycyjny model klient-serwer. Zamiast żeby serwer robił całą ciężką pracę, a klienci tylko korzystali, to klient ponosi koszt obliczeniowy dostępu do informacji.

To nie jest takie szalone, szczególnie w kontekście repozytoriów Git. Git przechowuje wszystko jako obiekty — commity, drzewa, bloby, tagi. Każdy fragment danych, który widzisz w przeglądarce Git, jest tylko kalkulacją od tych prymitywów. Masz obiekty — masz wszystko.

Rewolucja po stronie klienta

Najlepsze w tym podejściu? Współczesne przeglądarki są absolutnie zdolne do tej roboty. Pewien deweloper o nicku legoktm zbudował w pełni kliencką przeglądarkę repozytoriów Git, która działa w całości w przeglądarce. Serwer? Służy tylko plikom statycznym — bare repositories przez HTTP. Żadnych skryptów CGI, żadnej bazy danych, żadnego skomplikowanego backendu. Po prostu Apache z kilkoma regułami przepisywania.

Przeglądarka pobiera obiekty na żądanie, zapisuje je w IndexedDB i oblicza diffy, zawartość plików oraz logi commitów lokalnie. To zasadniczo wykonuje partial git clone na żądanie, uzupełniając brakujące obiekty podczas przeglądania. Praca serwera staje się prawie śmiesznie prosta — serwuj pliki.

Czemu to ma znaczenie dla deweloperów i startupów

Jeśli prowadzisz startup lub zarządzasz małym zespołem deweloperskim, to podejście ma kilka poważnych zalet:

Przepustowość to jedyne realne zmartwienie. Skoro serwujesz statyczne pliki, możesz bez problemu postawić CDN przed wszystkim. Twoja przeglądarka repozytoriów staje się praktycznie nieskończenie skalowalna przy niemal zerowej złożoności backendu.

Prywatność poprawia się praktycznie za darmo. Gdy przeglądarka raz zacachuje obiekty, kolejne wizyty nie muszą nic pobierać, jeśli nic się nie zmieniło. Możesz teoretycznie przeglądać repozytorium w pełni offline po pierwszym załadowaniu. Żadnego śledzenia twoich nawyków przeglądania przez serwer przy requestach paginacji.

Deployments stają się absurdalnie proste. Hosting statyczny działa wszędzie. GitHub Pages, Netlify, Cloudflare Pages, czy nawet zwykły bucket object storage — twoja przeglądarka Git staje się infrastrukturą, która praktycznie zarządza się sama.

Połączenie z AI coding

Tu robi się ciekawie, szczególnie dla entuzjastów vibe coding. W miarę jak narzędzia wspomagane AI stają się coraz popularniejsze, będziemy widzieć więcej generowanego kodu, więcej tworzonych repozytoriów i większe zapotrzebowanie na lekkie rozwiązania hostingowe. Systemy takie jak ten wskazują na przyszłość, gdzie infrastruktura deweloperska nie musi być skomplikowanym managed service — może być prosta, statyczna i zaskakująco potężna.

Moc obliczeniowa w przeglądarce użytkownika to praktycznie darmowe zasoby, do których możesz sięgnąć. Zamiast płacić za server-side rendering, zbierasz compute po stronie klienta. Dla wysokiej jakości publicznych repozytoriów może to oznaczać ogromne oszczędności.

Czy to przyszłość?

Wciąż są wczesne dni — potraktuj to jako proof-of-concept pokazujący co jest możliwe, a nie produkcyjne rozwiązanie dla każdego. Ale główna idea jest słuszna: niech klient wykonuje pracę, a serwer może zostać szczupły i zwinny.

Dla hostingu Git konkretnie — jeśli nie potrzebujesz pełnego doświadczenia forge (issue tracking, pull requesty, CI/CD), a chcesz tylko przeglądać kod, to to podejście mogłoby zastąpić instalacje cgit czymś znacznie bardziej skalowalnym i szanującym prywatność.

Następnym razem, gdy będziesz myśleć o tym, jak chronić swoje usługi przed scraperami bez utrudniania życia prawdziwym użytkownikom, rozważ podejście do-the-work. Przeglądarki twoich użytkowników mają wolne cykle. Twoje serwery mają ograniczone zasoby. Niech przeglądarki liczą.

Czasem najlepszym sposobem na rozwiązanie problemu skalowania nie jest dorzucenie więcej mocy serwerowej — tylko rozłożenie pracy tam, gdzie compute już istnieje.