Eine Sammlung wird erst nützlich, wenn ihre Daten belastbar sind.

Systemansichten

Case Study

1. 01

   Ausgangslage

   Sammelkarten werden schnell unübersichtlich: Katalogdaten, Varianten, Sprache, Zustand, Besitz, Wunschlisten und Preise liegen verstreut. Eine Sammlung braucht ein Modell, das diese Unterschiede als Fachdaten behandelt und nicht als Freitext.

2. 02

   Aufgabe und eigene Rolle

   Produktkonzeption, Systemarchitektur und Entwicklung einer privaten, API-first Plattform, vom Domänenmodell über das Sicherheitskonzept bis zu Web-Oberfläche, Synchronisation und Scanner.

   • Fachmodell für Karten, Sets, Varianten und Besitzpositionen
   • Katalog, private Sammlung und Preisverlauf in getrennten Schichten
   • Lokaler OCR-Scanner für die schnelle Erfassung

3. 03

   Wichtigste Entscheidungen

   Öffentliche Referenzdaten und private Sammlungsdaten sind strikt getrennt. Preise bleiben nach Zeit und Herkunft getrennt, und eine fehlende Bewertung zählt nicht als Preis von null. So bleiben die Daten nachvollziehbar, auch wenn sich Kataloge oder Anbieter ändern.

4. 04

   System und Datenflüsse

   Ein React-Client spricht über eine versionierte REST-API mit einem modularen Monolithen. PostgreSQL hält Katalog-, Sammlungs- und Preisdaten getrennt, ein Worker übernimmt Synchronisation und Preisaktualisierung. Der Scanner verarbeitet das Kamerabild lokal und sendet nur den erkannten Text an die Katalogsuche.

5. 05

   Technologien und Lösungen

   Der Aufbau im Einzelnen:

   • Web-App: React und Vite als PWA, Datenabruf mit React Query. Die Oberfläche greift nie direkt auf die Datenbank zu, sondern nur auf die API.
   • API: Fastify mit Zod-Validierung, JWT-Authentifizierung und Rate-Limit. Jede private Abfrage ist auf den Eigentümer der Sammlung beschränkt, Passwörter sind mit scrypt und eigenem Salt gehasht.
   • Gemeinsames Domänenpaket: Berechnung von Vollständigkeit, Dubletten und Bewertung liegt in einem geteilten TypeScript-Paket, das Frontend und Backend nutzen.
   • Katalog-Synchronisation: Ein Provider-Adapter (zunächst TCGdex) liest externe Karten- und Setdaten. Die Synchronisation ist idempotent und fasst private Daten nie an.
   • Scanner: Die Kamera läuft über getUserMedia, ein Canvas schneidet den unteren Kartenbereich zu, Tesseract.js (WebAssembly) liest nur Ziffern und Schrägstrich, etwa „125/197“. Die API liefert bis zu acht passende Karten, und die Aufnahme erfolgt erst nach Bestätigung durch den Nutzer.
   • Betrieb: Docker-Compose für Datenbank, Migrationen, API und Auslieferung.

6. 06

   Qualität, Sicherheit und Betrieb

   Eingaben werden validiert, Anfragen sind begrenzt, und private Daten werden von Katalog-Synchronisationen nie überschrieben. Es gibt keinen Bildupload: Kamerabild und Ausschnitt bleiben im Arbeitsspeicher des Browsers.

7. 07

   Grenzen und nächster Ausbau

   Cardfolio ist ein persönliches Sammlungswerkzeug, und Marktpreise sind unverbindliche Anhaltspunkte. Der Funktionsumfang wächst nach meinem eigenen Bedarf, statt eine Plattform für jede denkbare Sammlung zu versprechen.