Backend- und API-Entwicklung mit .NET

Danijel Balog
Von Danijel Balog
Gründer, Fragon Studios

Robuste Backend-Systeme und APIs mit C# und .NET. Hosting bei Hetzner in Deutschland.

Das Fundament für Ihren Erfolg

Fragon Studios baut Backend-Systeme primär mit C# und .NET 10 auf PostgreSQL; für KMU-Projekte empfehlen wir standardmäßig einen modularen Monolith statt Microservices, weil die Komplexität von Microservices in über 80 Prozent der Fälle mehr Probleme schafft als löst. Microservices oder Monolith? Der modulare Monolith ist für die meisten KMU-Anwendungen der richtige Default. Er ist leichter zu entwickeln, leichter zu deployen, leichter zu debuggen und skaliert für fünfstellige Nutzerzahlen problemlos. Microservices lohnen sich, wenn Teams unabhängig arbeiten müssen, wenn einzelne Komponenten unterschiedliche Skalierungs-Profile haben oder wenn Sprach-Polyglotter Stack nötig ist. 'Microservices von Tag eins' ist fast immer ein teurer Fehler. Datenbanken: PostgreSQL ist unser Default. Relational, transaktional, mit JSON-Support für das, was nicht schema-fest ist. Redis für Cache und Session-Store, MySQL wenn bestehende Systeme das erfordern. Für Vektor-Suche nutzen wir Milvus oder Qdrant in pgvector-Ergänzung, je nach Volumen. Observability ist kein Luxus. Wir instrumentieren mit OpenTelemetry für verteilte Traces, Prometheus für Metriken, Grafana für Dashboards und Loki für Logs. Alles auf eigener Infrastruktur, keine Daten an externe APM-Anbieter. Wenn etwas schief läuft, wissen wir das in Minuten, nicht Stunden. Sprach-Flexibilität: Wir arbeiten primär in C# mit .NET 10, haben aber Node.js mit NestJS und Python mit FastAPI im Toolkit. Wenn Ihr Team bereits auf einem Stack lebt, bauen wir darauf auf.

Entwicklung + Betrieb

Falls gewünscht übernehmen wir auch den Betrieb. Ein Ansprechpartner für alles, keine Abstimmungsprobleme zwischen Teams.

Solide Technologie

C# als Basis für langlebige, wartbare Software. Eine durchgängige Technologie statt zusammengewürfelter Stacks. Andere Sprachen auf Anfrage.

Datenhoheit

Alle Daten bleiben in Österreich/EU. Hosting auf Fragon Cloud mit voller Kontrolle über Ihre Daten.

Backend-Entwicklung bei uns

Transparent, agil und zielgerichtet zum Erfolg.

1

Kundengespräch & Anforderungen

Wir verstehen Ihre Anforderungen, erstellen eine grobe Architektur und stimmen sie mit Ihnen ab.

2

API-Design

Wir dokumentieren alle Endpunkte bevor wir entwickeln. So haben Frontend-Teams früh etwas zum Arbeiten.

3

Entwicklung & Testing

Entwicklung mit automatisierten Tests. Jeder Pull Request wird getestet bevor er merged wird.

4

Deployment

Deployment auf Fragon Cloud oder auf Ihren eigenen Servern, je nach Wunsch.

Technische Standards

C# mit .NET 10 als primärer Stack
PostgreSQL, Redis, Milvus, Qdrant
REST, gRPC, GraphQL und SignalR
OpenTelemetry, Prometheus, Grafana, Loki
Docker und Kubernetes auf Fragon Cloud
Node.js mit NestJS oder Python mit FastAPI auf Anfrage

Typische Projekte

Vier wiederkehrende Backend-Engagements. Keine vollständige Liste, sondern ein Gefühl für die Bandbreite.

Multi-Tenant-API mit Rollensystem

Problem: Ein SaaS-Anbieter wächst über mehrere Kunden hinaus und braucht saubere Mandantentrennung samt rollenbasierter API.

Lösung: Sechs bis zehn Wochen .NET-10-API mit PostgreSQL-Schema-pro-Tenant, RBAC-Layer, Rate-Limiting und OpenAPI-Doku, deployed auf Fragon Cloud.

Legacy-Integration via Adapter-Layer

Problem: Ein Mittelständler will neue Anwendungen anbinden, ohne das Legacy-ERP umzubauen, und braucht eine stabile API-Fassade.

Lösung: Vier bis sechs Wochen Adapter-Layer in C#, Caching für teure Calls, asynchrone Replikation in eine moderne PostgreSQL-Sicht, Monitoring mit OpenTelemetry.

Realtime-System mit WebSocket

Problem: Eine Logistik-Plattform muss Status-Änderungen für Disponenten in Echtzeit anzeigen, derzeit pollt das Frontend alle fünf Sekunden.

Lösung: Vier bis sechs Wochen Backend mit SignalR-Hub für WebSocket-Streaming, ereignisgetriebenem Status-Modell und horizontaler Skalierung über Redis-Backplane.

ETL-Pipeline für Datenkonsolidierung

Problem: Ein Vertriebsteam zieht Reports aus drei verschiedenen Tools zusammen und verbringt damit jeden Montag einen halben Tag.

Lösung: Drei bis fünf Wochen ETL-Pipeline in .NET mit nächtlichem Batch-Job, deduplizierter Ziel-Tabelle und schlanker Reporting-API für ein bestehendes BI-Tool.

Häufige Fragen

Beides, je nach Use Case. REST für klassische CRUD und öffentliche APIs, GraphQL wenn das Frontend viele Datenkombinationen braucht oder mobile Clients Bandbreite optimieren müssen. Wir entscheiden das gemeinsam in der Architektur-Phase, nicht ideologisch.