Querchecker entstand aus einem konkreten Bedarf: die Suche nach einem gebrauchten Drucker auf dem Willhaben Marktplatz (Kleinanzeigen). Welche Modelle haben noch verfügbare Patronen? Gibt es Ersatzteile? Hat er Duplex? Diese Fragen sind auf Willhaben selbst mühsam zu beantworten — man jongliert zwischen Inseraten, Geizhals und Herstellerseiten, verliert spätestens ab dem zweiten Inserat den Überblick und fängt von vorne an.
Querchecker bündelt diesen Workflow in einer einzigen, fokussierten Oberfläche. Gleichzeitig ist es ein Showcase dafür, wie sich moderne KI-Funktionen sinnvoll in eine reale Alltagsanwendung integrieren lassen — nicht als Gimmick, sondern als echter Mehrwert.
Mir war dabei wichtig:
- Durchdachtes UI-Design — klare Struktur, konsistentes Material Design v3 Theme (TealMist), angenehme Interaktion
- Aktueller, sauberer Stack — Angular 21+, Spring Boot 3.5, @ngrx/signals, keine veralteten Patterns
- AI sinnvoll eingesetzt — automatische Produkterkennung, Spezifikations-Lookup, strukturierte Datenextraktion
- Robustheit — Edge Cases wie API-Ausfälle, Kontingent-Limits oder ungültige LLM-Responses werden explizit behandelt; kritische Komponenten sind unit-getestet
- Durchgehender Workflow — Suche, Bewertung und KI-Recherche greifen ineinander und ergeben eine tatsächlich nutzbare Anwendung, keine Feature-Demo
Der Workflow ist bewusst linear gehalten: Du startest eine Suche, bekommst deine Ergebnisse als Karten, und klickst dich in die Detailansicht — ohne dass die Seite neu lädt. Die drei Zustände (Suche, Ergebnisse, Detail) wechseln fließend ineinander, du verlierst nie den Kontext.
In der Detailansicht siehst du alle Bilder des Inserats in einer Galerie, kannst das Inserat bewerten (👍/👎), Notizen hinzufügen (werden automatisch gespeichert) und direkt in die KI-gestützte Produktanalyse wechseln. Dort schlägt Querchecker automatisch einen Produktnamen vor — du kannst ihn korrigieren, und auf Knopfdruck werden technische Spezifikationen nachgeschlagen: aus Quellen wie Icecat, GSMArena oder FlatpanelsHD, aufbereitet von einem LLM zu strukturierten Quick Facts. Felder, die dir wichtig sind (z.B. Duplex-Druck, Akkukapazität), kannst du als bevorzugt markieren — sie erscheinen dann immer ganz oben.
Was du nicht siehst: wie viele API-Aufrufe das im Hintergrund kostet. Querchecker arbeitet mit freien API-Kontingenten (Groq, Brave Search) und trackt die Nutzung intern — in den Einstellungen gibt es einen Usage Monitor, der dir zeigt wie weit du noch von deinem Tageslimit entfernt bist.
Damit du nicht den Überblick verlierst, kannst du deine Suche im Querchecker sehr präzise steuern. Der Filter-Bereich ist in drei logische Schritte unterteilt:
| Schicht | Technologie |
|---|---|
| Frontend | Angular 21+, Angular Material v3, @ngrx/signals SignalStore |
| Backend | Spring Boot 3.5, Java 21, Lombok, SpotBugs |
| Datenbank | PostgreSQL 16 |
| KI / LLM | OpenRouter / Groq (OpenAI-kompatibel) oder lokal via llama.cpp |
| Websuche | Brave Search API |
| Prod | Docker, nginx, Traefik (SSL via Let's Encrypt) |
| Version | 0.2.0 |
|
Voraussetzungen Docker · Java 21 · Node.js 20+ # PostgreSQL starten
docker compose up -d
# Backend
cd backend && mvn spring-boot:run
# Frontend
cd frontend && npm install && npm start
# Nach Backend-API-Änderungen
cd frontend && npm run generate-api |
Ports (lokal)
|
Querchecker funktioniert auch ohne konfigurierte API-Keys (nur Willhaben-Suche). Für Web Search (Brave) und Textanalyse-Engine (Groq/OpenRouter) brauchst du externe Provider.
Siehst du beim ersten Start diese Nachricht, fehlt einer der Provider:
Weitere Details → Developer Setup
Hot Reload: Datei speichern → Spring DevTools erkennt die Änderung und startet den Context automatisch neu. JVM-Neustart nur bei Prozess-Crash nötig.
docker compose -f docker-compose.prod.yml up -dTraefik-Labels in docker-compose.prod.yml anpassen (Domain, certresolver).
querchecker/
├── backend/ ← Spring Boot (Maven)
├── frontend/ ← Angular 21+
├── docs/
│ ├── screenshots/ ← Screenshots für README
│ ├── concepts/ ← Design-Konzepte (Provider-Konfiguration, …)
│ └── *.md ← Technische Dokumentation
├── docker-compose.yml ← Dev: nur PostgreSQL
├── docker-compose.prod.yml ← Prod: nginx + backend + postgres
└── README.md
| 📐 Technisch & Design | ⚙️ Setup & Betrieb |
|---|---|
| 🏗️ Architecture & Design Decisions SignalStore, SSE, conditional model registration, OpenAPI workflow |
📖 Admin Guide Installation, Konfiguration und Betrieb (API-Keys, Provider-Setup, Deployment) |
| 🛡️ Robustness & Error Handling API-Ausfälle, Rate-Limiting, Quota-Verwaltung, Server-Restarts |
⚙️ Provider-Konfiguration KI-Modelle und Web-Suche konfigurieren (lokal vs. Cloud) |
| 🤖 KI-Produktanalyse Produktname-Extraktion und Item Research |
💻 Lokale Modelle LLM lokal statt Cloud betreiben |
| ⚙️ Extraction Engine Queue-Architektur, Status-Maschine, Modell-Registrierung |
🛠️ Developer Setup Ersteinrichtung, API-Keys, Troubleshooting |
- Mobile-optimiertes Layout
- Lokales Modell als Fallback — wenn die Remote-LLM-API nicht erreichbar ist, automatisch auf das lokal verfügbare Modell ausweichen (nahtlose Redundanz)
- Ähnliche Inserate — nach erkanntem Produktnamen wird in den aktuellen Suchergebnissen nach weiteren Inseraten des gleichen Produkts gesucht und direkt in der Detailansicht angezeigt. Kein zusätzlicher API-Aufruf — rein clientseitig über die bereits geladenen Listings.
- Provider-Wechsel zur Laufzeit — Web-Such-Provider (Brave / Google Discovery) ohne App-Neustart umschalten.
Bei positivem Feedback bin ich offen für weitere Features, sofern sie mich fachlich reizen und der Aufwand vertretbar ist.






