Eine GitHub-Suche nach "facebook scraper" liefert 475 Repositories. Nur 62 davon wurden in den letzten sechs Monaten aktualisiert.
Genau diese Lücke zwischen „verfügbar“ und „tatsächlich funktionsfähig“ erzählt die ganze Geschichte des Facebook-Scrapings auf GitHub im Jahr 2026.
Ich habe viel Zeit damit verbracht, Issue-Tabs in Repos, Beschwerden auf Reddit und echte Ausgaben dieser Tools zu prüfen. Das Muster ist klar: Die meisten hoch bewerteten Projekte sind stillschweigend kaputt, die Maintainer sind abgesprungen und Facebooks Anti-Scraping-Abwehr wird immer stärker. Entwickler und Business-Anwender landen immer wieder bei denselben Suchergebnissen, installieren dieselben Repos und stoßen auf dieselben leeren Resultate. Dieser Artikel ist ein Reality-Check für 2026 — ein ehrlicher Überblick darüber, welche Repos Ihre Zeit noch wert sind, wie Facebook sie kaputt macht und wann Sie GitHub besser ganz links liegen lassen.
Warum Menschen auf GitHub nach einem Facebook Scraper suchen
Die Anwendungsfälle hinter dieser Suche sind seit Jahren dieselben — auch wenn die Tools ständig auseinanderfallen:
- Lead-Generierung: Kontaktdaten von Unternehmensseiten wie E-Mails, Telefonnummern und Adressen für Outreach extrahieren
- Marketplace-Monitoring: Produktangebote, Preise und Verkäuferdaten für E-Commerce oder Arbitrage verfolgen
- Gruppenanalyse: Beiträge und Kommentare für Marktforschung, OSINT oder Community-Management archivieren
- Content- und Beitragsarchivierung: Öffentliche Seitenposts, Reaktionen, Bilder und Zeitstempel sichern
- Event-Aggregation: Veranstaltungstitel, Termine, Orte und Organisatoren zusammentragen
Der Reiz von GitHub liegt auf der Hand: sichtbarer Code, keine Kosten, theoretisch Community-Pflege und volle Kontrolle über Felder und Pipelines.
Das Problem: Sterne und Forks sagen nichts darüber aus, ob etwas aktuell noch funktioniert. Unter den Top-10-Repositories mit exakt dieser Suchphrase nach Sternen waren Stand April 2026 alle 10 länger als 12 Monate veraltet. Das ist kein Ausreißer, sondern die Regel.
Ein Reddit-Nutzer schrieb in einem Thread von November 2025 nach sechs Monaten Versuch und Irrtum ganz offen, es sei „unmöglich, ohne entweder für eine externe Data-Scraping-Anwendung zu zahlen“ oder Python plus JS-Rendering plus erhebliche Rechenleistung zu nutzen. Ein anderer fasste es in einer Diskussion im April 2026 so zusammen: „Facebook ist eines der schwierigeren Ziele zum Scrapen, weil sie Automatisierung aggressiv blockieren“, und Browser-Automation sei „fragil, weil Facebook sein DOM ständig verändert.“
Die Anwendungsfälle sind real. Die Nachfrage ist real. Die Frustration ist ebenfalls real. Um genau diese Lücke geht es in diesem Artikel.
Was ist ein Facebook-Scraper-Repo auf GitHub eigentlich?
Ein „Facebook Scraper“ auf GitHub ist ein Open-Source-Skript — meist in Python —, das öffentliche Daten von Facebook-Seiten, Posts, Gruppen, Marketplace oder Profilen programmgesteuert ausliest. Nicht alle arbeiten auf dieselbe Art. Drei Architekturen dominieren:
Browser-Automation-Scraper vs. API-Wrapper vs. direkte HTTP-Scraper
| Ansatz | Typischer Stack | Stärke | Schwäche |
|---|---|---|---|
| Browser-Automation | Selenium, Playwright, Puppeteer | Kann Login-Hürden umgehen, ahmt echtes Nutzerverhalten nach | Langsam, ressourcenintensiv, leicht per Fingerprinting erkennbar, wenn nicht sauber konfiguriert |
| Offizieller API-Wrapper | Meta Graph API / Pages API | Stabil, dokumentiert, compliant bei Freigabe | Stark eingeschränkt — die meisten öffentlichen Post-/Gruppendaten sind nicht mehr verfügbar |
| Direkter HTTP-Scraper | requests, HTML-Parsing, undokumentierte Endpunkte | Schnell und leichtgewichtig, wenn er funktioniert | Bricht, sobald Facebook Seitenstruktur oder Anti-Bot-Maßnahmen ändert |
kevinzg/facebook-scraper ist das klassische Beispiel für einen direkten HTTP-Scraper: Er liest öffentliche Seiten „ohne API-Key“ über direkte Requests und Parsing aus. apurvmishra99/facebook-scraper-selenium steht für Browser-Automation. minimaxir/facebook-page-post-scraper repräsentiert die alte Graph-API-Ära, in der Skripte Seiten- und Gruppenposts über offizielle Endpunkte abrufen konnten, die heute nicht mehr breit verfügbar sind.
Zu den typischen Ziel-Daten in diesen Repos gehören Post-Texte, Zeitstempel, Reaktions- und Kommentarzahlen, Bild-URLs, Seitenmetadaten (Kategorie, Telefon, E-Mail, Follower-Zahl), Marketplace-Angebotsdaten sowie Gruppen- oder Event-Metadaten.
Im Jahr 2026 geht es beim echten Kompromiss nicht mehr um die Sprachpräferenz. Es geht darum, welchen Typ von Ausfall Sie akzeptieren können.
Der Freshness-Check 2026 für Facebook-Scraper auf GitHub: Welche Repos funktionieren wirklich?
Ich habe die bekanntesten und am häufigsten empfohlenen Facebook-Scraper-Repos auf GitHub gegen reale Daten aus 2026 geprüft — nicht gegen Readme-Versprechen, sondern anhand von Commit-Daten, Issue-Queues und Community-Berichten. Das ist der wichtigste Abschnitt.
Die vollständige Freshness-Analyse
Ein paar Dinge fallen sofort auf:
- Selbst der „aktive Fork“ (moda20) wurde seit Juni 2024 nicht mehr gepusht.
- Die Issue-Queues erzählen die echte Geschichte schneller als Readmes.
- Sowohl kevinzg als auch moda20 geben in ihren pyproject.toml-Dateien weiterhin Python ^3.6 an — ein Hinweis darauf, dass die Dependency-Basis nicht modernisiert wurde.
kevinzg/facebook-scraper
Der bekannteste Python-Facebook-Scraper auf GitHub. Das README beschreibt das Scrapen von Seiten und Gruppen, Login per Credentials oder Cookies sowie Post-Felder wie comments, image, images, likes, post_id, post_text, text und time.
Das operative Signal ist jedoch schwach:
- Letzter Push: 22. Juni 2024
- Offene Issues: 438 — darunter Titel wie „Example Scrape does not return any posts“
- Der Maintainer hat auf aktuelle Issues nicht reagiert
Fazit: Teilweise kaputt. Für kleine Experimente mit öffentlichen Seiten und als Referenz für Feldnamen noch nützlich, aber nicht zuverlässig für den Produktionseinsatz.
moda20/facebook-scraper (Community-Fork)
Der sichtbarste Fork von kevinzg, mit zusätzlichen Optionen und Marketplace-orientierten Helfern wie extract_listing, dokumentiert im README.
Die Issue-Queue macht die Probleme deutlich:
- „mbasic is gone“
- „CLI 'Couldn't get any posts.'“
- „https://mbasic.facebook.com is no longer working"
Wenn das vereinfachte mbasic-Frontend sich ändert oder verschwindet, bricht auf einen Schlag eine ganze Klasse von Scrapern ein.
Fazit: Der bekannteste Fork, aber 2026 ebenfalls veraltet und fragil. Wenn Sie unbedingt eine GitHub-basierte Lösung wollen, ist er der erste Testkandidat — erwarten Sie aber keine Stabilität.
minimaxir/facebook-page-post-scraper
Früher ein sehr praktisches Graph-API-Tool, um Posts, Reaktionen, Kommentare und Metadaten aus öffentlichen Seiten und offenen Gruppen in CSVs zu sammeln. Das README erklärt noch heute die Nutzung von App ID und App Secret einer Facebook-App.
Im Jahr 2026 ist es ein historisches Artefakt:
- Letzter Push: 23. Mai 2019
- Offene Issues: 53 — darunter „HTTP 400 Error Bad Request“ und „No data retrieved!!“
Fazit: Aufgegeben. Stark an ein API-Berechtigungsmodell gekoppelt, das Meta inzwischen deutlich eingeschränkt hat.
Weitere erwähnenswerte Repos
- passivebot/facebook-marketplace-scraper: Nützlich für Marketplace-Szenarien, aber die Issue-Queue enthält Einträge wie „login to view the content“, „CSS selectors outdated“ und „Getting blocked“. Ein Einzeiler, der ziemlich genau zeigt, was beim Marketplace-Scraping kaputtgeht.
- apurvmishra99/facebook-scraper-selenium: Hat ein Issue, das wortwörtlich „Does it work with new Facebook layout?“ aus dem September 2020 fragt. Das sagt fast alles.
- Mhmd-Hisham/selenium_facebook_scraper und anabastos/faceteer: Beide haben nicht genug aktuelle Aktivität, um Vertrauen zu rechtfertigen.
Facebooks Anti-Scraping-Abwehr: Womit jedes GitHub-Scraper-Repo konkurrieren muss
Die meisten Artikel zu diesem Thema liefern nur vage „ToS prüfen“-Hinweise. Das bringt niemanden weiter.
Facebook besitzt eines der aggressivsten Anti-Scraping-Systeme unter allen großen Plattformen. Diese konkreten Schutzschichten zu verstehen, macht den Unterschied zwischen einem funktionierenden Scraper und einem Nachmittag voller leerer Ausgaben.
Metas eigener Engineering-Beitrag von Februar 2025 beschreibt ein „Anti Scraping team“, das per statischer Analyse über die gesamte Codebasis Scraping-Vektoren identifiziert, Unterlassungsschreiben verschickt, Accounts deaktiviert und auf Rate-Limiting-Systeme setzt. Das ist keine Theorie, sondern organisatorisch verankerte Praxis.
Zufällige DOM- und CSS-Klassennamen
Facebook verändert HTML-Element-IDs, Klassennamen und Seitenstrukturen absichtlich zufällig. Wie ein r/webscraping-Kommentator es formulierte: „No normal scraper can work on Facebook. The HTML mutates between refreshes.“
Was kaputtgeht: XPath- und CSS-Selektoren, die letzte Woche noch funktionierten, liefern heute nichts.
Gegenmaßnahme: Wenn möglich textbasierte oder attributbasierte Selektoren verwenden. KI-basierte Parser, die Seiteninhalt lesen statt sich auf starre Selektoren zu verlassen, kommen damit besser zurecht. Selektorpflege ist als laufender Aufwand einzuplanen.
Login-Walls und Session-Management
Viele Facebook-Bereiche — Profile, Gruppen, manche Marketplace-Angebote — sind nur nach Login sichtbar. Headless-Browser werden umgeleitet oder erhalten abgespecktes HTML. Im Issue-Tab des passivebot-Marketplace-Scrapers taucht „login to view the content“ ganz oben auf.
Was kaputtgeht: Anonyme Requests sehen Inhalte nicht oder landen komplett auf Umleitungen.
Gegenmaßnahme: Session-Cookies aus einer echten Browsersitzung nutzen oder browserbasierte Scraping-Tools verwenden, die innerhalb Ihrer eingeloggten Session arbeiten. Account-Rotation ist möglich, aber riskant.
Digital Fingerprinting
Metas Engineering-Beitrag sagt, unautorisierte Scraper würden „commonly hide themselves by mimicking the ways users would normally use a product“ — ein indirekter Hinweis darauf, dass Browser-Qualität und Verhaltensqualität zentrale Erkennungsfaktoren sind. Community-Diskussionen im März und April 2026 empfehlen weiterhin Anti-Detect-Browser und konsistente Fingerprints.
Was kaputtgeht: Standard-Setups mit Selenium oder Puppeteer sind leicht zu erkennen.
Gegenmaßnahme: Tools wie undetected-chromedriver oder Anti-Detect-Browser-Profile verwenden. Realistische Sessions und konsistente Fingerprints sind wichtiger als bloßes User-Agent-Spoofing.
IP-basiertes Rate-Limiting und Blocking
Der Engineering-Beitrag von Meta spricht ausdrücklich über Rate Limiting als Teil der Verteidigungsstrategie, einschließlich der Begrenzung von Follower-Listen, um mehr Requests zu erzwingen, die dann Rate-Kontrollen auslösen. In der Praxis berichten Nutzer, dass sie bereits nach Posts in 10 Gruppen im 10-Sekunden-Takt gedrosselt werden.
Was kaputtgeht: Massenanfragen von derselben IP werden innerhalb weniger Minuten gebremst oder blockiert. Datacenter-Proxys sind oft bereits vorgeblockt.
Gegenmaßnahme: Residential-Proxy-Rotation statt Datacenter-Proxys, dazu ein vernünftiges Anfrage-Tempo.
Änderungen am GraphQL-Schema
Manche Scraper verlassen sich auf Facebooks interne GraphQL-Endpunkte, weil diese sauberer strukturierte Daten liefern als rohes HTML. Meta gibt für interne GraphQL-Abfragen jedoch keine Stabilitätsgarantie, daher brechen diese Queries oft stillschweigend — sie liefern leere Daten statt Fehlermeldungen.
Was kaputtgeht: Strukturierte Extraktion gibt einfach nichts zurück.
Gegenmaßnahme: Validierungsprüfungen ergänzen, Schema-Endpunkte überwachen und auf bekannte funktionierende Queries pinnen. Wartung einkalkulieren.
Zusammenfassung der Anti-Scraping-Abwehr
| Abwehrschicht | Wie sie Ihren Scraper bricht | Praktische Gegenmaßnahme |
|---|---|---|
| Layout-Wechsel / instabile Selektoren | XPath- und CSS-Selektoren liefern nichts oder nur Teilfelder | Robuste Anker bevorzugen, gegen sichtbare Seitenausgabe validieren, Wartung einplanen |
| Login-Walls | Ausgeloggte Requests verpassen Inhalte oder werden umgeleitet | Gültige Session-Cookies oder Browser-Session-Tools verwenden |
| Fingerprinting | Standard-Automation wirkt künstlich | Echte Browser, konsistente Session-Qualität, Anti-Detect-Maßnahmen nutzen |
| Rate Limiting | Leere Ausgaben, Blocks, Drosselung | Langsameres Tempo, kleinere Batches, Residential-Proxy-Rotation |
| Interne Query-Änderungen | Strukturierte Extraktion liefert stillschweigend leere Daten | Validierungschecks ergänzen, Query-Pflege einplanen |
Wenn GitHub-Repositories scheitern: Wählen Sie eine zulässige Alternative
Ein defektes Repository ist kein Grund, Plattformkontrollen einfach zu umgehen. Klären Sie zuerst die geschäftliche Frage: Brauchen Sie Analysen auf Seitenebene, Werbe-Transparenz, ein öffentliches Kontaktverzeichnis oder einen Produktkatalog? Viele dieser Anforderungen lassen sich mit einem offiziellen Meta-Produkt, einer berechtigten API oder einer öffentlichen Quelle außerhalb von Meta abdecken.
Nutzen Sie die Graph API nur dann, wenn App und Anwendungsfall die erforderlichen Berechtigungen haben. Verwenden Sie Metas Forschungsprogramme nur, wenn Sie dafür zugelassen sind, und greifen Sie für Werbeinformationen auf die Meta Ad Library zurück. Für Lead-Recherche, Preisbeobachtung und lokale Unternehmenssuche sind unabhängige öffentliche Websites oft die bessere Wahl, deren Bedingungen und Datenschutzpflichten sich direkt bewerten lassen.
Echte Ausgabe-Beispiele: Was Sie tatsächlich bekommen
Alle Konkurrenzartikel zeigen Code-Snippets, aber nie die echte Ausgabe. Unten sehen Sie, was Sie von den jeweiligen Ansätzen realistisch erwarten können.
Beispielausgabe: kevinzg/facebook-scraper (oder aktiver Fork)
Aus dem README-Beispiel kommt ein gescrapter öffentlicher Post als JSON zurück, etwa so:
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Don't let this diminutive version...",
"text": "Don't let this diminutive version...",
"time": "2019-04-30T05:00:01"
}
Beachten Sie die nullable Felder wie comments_full. Im Jahr 2026 sollten Sie eher damit rechnen, dass mehr Felder leer oder fehlend zurückkommen — das ist meist ein Blockierungs-Signal und kein harmloser Zufall. Die Ausgabe ist rohes JSON und muss weiterverarbeitet werden.
Beispielausgabe: Facebook Graph API
Metas aktuelle Pages API dokumentiert Anfragen wie GET /<PAGE_ID>?fields=id,name,about,fan_count. Die Page-Referenz enthält Felder wie followers_count, fan_count, category, emails, phone und weitere öffentliche Metadaten — allerdings nur mit den passenden Berechtigungen wie Page Public Content Access oder Page Public Metadata Access.
Das ist ein deutlich engeres Datenbild, als die meisten GitHub-Scraper-Nutzer erwarten. Es ist seitenzentriert, an Berechtigungen gebunden und kein Ersatz für beliebiges Scraping von öffentlichen Posts oder Gruppen.
Matrix für Facebook-Datentypen × Zugriffsweg
| Facebook-Datentyp | Besserer Startpunkt | Zentrale Einschränkung |
|---|---|---|
| Von Ihrer Organisation verwaltete Assets | Offizielle Meta-Management-Tools und freigegebene APIs | Berechtigungen und verfügbare Felder variieren |
| Beobachtungen zu Werbung | Meta Ad Library | Nur die dort angebotenen Felder und Filter verwenden |
| Öffentliche Unternehmensdaten für Lead-Recherche | Eine zulässige Nicht-Meta-Datenquelle oder eine Publisher-Website | Bedingungen und Datenschutzpflichten der Quelle prüfen |
| Private, geschlossene, login-geschützte oder accountgebundene Inhalte | Nicht automatisiert erfassen | Stattdessen einen autorisierten Weg suchen |
Schritt für Schritt: So richten Sie einen Facebook Scraper von GitHub ein, wenn es sinnvoll ist
Wenn Sie den Freshness-Check gelesen haben und trotzdem den GitHub-Weg gehen wollen, fair enough. Hier ist der praktische Ablauf — inklusive ehrlicher Hinweise darauf, wo es scheitert.
Schritt 1: Das richtige Repo wählen (Freshness-Analyse nutzen)
Gehen Sie zurück zur Audit-Tabelle. Wählen Sie das am wenigsten veraltete Repo, das zu Ihrer Zieloberfläche passt. Bevor Sie etwas installieren, prüfen Sie den Issues-Tab — aktuelle Issue-Titel verraten mehr über die heutige Funktionsfähigkeit als das README.
Schritt 2: Ihre Python-Umgebung einrichten
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Typische Stolperfalle: Versionskonflikte bei Abhängigkeiten, besonders bei Selenium- oder Playwright-Versionen. Sowohl kevinzg als auch moda20 geben in ihren pyproject.toml-Dateien Python ^3.6 an — eine ältere Basis, die mit neueren Libraries kollidieren kann. Der Marketplace-Scraper von passivebot pinnt playwright==1.40.0, was für Experimente okay ist, aber nichts über die Haltbarkeit aussagt.
Schritt 3: Proxys und Anti-Detection konfigurieren
Wenn Sie mehr als nur einen kurzen Test machen:
- Residential-Proxy-Rotation einrichten (Anbieter mit Facebook-spezifischen IP-Pools suchen)
- Bei Browser-Automation undetected-chromedriver installieren oder Anti-Fingerprinting konfigurieren
- Diesen Schritt nicht überspringen — Standard-Selenium oder Puppeteer wird schnell erkannt
Schritt 4: Einen kleinen Testlauf starten und die Ausgabe prüfen
Beginnen Sie mit einer einzelnen öffentlichen Seite, nicht mit einem großen Batch. Prüfen Sie die Ausgabe sorgfältig:
- Leere Felder oder fehlende Daten bedeuten meist, dass Facebooks Schutzmechanismen eingreifen
- Vergleichen Sie die Ausgabe mit dem, was Sie im Browser tatsächlich sehen
- Ein erfolgreicher Test mit einer Seite ist wichtiger als ein schickes README
Schritt 5: Fehler, Rate Limits und Wartung behandeln
- Bauen Sie Retry-Logik und Fehlerbehandlung ein
- Rechnen Sie damit, Selektoren oder Konfigurationen regelmäßig anzupassen — das ist fortlaufende Wartung, kein „einmal einrichten und vergessen“
- Wenn Sie mehr Zeit mit der Pflege des Scrapers verbringen als mit der Nutzung der Daten, ist das ein Zeichen, den No-Code-Weg neu zu bewerten
Rechtliche und ethische Überlegungen beim Facebook-Scraping
Plattformbedingungen, Datenschutzregeln, vertragliche Pflichten und Datenschutzgesetze können alle relevant sein. Öffentliche Sichtbarkeit ist keine pauschale Erlaubnis zur automatisierten Erfassung. Halten Sie Daten sparsam, dokumentieren Sie Zweck und Rechtsgrundlage und holen Sie bei kommerziellen oder groß angelegten Programmen rechtlichen Rat ein.
Betrachten Sie eine Browser-Erweiterung, eine eingeloggte Session oder die Kennzeichnung „öffentlich“ nicht als Erlaubnis, Inhalte aus Meta-Produkten automatisiert zu erfassen.
Zentrale Erkenntnisse: Was 2026 beim Facebook-Scraping tatsächlich funktioniert
Repo-Aktivität, Issue-Queues und aktuelle Plattformregeln sind wichtiger als Sternzahlen oder alte Readmes. Wenn sich die Geschäftsfrage auf ein Asset bezieht, das Sie selbst verwalten, sollten Sie mit offiziellen Meta-Tools und freigegebenen APIs starten. Für Marktanalysen, Lead-Recherche und Preisfragen ist eine zulässige Nicht-Meta-Quelle oft einfacher zu dokumentieren und zu steuern.
FAQs
Gibt es 2026 einen funktionierenden Facebook Scraper auf GitHub?
Ja, aber die Auswahl ist begrenzt. Am bekanntesten ist der Fork moda20/facebook-scraper des ursprünglichen kevinzg-Repos — prüfen Sie die Freshness-Tabelle oben für den aktuellen Stand. Er kann öffentliche Seitenposts und einige Metadaten teilweise auslesen, aber die Issue-Queue zeigt grundlegende Probleme mit mbasic und leeren Ausgaben. Die meisten anderen Repos sind aufgegeben oder vollständig defekt.
Kann ich Facebook ohne Programmierung scrapen?
Nutzen Sie Facebooks eigene Such- und Verwaltungstools für manuelle Recherchen. Für wiederholbare oder programmatische Aufgaben prüfen Sie die offizielle API und ihre Berechtigungen oder gestalten Sie den Workflow um eine zulässige Nicht-Meta-Quelle neu. No-Code-Komfort hebt Plattform-, Datenschutz- oder Vertragsauflagen nicht auf.
Ist es legal, Facebook zu scrapen?
Die Nutzungsbedingungen von Facebook verbieten automatisierte Datenerfassung ohne Erlaubnis. Meta setzt dies aktiv durch, unter anderem mit Account-Sperren, Unterlassungsschreiben und Klagen. Die Rechtslage hängt von Jurisdiktion und Anwendungsfall ab. Beschränken Sie sich auf öffentlich verfügbare Unternehmensdaten, vermeiden Sie personenbezogene Profile und holen Sie bei großem Umfang juristischen Rat ein.
Welche Daten kann ich über die Facebook Graph API noch bekommen?
Im Jahr 2026 ist die Graph API stark eingeschränkt. Mit passenden Berechtigungen wie Page Public Metadata Access können Sie begrenzte Daten auf Seitenebene abrufen — Felder wie id, name, about, fan_count, emails, phone. Die meisten öffentlichen Post-Daten, Gruppendaten (die Groups API ist veraltet) und Nutzerdaten sind über die API nicht mehr verfügbar.
Wie oft brechen Facebook-Scraper-Repos auf GitHub?
Sehr häufig. Facebook ändert fortlaufend DOM-Struktur, Anti-Bot-Maßnahmen und interne APIs — es gibt keinen veröffentlichten Takt, aber Community-Berichte zeigen bei aktiven Scrapern alle paar Wochen Probleme. Die Issue-Queue des moda20-Forks rund um das Verschwinden von mbasic ist ein aktuelles Beispiel. Wenn Sie auf ein GitHub-Repo setzen, sollten Sie regelmäßige Wartung und eine Validierung der Ausgabe einkalkulieren.
Mehr erfahren
