Crypto Edge Engine ist ein leichtgewichtiges, skalierbares Backend-Framework für algorithmischen Krypto-Handel. Der Fokus liegt auf modularer FastAPI-Architektur, umgebungsgetriebenen Settings, optionaler Supabase-Persistenz und schnellem Cloud-Deployment.
1. Projekt-Überblick
Crypto Edge Engine ist ein leichtgewichtiges, auf FastAPI basierendes Backend-Framework, das als Ausgangspunkt für die Entwicklung einer vollautomatisierten Krypto-Handelsplattform dient.
Der Fokus liegt auf Modularität, Umgebungs-Konfiguration und einem optionalen Supabase-Persistenz-Layer, sodass das System sowohl lokal als auch in der Cloud, zum Beispiel auf Railway, betrieben werden kann.
2. Kern-Features
Feature
FastAPI-Entry-Point
Beschreibung
Lifespan-Manager startet Scheduler und Runtime-Setup beim App-Start.
Relevante Datei
app/main.py
Feature
Umgebungsgetriebene Settings
Beschreibung
API-Prefix, CORS, Symbol-Liste, Risiko-Limits, Supabase-Keys und AI-Parameter werden aus der .env geladen und gecacht.
Relevante Datei
app/core/settings.py
Feature
Modulare API-Router
Beschreibung
18 spezialisierte Sub-Router werden in einer zentralen api_router-Instanz zusammengeführt.
Relevante Datei
app/api/router.py
Feature
Supabase-Integration (optional)
Beschreibung
Beim Start wird eine Supabase-Verbindung versucht, ansonsten greift das System auf ein In-Memory-Repository zurück.
Relevante Datei
supabase/
Feature
Job-Scheduler
Beschreibung
Hintergrund-Jobs für Daten-Crawling, Risiko-Checks und weitere Runtime-Aufgaben werden zentral verwaltet.
Relevante Datei
app/jobs/scheduler.py
Feature
Deploy- und Entwicklungs-Werkzeuge
Beschreibung
Dockerfile, Procfile und pyproject.toml ermöglichen lokale Entwicklung, Container-Deploy und Cloud-Hosting.
Relevante Datei
Dockerfile, Procfile, pyproject.toml
Feature
Test-Coverage
Beschreibung
Grundlegende Unit-Tests sichern Settings-Loading und Health-Endpoint ab.
Relevante Datei
tests/
| Feature | Beschreibung | Relevante Datei |
|---|---|---|
| FastAPI-Entry-Point | Lifespan-Manager startet Scheduler und Runtime-Setup beim App-Start. | app/main.py |
| Umgebungsgetriebene Settings | API-Prefix, CORS, Symbol-Liste, Risiko-Limits, Supabase-Keys und AI-Parameter werden aus der .env geladen und gecacht. | app/core/settings.py |
| Modulare API-Router | 18 spezialisierte Sub-Router werden in einer zentralen api_router-Instanz zusammengeführt. | app/api/router.py |
| Supabase-Integration (optional) | Beim Start wird eine Supabase-Verbindung versucht, ansonsten greift das System auf ein In-Memory-Repository zurück. | supabase/ |
| Job-Scheduler | Hintergrund-Jobs für Daten-Crawling, Risiko-Checks und weitere Runtime-Aufgaben werden zentral verwaltet. | app/jobs/scheduler.py |
| Deploy- und Entwicklungs-Werkzeuge | Dockerfile, Procfile und pyproject.toml ermöglichen lokale Entwicklung, Container-Deploy und Cloud-Hosting. | Dockerfile, Procfile, pyproject.toml |
| Test-Coverage | Grundlegende Unit-Tests sichern Settings-Loading und Health-Endpoint ab. | tests/ |
3. Technologischer Stack
Ebene
Backend
Technologie
Python 3.12, FastAPI, Pydantic, Uvicorn
Ebene
Persistenz
Technologie
Supabase (PostgreSQL + Realtime), optional In-Memory
Ebene
Scheduling
Technologie
APScheduler-basiert innerhalb von app/jobs/
Ebene
Entwicklung
Technologie
Poetry / uv, Docker, Railway
Ebene
Testing
Technologie
Pytest, HTTPX
Ebene
CI/CD
Technologie
GitHub-Actions-fähige Struktur mit Railway-Deploy-Fokus
| Ebene | Technologie |
|---|---|
| Backend | Python 3.12, FastAPI, Pydantic, Uvicorn |
| Persistenz | Supabase (PostgreSQL + Realtime), optional In-Memory |
| Scheduling | APScheduler-basiert innerhalb von app/jobs/ |
| Entwicklung | Poetry / uv, Docker, Railway |
| Testing | Pytest, HTTPX |
| CI/CD | GitHub-Actions-fähige Struktur mit Railway-Deploy-Fokus |
4. Architekturelle Entscheidungen
- Lebenszyklus-Management: Der lifespan-Context-Manager stellt sicher, dass Hintergrund-Jobs nur laufen, solange die Anwendung aktiv ist.
- Dependency Injection via Settings: Services wie Supabase-Client, Scheduler oder AI-Keys werden aus
get_settings()bezogen, was lokales Testen und Umgebungswechsel vereinfacht. - Plug-and-Play Router-Architektur: Neue Geschäftslogik kann über ein eigenes
routes_*.py-Modul und eine zusätzliche Referenz inrouter.pyintegriert werden. - Supabase als optionaler Layer: Fehlen
SUPABASE_URLoderSUPABASE_KEY, läuft das System stabil im In-Memory-Modus weiter.
5. Herausforderungen & Lösungen
Herausforderung
Umgebungsvariablen-Parsing
Lösung
Ein generischer CSV-Parser wandelt komma-separierte Strings zuverlässig in Python-Listen um und eignet sich für lokale .env-Dateien sowie Cloud-Secrets.
Herausforderung
Saubere Shutdown-Sequenz
Lösung
Der Scheduler wird im
lifespan-finally-Block gestoppt, wodurch hängende Threads vermieden werden.Herausforderung
Modulare Expansion ohne Tight Coupling
Lösung
Jeder Sub-Router bleibt ein eigenständiges FastAPI-
APIRouter-Objekt; das Haupt-Router-File enthält nur die Referenzliste.Herausforderung
Testing ohne Supabase-Instanz
Lösung
Die In-Memory-Repository-Implementierung ermöglicht Unit-Tests ohne externe Datenbank.
| Herausforderung | Lösung |
|---|---|
| Umgebungsvariablen-Parsing | Ein generischer CSV-Parser wandelt komma-separierte Strings zuverlässig in Python-Listen um und eignet sich für lokale .env-Dateien sowie Cloud-Secrets. |
| Saubere Shutdown-Sequenz | Der Scheduler wird im lifespan-finally-Block gestoppt, wodurch hängende Threads vermieden werden. |
| Modulare Expansion ohne Tight Coupling | Jeder Sub-Router bleibt ein eigenständiges FastAPI-APIRouter-Objekt; das Haupt-Router-File enthält nur die Referenzliste. |
| Testing ohne Supabase-Instanz | Die In-Memory-Repository-Implementierung ermöglicht Unit-Tests ohne externe Datenbank. |
6. Ergebnisse & Mehrwert
- Schneller Prototyp-Start: Nach der Entwicklungsinstallation steht in wenigen Minuten ein funktionsfähiger API-Server bereit.
- Klare Trennung von Geschäftslogik und Infrastruktur: Handelsalgorithmen können unabhängig von Boilerplate und Runtime-Setup entwickelt werden.
- Hohe Portabilität: Durch Docker- und Railway-Support lässt sich das Projekt schnell lokal und in der Cloud betreiben.
- Skalierbarkeit: Das optionale Supabase-Backend eröffnet sofortige Erweiterungsmöglichkeiten für Realtime-Updates, Persistenz und Security-Layer.
Projektfazit
“Crypto Edge Engine schafft eine belastbare technische Basis für Forschung, Prototyping und den schrittweisen Ausbau einer vollautomatisierten Krypto-Handelsplattform.”
Sie planen ein FinTech- oder Trading-System?
Wir entwickeln robuste Backends, Dashboards, Datenpipelines und skalierbare Plattform-Architekturen für anspruchsvolle digitale Produkte.
Projekt besprechenPassende nächste Schritte
Vertiefen Sie das Thema mit den wichtigsten Service- und Projektseiten.
Interner Link
Portfolio ansehen
Weitere Plattform-, KI- und Systemprojekte im Überblick.
Interner Link
KI- & Automatisierung in Köln
Mehr über unsere Arbeit an intelligenten Systemen und Geschäftsautomatisierung.
Interner Link
Projektberatung anfragen
Direkt über Ihr Backend-, Plattform- oder FinTech-Projekt sprechen.
Häufig gestellte Fragen (FAQ)
Wofür eignet sich Crypto Edge Engine besonders?
Das System eignet sich als technisches Ausgangsgerüst für algorithmischen Krypto-Handel, Research-Workflows, Signal-Services, Backtests und operatororientierte Trading-Dashboards.
Muss Supabase zwingend vorhanden sein?
Nein. Die Architektur ist bewusst so aufgebaut, dass sie bei fehlenden Supabase-Zugangsdaten auf einen In-Memory-Modus zurückfällt und dadurch lokales Prototyping sowie Tests ohne externe Infrastruktur möglich bleiben.
Warum ist der Lifespan-Ansatz wichtig?
Weil Scheduler und Runtime-Jobs sauber an den Lebenszyklus der Anwendung gekoppelt werden. Dadurch starten Hintergrundprozesse zuverlässig beim App-Start und werden beim Shutdown kontrolliert beendet.
Kann das Framework später erweitert werden?
Ja. Die Router-Architektur, settings-basierte Konfiguration und die klar getrennten Infrastrukturmodule machen es einfach, neue Geschäftslogik, weitere Datenquellen oder zusätzliche Risiko- und Analyse-Module zu ergänzen.
