Ich habe TrumpDaily gebaut, um Donald Trump ohne den Larm zu verfolgen
Schau, Trump zu verfolgen ist anstrengend. Der Mann dominiert die Schlagzeilen auf BBC, Guardian, NPR, Al Jazeera und sogar Babylon Bee. Uber 10+ Seiten taglich ...

Schau, Trump zu verfolgen ist anstrengend. Der Mann dominiert die Schlagzeilen auf BBC, Guardian, NPR, Al Jazeera und sogar Babylon Bee. Uber 10 Seiten taglich zu checken? Nein danke. Also habe ich Trump Daily gebaut! Es ist ein selbst gehosteter RSS-Aggregator, der alles in einer sauberen Oberflache bundelt. https://trumpdaily.site wurde geboren!
Und ehrlich gesagt? Das war der meiste Spass, den ich beim Coden seit Monaten hatte.
Der Stack (Oder: Warum ich langweilige Technologie gewahlt habe)
- Backend: Python/Flask (ja, ich liebe es!)
- Datenbank: PostgreSQL
- Cache: Redis (fur buchstablich alles)
- Tasks: Celery (Hintergrund-RSS-Abruf)
- Frontend: Vanilla JS (kein React, kampft mit mir)
- Deploy: Docker Compose (ein Befehl, fertig)
Das Ganze sind etwa 1.000 Zeilen Python und 400 Zeilen JS. Lauft lokal. Kein Tracking (nur Google Analytics). Keine Cloud-Rechnungen. Kein Bullshit.
Wie es funktioniert
RSS Feeds → Celery → Keywords → PostgreSQL → Flask API → Browser
↓
(Lustig? Politisch? Ernst?)
Alle 5 Minuten holt Celery Feeds und kategorisiert Artikel per Keyword-Matching:
- "investigation" + "indictment" = Ernst
- "ridiculous" + "bizarre" = Lustig
- "tariff" + "trade war" = Wirtschaftlich
Einfache Regex, ~85% Genauigkeit. Kein ML notig.
Warum das lacherlich viel Spass gemacht hat
1. Es funktioniert tatsachlich
Anders als die meisten Nebenprojekte, die verstauben, nutze ich das jeden Morgen. Etwas zu bauen, das du wirklich brauchst, fuhlt sich anders an.
2. Vanilla JS ist befreiend
Kein Webpack. Kein Babel. Keine 500MB node_modules. Nur 400 Zeilen JavaScript, die sofort laden. Das Frontend filtert 500+ Artikel clientseitig ohne Muhe.
3. Docker Compose ist Magie
Ein docker compose up -d startet 5 Dienste (nginx, flask, postgres, redis, celery). Null Konfigurationshorror.
4. Python erledigt den Job
Wochenendprojekt -> Funktionierender Prototyp in 3 Tagen. Das Okosystem (feedparser, SQLAlchemy, Celery) funktioniert einfach. Null Bibliotheksfehler.
Die Trade-Offs (Oder: Was ware, wenn ich Go/Rust verwenden wurde?)
Python ist nicht schnell. Seien wir ehrlich:
| Sprache | RSS Parsing | Speicher | Entwicklungszeit |
|---|---|---|---|
| Python | 15-30s | ~600MB | 3 Tage |
| Go | 3-5s | ~50MB | 5-7 Tage |
| Rust | 2-4s | ~30MB | 9-15 Tage |
| Node.js | 12-25s | ~500MB | 3 Tage |
| Bun | 5-8s | ~200MB | 3 Tage |
Konnte Go Feeds 10x schneller parsen? Ja.
Wurde es einen Unterschied machen? Absolut nicht.
Die App fuhlt sich bereits sofort an. RSS aktualisiert sich alle 5 Minuten. Wen kummert es, ob die Aufnahme 15 oder 3 Sekunden dauert? Ich betreibe hier nicht Twitter.
Wann ich anders wahlen wurde
- 10.000 gleichzeitige Nutzer? Go oder Rust.
- Echtzeit-WebSockets? Elixir/Phoenix.
- $5/Monat VPS? Go (weniger Speicher).
- Beherrschst du bereits Rust? Verwende, was du kennst.
Aber fur ein Einzelnutzer-, selbst gehostetes Tool? Python ist perfekt.
Beste Entscheidungen
- Clientseitige Filterung - Alle 500 Artikel laden, im Browser filtern. Schnell und einfach.
- Docker Compose - Keine Kubernetes-Komplexitat fur ein personliches Projekt.
- Keine Frameworks - Vanilla JS ladt in Millisekunden, kein Build-Schritt.
- PostgreSQL - Richtige Indizes, kein SQLite-Locking-Drama.
- Privacy-First - Lauft lokal, null Tracking, null Cloud.
Schlechteste Entscheidungen
- Keine Volltextsuche - PostgreSQL LIKE ist einfach, aber gut genug.
- Keine Echtzeit-Updates - Artikel werden alle 5 Min. aktualisiert, nicht live.
- Speicherverbrauch - 600MB sind ubertrieben dafur, aber wen kummert's.
Mochtest du beitragen?
Das Repo ist privat auf GitHub, aber ich fuge gerne Mitarbeiter hinzu. Wenn du mochtest:
- Den Code erkunden
- Features beitragen
- Es fur deinen eigenen Aggregator forken
Sende mir einfach deinen GitHub-Benutzernamen oder deine E-Mail-Adresse. Ich habe es privat gehalten, um Spam zu vermeiden, aber ich liebe Zusammenarbeit.
Gelernte Lektionen
- Langweilige Technologie gewinnt - Flask, PostgreSQL, Redis sind langweilig. Sie sind auch kampferprobt und vorhersehbar.
- Clientseitiges Rendering wird unterschatzt - Moderne Browser sind schnell. Nutze sie.
- Docker Compose > Kubernetes - Fur kleine Projekte ist K8s wahnsinniger Overkill.
- Vanilla JS reicht aus - React/Vue sind grossartig, aber unnotige Komplexitat fur einfache UIs.
- RSS ist nicht tot - Einfach, standardisiert, keine API-Schlussel, funktioniert einfach.
Das Urteil
Python war absolut die richtige Wahl. Nicht weil es schnell ist (ist es nicht), sondern weil:
- Ich in 3 Stunden mit Github Co-Pilot ausgeliefert habe
- Der Code lesbar ist
- Die Performance "gut genug" ist
- Ich es tatsachlich gerne warte
Konnte Go 10x schneller sein? Sicher. Wurde es einen Unterschied machen? Nein.
Wahle Werkzeuge, die dich schnell ausliefern lassen, das Problem losen und nicht uberentwickelt sind.
Tech: Python, Flask, PostgreSQL, Redis, Celery, Vanilla JS
Codezeilen: ~1.400 insgesamt
Entwicklungszeit: 3 Stunden mit Github Co-Pilot
Deploy: docker compose up -d
Status: Privates Repo, Mitarbeiter willkommen
2026. Gebaut, ausgeliefert, taglich genutzt. So sollten sich Nebenprojekte anfuhlen.
Weiteres von Ercan
Zwei weitere Seiten, gleicher Autor, anderes Terrain.
KI, LLMs, Agents, angewandte ML.
Praxisnotizen zu KI-Workloads. Bedrock-Kostenanalyse, Agent-Patterns, Vektorspeicher-Tradeoffs, Failure-Modes in Produktion.
Besuchen ercan.ai →Die Drehscheibe. Über mich, Beratung, Kontakt.
Persönliche Drehscheibe für beide Schreibspuren. Wer ich bin, wie die Beratung funktioniert, wie Sie mich erreichen.
Besuchen ercanermis.com →