Future Me
Cloud-Projekt auf Basis von Azure und .NET zur Planung und automatisierten Zustellung zeitgesteuerter Nachrichten.
React · Azure Functions · Table Storage · API Management · Communication Services · Terraform
FutureMe ist eine Cloud-Anwendung auf Basis von Azure und .NET, mit der zeitgesteuerte Nachrichten geplant, gespeichert und automatisiert zugestellt werden können.
Im Fokus standen dabei die Backend-Logik, die Bereitstellung in Azure sowie ein sauberer Deployment-Workflow mit modernen Cloud- und DevOps-Technologien.
🕹️ Features
Zeitgesteuerter Nachrichtenversand
Automatisierte Zustellung geplanter Nachrichten zu einem späteren Zeitpunkt.
Serverlose Verarbeitung mit Azure Functions
Trennung von HTTP- und Timer-Logik für Speicherung und Versand.
Persistenz über Azure Table Storage
Speicherung geplanter Nachrichten in einem leichtgewichtigen, statusbasierten Modell.
API Gateway mit Rate Limiting
Öffentlicher Einstiegspunkt über API Management mit Schutz vor Missbrauch.
CI/CD
Automatisiertes Deployment über GitHub Actions.
Infrastruktur als Code (IaC) mit Terraform
Reproduzierbare Bereitstellung und Konfiguration der Azure-Infrastruktur mit Terraform.
💡 Designentscheidungen
Azure Functions für das Backend
Ich habe Azure Functions verwendet, weil FutureMe gut zu einem serverlosen Ansatz passt. Die Anwendung braucht nur wenige API-Endpunkte und einen geplanten Hintergrundprozess, sodass Functions deutlich einfacher und passender waren als ein dauerhaft laufendes Backend.
Timer-Function statt Queue-basierter Verarbeitung
Für den aktuellen Scope war eine Timer-Function die einfachere und passendere Lösung. Das Projekt braucht nur eine regelmäßige Prüfung auf fällige E-Mails. Eine Queue-basierte Architektur wäre möglich gewesen, hätte aber für diesen Anwendungsfall unnötige zusätzliche Komplexität eingeführt.
Table Storage statt Cosmos DB
Ich habe Table Storage gewählt, weil FutureMe einfache Datensätze ohne relationale Anforderungen speichert. Für diesen Scope ist Table Storage leichtgewichtig, kostengünstig und gut geeignet für einen status- und zeitbasierten Workflow.
Table Storage PartitionKey
Der PartitionKey basiert auf dem geplanten Sendedatum, weil das wichtigste Abfragemuster im Backend zeitbasiert ist: Die Timer-Function prüft, welche E-Mails an einem bestimmten Tag fällig sind. Damit ist das Speichermodell besser an den tatsächlichen Verarbeitungsablauf angepasst.
API Management vor dem öffentlichen Backend-Endpunkt
Ich habe API Management vor die öffentliche HTTP-Function gesetzt, damit die rohe Function-URL und der Function Key nicht direkt im Frontend sichtbar sind. Zusätzlich bietet APIM einen sauberen öffentlichen Einstiegspunkt und ermöglicht Rate Limiting sowie CORS-Konfiguration auf Gateway-Ebene.
APIM Consumption statt Basic
Ich habe die Consumption-Stufe gewählt, weil sie für ein kleines Portfolio-Projekt deutlich sinnvoller war als die Basic-Stufe. So konnte ich API-Gateway-Konzepte zeigen, ohne hohe fixe monatliche Kosten zu erzeugen.
📈 Weiterentwicklung
Deployment slots
Der aktuelle GitHub Actions Workflow deployed das Frontend und die Functions im Produktionsslot. Für ein echtes Projekt wären mehrere Deploymentslots sinnvoller, sodass der GitHub Actions Workflow den Code in einem anderen Slot bereitstellt.
API Management Tier
Für ein reales Produktivprojekt wäre ein höheres API-Management-Tier sinnvoll, um feinere Möglichkeiten für Rate Limiting, Quotas und zusätzliche Gateway-Funktionen zu erhalten.