Streszczenie AI
Workflow w n8n automatyzuje gromadzenie i analizę repozytoriów GitHub Trending, łącząc web scraping, MySQL i modele LLM do oceny potencjału wdrożeniowego. System eliminuje ręczne śledzenie, zapewniając deduplikację danych, przetwarzanie wsadowe oraz asynchroniczne powiadomienia przez Discord i Google Drive. Dzięki temu zespoły mogą szybciej zidentyfikować wartościowe projekty i zintegrować je z własną infrastrukturą.
Automatyzacja procesów gromadzenia, strukturyzowania i wielowymiarowej analizy danych staje się nieodzownym elementem pracy z otwartym oprogramowaniem. Wraz z wykładniczym wzrostem liczby projektów open source, ręczne śledzenie nowości i ocena ich przydatności pochłaniają zasoby, które zespoły inżynierskie mogłyby przeznaczyć na właściwy rozwój własnych aplikacji. Przedstawiony przepływ pracy (workflow) w platformie n8n demonstruje, jak skutecznie zintegrować mechanizmy bezkodowego web scrapingu, relacyjne bazy danych oraz duże modele językowe (LLM) do ciągłego monitorowania zyskujących popularność repozytoriów. Takie rozwiązanie pozwala na całkowicie zautomatyzowane pozyskiwanie surowych informacji z sieci, ich ewaluację pod kątem potencjału wdrożeniowego oraz asynchroniczną dystrybucję przetworzonych wyników za pośrednictwem dedykowanych kanałów komunikacyjnych i dysków chmurowych.
Uwaga
By skorzystać z tego workflow musisz najpierw utworzyć bazę przez wykonanie poniższej komendy.
CREATE TABLE `github_db` (
`id` int NOT NULL,
`link` text NOT NULL,
`name` text NOT NULL,
`original` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci,
`translated` text CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci,
`processed` tinyint(1) NOT NULL,
`when_added` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
Architektura rozwiązania i przepływ danych
Zaprojektowany system automatyzacji opiera się na złożonej architekturze potokowej (pipeline), w której surowe dane z internetu przepływają przez kolejne węzły transformujące, weryfikujące oraz wzbogacające kontekst. Cały proces został zaprojektowany z myślą o odporności na błędy sieciowe (rezyliencji) – wiele węzłów posiada skonfigurowaną flagę onError: continueRegularOutput, co zapobiega zatrzymaniu całego skryptu w przypadku awarii jednego z żądań. Działanie systemu można podzielić na cztery kluczowe fazy: celowaną ekstrakcję adresów URL, ścisłe zarządzanie stanem w bazie danych, głęboką analizę semantyczną z wykorzystaniem sztucznej inteligencji oraz formatowanie i wielokanałowe powiadamianie.
Faza 1: Ekstrakcja danych bazowych i normalizacja odnośników
Proces rozpoczyna się od zdefiniowania punktu wejścia, którym w tym scenariuszu jest oficjalna zakładka GitHub Trending. Zamiast polegać na restrykcyjnym i limitowanym interfejsie API GitHuba, system wykorzystuje klasyczne metody scrapowania. Moduł węzła HTTP Request w połączeniu z węzłem HTML Extract bezpośrednio pobiera i parsuje strukturę drzewa DOM witryny.
Kluczowym aspektem inżynieryjnym na tym etapie jest precyzyjne wyodrębnienie selektorów CSS (np. klas takich jak .Box-row oraz .Link), które bezbłędnie identyfikują wiersze z projektami. Ponieważ wyodrębnione odnośniki mają format względny (np. /n8n-io/n8n), niezbędna jest ich natychmiastowa transformacja. Zastosowanie węzła operacyjnego Set (nazwanego w strukturze jako „Naprawa linków”) pozwala na konkatenację z bazową domeną i ujednolicenie formatu na adresy bezwzględne. Normalizacja ta jest krytyczna, ponieważ adres URL staje się unikalnym identyfikatorem (kluczem głównym) w kolejnych krokach weryfikacji bazy danych.
Faza 2: Zarządzanie stanem i deduplikacja za pomocą MySQL
Aby zapobiec wielokrotnemu pobieraniu oraz kosztownemu przetwarzaniu przez modele AI tych samych repozytoriów dzień po dniu, przepływ pracy implementuje własną pamięć stanu opartą na relacyjnej bazie danych MySQL. Jest to klasyczny i wysoce wydajny wzorzec deduplikacji w asynchronicznych systemach ETL (Extract, Transform, Load).
| Zastosowana operacja SQL | Znaczenie techniczne w przepływie pracy |
|---|---|
| Weryfikacja istnienia (SELECT) | System dynamicznie odpytuje tabelę github_db, sprawdzając, czy wyodrębniony adres URL figuruje już w rejestrze. (Nie zapomnij wcześniej utworzyć tej bazy.) |
| Rejestracja nowości (INSERT) | Projekty, których brakuje w systemie, są dodawane jako nowe rekordy z przypisaną flagą processed = 0. |
| Sanityzacja danych (DELETE) | Dedykowany węzeł bazy danych wyszukuje i usuwa nieprawidłowe wpisy (np. puste nazwy, adresy zawierające tylko domenę bazową bez ścieżki repozytorium), które mogły wyniknąć z drobnych zmian w layoucie strony GitHuba. |
| Inicjalizacja kolejki (SELECT z LIMIT) | Skrypt wydobywa z bazy partię do 200 najstarszych nieprzetworzonych projektów, przekazując je do właściwej logiki pobierania szczegółów. |
Faza 3: Przetwarzanie wsadowe i głęboka analiza semantyczna LLM
Jednoczesne odpytywanie zewnętrznych serwerów o pełną zawartość kilkudziesięciu różnych repozytoriów szybko doprowadziłoby do nałożenia blokad (rate limits) lub odrzucenia połączeń (HTTP 429 Too Many Requests). Wymusiło to zastosowanie wzorca wsadowego. Węzeł „Split In Batches” fragmentuje masowy strumień danych na małe pakiety wielkości 10 elementów. Dla każdego pojedynczego pakietu skrypt realizuje żądanie HTTP pobierające strukturę HTML głównej strony projektu, z której kolejny parser HTML wydobywa najważniejsze kontenery tekstowe zawierające opis i sekcję README.
Prawdziwym sercem analitycznym tego rozwiązania jest węzeł LangChain (Basic LLM Chain). Zamiast polegać na sztywnych wyrażeniach regularnych, system deleguje rozpoznawanie wzorców i ekstrakcję sensu do dużego modelu językowego. Inżynieria podpowiedzi (prompt engineering) zrealizowana w tym węźle jest niezwykle rygorystyczna. Prompt systemowy instruuje model, aby pisał wyłącznie w języku polskim, stosował ton techniczny i nie kopiował tekstów dosłownie, lecz syntetyzował ich znaczenie.
Na podstawie dostępnych danych o projekcie GitHub przygotuj analizę repozytorium.
Projekt:
{{ $json.name }}
Zasady:
Pisz wyłącznie po polsku.
Styl: rzeczowy, konkretny, techniczny.
Nie kopiuj treści 1:1 z README — parafrazuj i syntetyzuj.
Jeśli brakuje danych, wpisz: "Brak informacji".
Jeśli dane wejściowe są puste, nieczytelne lub niewystarczające, zwróć wyłącznie: "Błąd danych".
Nie dodawaj komentarzy poza wskazanym formatem.
Odpowiedź w czystym markdown.
Oceń projekt pod kątem:
możliwości uruchomienia lokalnie,
wykorzystania modeli AI (zwłaszcza LLM),
praktyczności zastosowań,
jakości i aktywności repozytorium.
Zwróć odpowiedź dokładnie w tym formacie:
Nazwa projektu
Opis:
2–4 zdania czym jest projekt, do czego służy i co go wyróżnia.
Zastosowania:
...
...
...
Zalety:
...
...
...
...
Wady / ograniczenia:
...
...
...
...
Uruchamianie lokalne:
Tak / Częściowo / Nie
Wykorzystanie AI / LLM:
Tak / Częściowo / Nie
Aktywność repozytorium:
Wysoka / Średnia / Niska / Brak informacji
Obsługiwane modele / technologie:
...
...
...
Jeśli brak danych: Brak informacji
Wymagania techniczne:
System / sprzęt: ...
Uruchomienie: ...
Zależności: ...
Jeśli brak danych: Brak informacji
Docelowi użytkownicy:
...
...
...
Ocena końcowa:
1–2 zdania podsumowania wartości projektu i jego potencjalnego zastosowania.
Maksymalnie 2000 znaków, optymalnie 1500–1800.Taka parametryzacja gwarantuje, że nieustrukturyzowany kod HTML wejściowy zostaje zamieniony na wysoce ustrukturyzowany, przewidywalny raport. Po udanym przejściu przez ten węzeł, system wykonuje aktualizację (UPDATE) rekordu w bazie danych, ustawiając flagę processed = 1 i nadpisując kolumny przetłumaczonym i przeanalizowanym tekstem. Zamyka to cykl weryfikacji i analizy logicznej dla konkretnego wpisu.
Faza 4: Adaptacyjna dystrybucja komunikatów i omijanie limitów API
Ostatnim krokiem jest asynchroniczne powiadomienie użytkownika końcowego o nowym znalezisku. Architektura przewiduje dystrybucję powiadomień za pomocą webhooków aplikacji Discord. Ponieważ Discord posiada sztywne ograniczenie wielkości payloadu dla pojedynczej wiadomości wynoszące 2000 znaków, konieczne było wdrożenie pętli warunkowej na poziomie węzłów warunkowych (Node IF).
- Gdy wygenerowany przez LLM raport posiada objętość powyżej 2000 znaków (co jest częste przy rozbudowanych analizach zalet i wad), aktywuje się mechanizm tnący. Za pomocą funkcji split na bazie wyrażeń regularnych ciąg tekstu dzielony jest na bezpieczne tablice o długości maksymalnie 1400 znaków. Następnie węzeł „Split Out” iteracyjnie wysyła je na kanał Discorda, tworząc spójny wizualnie wątek.
- Jeśli tekst mieści się w dopuszczalnym progu, system omija pętlę dzielącą i wysyła pełną wiadomość jednorazowo, umieszczoną w znacznikach bloku kodu dla zachowania czytelności składni Markdown.
Dla celów archiwizacji, budowania historycznych zbiorów danych oraz łatwiejszej redystrybucji poza komunikatorami, system konwertuje zebrane dane tekstowe z powrotem na obiekt binarny w postaci pliku result.csv. Nazwa pliku jest dynamicznie generowana poprzez dołączenie bieżącej daty (np. github-2026-07-07.csv). Skrypt automatycznie loguje się do API Google Drive i umieszcza plik we wskazanym identyfikatorze folderu, a kopię binarną załącza do dodatkowego, dedykowanego kanału notyfikacyjnego Discord.
Demo
Wykorzystany sprzęt i model oraz czas lokalnej analizy.
Mac mini m4 24 GB pamięci zunifikowanej(przepustowość pamięci 120 GB/s )
Model: gemma4:e2b-mlx
Czas pojedynczej analizy: 28.243s, promptTokens 3135, completionTokens 1023
Repozytorium
Przedstawione workflow znajdziesz na repozytium ŁowcówAi, automatyzacja nosi nazwę github-scrapper.
Praktyczne zastosowania zautomatyzowanej analizy trendów
Przeniesienie ciężaru eksploracji nowych rozwiązań z inżyniera na bota opartego na n8n oraz LangChain otwiera przed organizacjami i programistami szereg praktycznych korzyści operacyjnych:
- Ciągły monitoring ekosystemu AI: Wraz z wysypem nowych bibliotek, agent dzięki zdefiniowanemu wejściu „Wykorzystanie AI / LLM” pozwala natychmiastowo wyłuskiwać frameworki zajmujące się uczeniem maszynowym spośród typowych projektów webowych czy narzędzi systemowych.
- Optymalizacja zarządzania wiedzą (Knowledge Management): Zamiast rozproszonych zakładek w przeglądarce, zespół otrzymuje usystematyzowany magazyn CSV na Google Drive. Może on zasilić firmową platformę RAG (Retrieval-Augmented Generation) dostarczając deweloperom kontekstu podczas pracy z korporacyjnymi botami.
- Przedwstępny audyt wdrożeniowy: Ponieważ sztuczna inteligencja ma za zadanie wyodrębnić „wymagania techniczne” oraz odpowiedzieć na pytanie o „możliwość uruchomienia lokalnie”, architekci bezpieczeństwa od razu wiedzą, czy projekt wymaga udostępniania danych zewnętrznym API, czy może zostać zhostowany bezpiecznie we własnym środowisku typu on-premise.
- Tworzenie niezależnych agregatorów treści: Tak przygotowane i wystandaryzowane pakiety Markdown mogą służyć za bezpośrednie źródło danych zasilające blogi technologiczne, newslettery lub automatycznie aktualizowane portfele branżowe bez ingerencji redaktorów.
Podsumowanie architektoniczne
Budowa zaawansowanych systemów scrapujących zintegrowanych z modelami LLM przestaje wymagać pisania tysięcy linii imperatywnego kodu w językach takich jak Python czy JavaScript. Wykorzystanie platform open source opartych o graficzny interfejs wizualny typu n8n umożliwia szybkie zestawienie procesów wydobywania wiedzy. Zastosowanie bazy SQL w roli pośrednika (stanu maszyny) rozwiązuje największe bolączki takich systemów – duplikację i utratę danych przy błędach zapytań. Dodanie do tego warstwy sztucznej inteligencji, która działa jako inteligentny filtr, zmienia postrzeganie web scrapingu: z prostego zbieracza danych na inteligentnego analityka zdolnego oceniać przydatność techniczną odnajdowanych rozwiązań.
Źródła
- Scrape latest Github trending repositories – n8n Workflows
- GitHub – Touxan/n8n-ultimate-scraper
- n8n GitHub Trending Repositories Scraper Template
- GitHub – The-AI-Workshops/Crawl4AI-N8N-Agent
Często zadawane pytania (FAQ)
Pytanie: Jak działa węzeł „Naprawa linków” i dlaczego jest potrzebny?
Odpowiedź: Węzeł „Naprawa linków” przekształca względne adresy GitHub (np. /user/repo) w pełne URL‑y, łącząc je z domeną bazową. Dzięki temu każdy link staje się unikalnym identyfikatorem, co jest kluczowe przy de-duplication i przechowywaniu w bazie danych.
Pytanie: Dlaczego workflow korzysta z MySQL zamiast e.g. PostgreSQL albo plików CSV?
Odpowiedź: MySQL zapewnia szybkie, transakcyjne operacje SELECT/INSERT/DELETE, co pozwala na skuteczną deduplikację i zarządzanie stanem rekordów. Relacyjna struktura ułatwia także filtrowanie najstarszych nieprzetworzonych repozytoriów oraz eliminuje ryzyko utraty danych w przypadku błędów zapytań.
Pytanie: Na czym polega podział danych w węźle „Split In Batches” i jakie ma korzyści?
Odpowiedź: Węzeł dzieli zbiór rekordów na małe paczki (np. po 10 repozytoriów), co zapobiega przekroczeniu limitów API GitHub i ułatwia kontrolę przepływu pracy. Dzięki temu workflow może równocześnie przetwarzać wiele repozytoriów, zachowując wysoką wydajność i niskie ryzyko blokad.
Pytanie: Jak model językowy ocenia repozytorium i jakie elementy raportu generuje?
Odpowiedź: LLM otrzymuje prompt opisujący analizę repozytorium, z instrukcjami do parafrazy i syntetyzowania treści w języku polskim. Wyjście zawiera podsumowanie opisu, zastosowań, zalet, wad, wymagan i oceny AI oraz podsumowanie, które następnie jest zapisywane w bazie i przekazywane do kanałów komunikacyjnych.
Pytanie: W jaki sposób system radzi sobie z limitem 2000 znaków w wiadomościach Discorda?
Odpowiedź: System sprawdza długość wygenerowanego raportu; jeśli przekracza 2000 znaków, działa maska, która dzieli tekst na fragmenty o maksymalnej długości 1400 znaków i wysyła je w kolejnych wiadomościach, tworząc spójny wątek. Jeśli raport mieści się w limicie, jest wysyłany w jednej wiadomości z formatowaniem Markdown.
