Hybrid-Architektur: Das Beste aus beiden Welten mit Supabase und Spring Boot

Veröffentlicht am 14 January 2026

Lesezeit: 12 minutes

Statt zwischen der Einfachheit von Supabase und der Leistungsfähigkeit von Spring Boot zu wählen, warum nicht beides kombinieren? Entdecken Sie eine hybride Architektur, die das Beste aus jeder Technologie nutzt.

Das falsche Dilemma der modernen Architektur

Beim Erstellen einer modernen Anwendung mit einem statischen Frontend steht man oft vor einer binären Wahl:

  • Alles auf eine Backend-as-a-Service-Lösung setzen(Supabase, Firebase) - einfach aber begrenzt

  • Ein komplettes Backend bauen(Spring Boot, Node.js) - leistungsstark aber komplex

Diese Wahl ist ein falsches Dilemma. Die hybride Architektur schlägt einen dritten Weg vor: jede Technologie dort einzusetzen, wo sie am besten funktioniert.

Architektonische Vision

Die traditionelle Architektur: Monolithisch

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Traditionelle Architektur" {
  actor Utilisateur as user
  component "Frontend" as frontend #LightBlue
  component "Monolithisches Backend" as backend #LightCoral {
    [Authentification]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [APIs Tierces]
  }
  database "Datenbank" as db #LightGray

  user --> frontend
  frontend --> backend : Alle Anfragen
  backend --> db
}

note right of backend
Alles läuft über das Backend
auch die einfachen Vorgänge
⚠️ Ein einzelner Engpass
⚠️ Komplexität von Anfang an
⚠️ Starke Kopplung
end note
@enduml

In diesem Ansatz müssen sogar die einfachsten Vorgänge (das Lesen eines Artikels, das Erstellen eines Kommentars) über dein Backend laufen. Du zahlst die Kosten der Komplexität schon ab dem ersten Tag.

Die BaaS-Architektur: Jeder Delegierte

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Architektur BaaS rein" {
  actor Utilisateur as user
  component "Frontend" as frontend #LightBlue
  cloud "Supabase / Firebase" as baas #LightGreen {
    [Auth]
    [Database]
    [Storage]
    [Edge Functions]
  }

  user --> frontend
  frontend --> baas : Alle Operationen
}

note right of baas
Schnelle Entwicklung
Kein Server zu verwalten
⚠️ Begrenzt für komplexe Logik
⚠️ Vendor Lock-In
⚠️ Beschränkungen bei Edge Functions
end note
@enduml

Im Gegensatz dazu ist es zunächst verlockend, alles einem BaaS zu delegieren, doch es zeigt schnell seine Grenzen, sobald die Geschäftslogik komplexer wird.

Die hybride Architektur: Trennung der Verantwortlichkeiten

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

actor Utilisateur as user #LightBlue

package "Frontend-Schicht" {
  component "Statische Site JBake" as frontend #SkyBlue
}

package "Einfache Schicht (Supabase)" #LightGreen {
  component "Authentifizierung" as auth
  component "CRUD Einfach" as crud
  component "Dateispeicherung" as storage
  component "Echtzeit" as realtime
}

package "Geschäftsschicht (Spring Boot)" #Coral {
  component "Komplexe Logik" as logic
  component "Orchestrierung" as orchestration
  component "Geplante Jobs" as jobs
  component "Integrationen" as integrations
}

database "PostgreSQL geteilt" as db #LightGray

user --> frontend

frontend --> auth : OAuth2, JWT
frontend --> crud : Artikel, Profile
frontend --> storage : Bilder, Dateien
frontend --> realtime : Benachrichtigungen

frontend --> logic : Berechnungen, Berichte
frontend --> orchestration : Workflows
logic --> integrations : Stripe, APIs
orchestration --> db
jobs --> db

crud --> db
auth --> db

note bottom of db
**Eine einzige Quelle der Wahrheit**
Geteilt zwischen Supabase und Spring Boot
end note

note right of auth
Kostenlos bis zu 50k Nutzer
Konfiguration in wenigen Klicks
OAuth2 mehrere Anbieter
end note

note right of logic
Aktiviert nur wenn nötig
Kotlin + Koroutinen
Komplexe Transaktionen
end note
@enduml

Die hybride Architektur trennt die Verantwortlichkeiten deutlich nach Komplexität und Art der Operationen.

Entwurfsprinzipien

Prinzip 1: Einfach beginnen, intelligent weiterentwickeln

@startuml
skinparam backgroundColor #FEFEFE

rectangle "**Phase 1 : MVP**" #LightGreen {
  component "JBake + Supabase" as mvp
  note right
    ✓ Développement en jours
    ✓ Coût : 0€
    ✓ Validation concept
  end note
}

rectangle "**Phase 2 : Croissance**" #LightYellow {
  component "JBake + Supabase\n+ Spring Boot (optionnel)" as growth
  note right
    ✓ Logique métier émerge
    ✓ Premiers jobs planifiés
    ✓ Intégrations tierces
  end note
}

rectangle "**Phase 3 : Scale**" #LightCoral {
  component "Architecture Complète" as scale
  note right
    ✓ Orchestration complexe
    ✓ Performances optimisées
    ✓ Cache distribué
  end note
}

mvp -down-> growth : Quand la complexité\nle justifie
growth -down-> scale : Optimisation\ncontinue
@enduml

Bauen Sie Spring Boot nicht, wenn Sie es nicht benötigen.Starte mit Supabase, füge Spring Boot hinzu, wenn die Komplexität es rechtfertigt.

Prinzip 2: Trennung nach Art der Operation

@startmindmap
skinparam backgroundColor #FEFEFE
* Opérations\nApplicatives

left side

** Opérations Simples\n(Supabase)
***_ CRUD Standard
****_ Lecture
****_ Création
****_ Mise à jour
****_ Suppression
***_ Authentification
****_ Login/Logout
****_ OAuth2
****_ Gestion session
***_ Stockage
****_ Upload fichiers
****_ CDN automatique
***_ Temps Réel
****_ WebSocket
****_ Notifications

right side

** Opérations Complexes\n(Spring Boot)
***_ Logique Métier
****_ Calculs complexes
****_ Règles métier
****_ Validations avancées
***_ Orchestration
****_ Multi-services
****_ Transactions distribuées
****_ Saga patterns
***_ Tâches Planifiées
****_ Rapports périodiques
****_ Synchronisations
****_ Nettoyages
***_ Intégrations
****_ Paiements (Stripe)
****_ APIs tierces
****_ Services ML/AI

@endmindmap

Prinzip 3: Eine einzige Quelle der Wahrheit

@startuml
skinparam backgroundColor #FEFEFE

database "PostgreSQL" as db #LightGray {
  package "Schema: auth (Supabase)" #LightGreen {
    [users]
    [sessions]
    [identities]
  }

  package "Schema: public (Geteilt)" #SkyBlue {
    [articles]
    [comments]
    [profiles]
  }

  package "Schema: business (Spring Boot)" #Coral {
    [orders]
    [payments]
    [reports]
  }
}

component "Supabase" as supabase #LightGreen
component "Spring Boot" as spring #Coral

supabase -down-> users : Gère
supabase -down-> sessions : Gère
supabase -down-> articles : Accède
supabase -down-> comments : Accède
supabase -down-> profiles : Accède

spring -down-> articles : Accède
spring -down-> profiles : Accède
spring -down-> orders : Gère
spring -down-> payments : Gère
spring -down-> reports : Gère

note right of db
**Vorteile:**
• Keine komplexe Synchronisierung
• JOINs zwischen Tabellen möglich
• Garantierte Konsistenz
• Vereinheitlichte Migrationen
end note
@enduml

Durch das Teilen derselben PostgreSQL-Instanz arbeiten Supabase und Spring Boot mit denselben Daten ohne komplexe Synchronisation.

Orchestrierung der Flüsse

Fluss 1: Zentrale Authentifizierung

@startuml
skinparam backgroundColor #FEFEFE
autonumber

actor "Utilisateur" as user
participant "JBake" as jbake
participant "Supabase Auth" as auth
participant "Spring Boot" as spring
database "PostgreSQL" as db

== Authentification ==
user -> jbake : Clique "Se connecter"
jbake -> auth : Redirect OAuth2 (Google/GitHub)
auth -> user : Consent screen
user -> auth : Autorise
auth -> auth : Génère JWT
auth -> jbake : Retourne JWT + Refresh Token
jbake -> jbake : Stocke tokens (sessionStorage)

== Accès aux Ressources ==
group Opération Simple (CRUD)
  user -> jbake : Crée un article
  jbake -> db : POST avec JWT
  note right: Supabase Row Level Security\nvérifie le JWT automatiquement
  db -> jbake : Article créé
end

group Opération Complexe (Métier)
  user -> jbake : Génère un rapport
  jbake -> spring : POST /api/reports\navec JWT
  spring -> spring : Valide JWT Supabase
  spring -> spring : Extrait claims (user_id, roles)
  spring -> db : Requêtes complexes
  spring -> jbake : Rapport généré
end

note over auth, spring
  **Le JWT est universel**
  Valide par Supabase ET Spring Boot
  Pas de double authentification
end note
@enduml

Schlüsselpunkt: Ein einziger Authentifizierungsprozess, ein einziger JWT, überall einsetzbar.

Flux 2: Orchestration eines komplexen Geschäftsprozesses

@startuml
skinparam backgroundColor #FEFEFE
autonumber

actor "Client" as user
participant "JBake" as jbake
participant "Spring Boot" as spring
participant "Supabase DB" as supadb
participant "Stripe API" as stripe
participant "Inventory Service" as inventory
participant "Email Service" as email
database "PostgreSQL" as db

user -> jbake : Passe commande
jbake -> spring : POST /api/orders/create

== Orchestration Spring Boot ==
spring -> db : BEGIN TRANSACTION

par Vérifications Parallèles
  spring -> inventory : Vérifier stock
  inventory -> spring : Stock OK
else
  spring -> db : Vérifier profil client
  db -> spring : Client vérifié
end

spring -> stripe : Créer Payment Intent
stripe -> spring : Intent créé (ID: pi_xxx)

spring -> db : Créer Order (status: PENDING)
db -> spring : Order créé

spring -> stripe : Confirmer paiement
stripe -> spring : Paiement confirmé

spring -> db : Update Order (status: PAID)
spring -> inventory : Décrémenter stock
spring -> db : COMMIT TRANSACTION

par Notifications Asynchrones
  spring -> email : Email confirmation
else
  spring -> supadb : Insert notification
  note right: Notification temps réel\nvia Supabase Realtime
end

spring -> jbake : Order confirmé
jbake -> user : Affiche confirmation

note over spring
  **Responsabilités Spring Boot :**
  • Transaction ACID
  • Orchestration multi-services
  • Rollback automatique si erreur
  • Gestion des cas limites
end note
@enduml

Was Spring Boot bringt: Zuverlässige Orchestrierung komplexer Prozesse, die mehrere Systeme umfassen, mit Transaktionsgarantie.

Flux 3: Geplante Aufträge und Synchronisierungen

@startuml
skinparam backgroundColor #FEFEFE

participant "Scheduler\n(Spring Boot)" as scheduler
participant "Report Service" as report
participant "PostgreSQL" as db
participant "External API" as api
participant "Email Service" as email
participant "Supabase Storage" as storage

== Job Quotidien : 2h00 ==
activate scheduler
scheduler -> report : Déclenche génération rapport

activate report
report -> db : Récupère données\ndes dernières 24h
db -> report : Dataset

report -> report : Calculs & Agrégations
report -> report : Génération PDF

report -> storage : Upload PDF
storage -> report : URL publique

report -> email : Envoie aux admins\navec lien PDF
deactivate report

== Job Hebdomadaire : Dimanche 3h00 ==
scheduler -> report : Synchronisation externe

activate report
report -> api : Fetch données externes
api -> report : Nouvelles données

report -> db : Mise à jour tables
report -> db : Nettoyage données obsolètes
deactivate report

== Job Mensuel : 1er du mois ==
scheduler -> report : Facturation

activate report
report -> db : Liste clients actifs
report -> report : Calcul montants
report -> api : Génération factures (Stripe)
report -> email : Envoi factures
deactivate report

deactivate scheduler

note right of scheduler
  **Impossible avec Supabase seul**
  Edge Functions non adaptées
  pour jobs longs et récurrents
end note
@enduml

Was Spring Boot mitbringt: Zuverlässige geplante Jobs mit Zustandsverwaltung, automatischer Wiederholung und garantierte Ausführung.

Entscheidungsmatrix

Wann Supabase verwenden ?

@startuml
skinparam backgroundColor #FEFEFE

start

:Nouvelle fonctionnalité à implémenter;

if (CRUD simple ?) then (oui)
  :✅ **Supabase**;
  stop
else (non)
  if (Authentification ?) then (oui)
    :✅ **Supabase Auth**;
    stop
  else (non)
    if (Upload fichiers ?) then (oui)
      :✅ **Supabase Storage**;
      stop
    else (non)
      if (Temps réel ?) then (oui)
        :✅ **Supabase Realtime**;
        stop
      else (non)
        if (Row Level Security\nsuffisante ?) then (oui)
          :✅ **Supabase + Policies**;
          stop
        else (non)
          :⚠️ **Considérer Spring Boot**;
          #Coral:Passer à l'arbre\nde décision Spring Boot;
          stop
        endif
      endif
    endif
  endif
endif

@enduml

Wann sollte man Spring Boot verwenden?

@startuml
skinparam backgroundColor #FEFEFE

start

:Nouvelle fonctionnalité complexe;

if (Orchestration\nmulti-services ?) then (oui)
  :✅ **Spring Boot**;
  stop
else (non)
  if (Transaction ACID\ncritique ?) then (oui)
    :✅ **Spring Boot**;
    stop
  else (non)
    if (Job planifié ?) then (oui)
      :✅ **Spring Boot Scheduler**;
      stop
    else (non)
      if (Intégration API\ntierce complexe ?) then (oui)
        :✅ **Spring Boot**;
        stop
      else (non)
        if (Calculs lourds\n> 10 secondes ?) then (oui)
          :✅ **Spring Boot**;
          stop
        else (non)
          if (Cache distribué\nnécessaire ?) then (oui)
            :✅ **Spring Boot + Redis**;
            stop
          else (non)
            :⚠️ **Probablement Supabase**;
            #LightGreen:Revenir à l'arbre\nde décision Supabase;
            stop
          endif
        endif
      endif
    endif
  endif
endif

@enduml

Beispiele für Architektur nach Projekttyp

Blog / Portfolio

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Persönlicher Blog - 95% Supabase" {
  component "JBake" as jbake #SkyBlue

  package "Supabase (Kostenlos)" #LightGreen {
    [Auth: OAuth2 Google]
    [Articles (CRUD)]
    [Commentaires]
    [Images (Storage)]
    [Notifications Realtime]
  }

  package "Spring Boot (Optional)" #LightCoral {
    [Newsletter Mensuelle]
    note bottom: Nur geplanter Job
  }

  database "PostgreSQL" as db

  jbake --> [Auth: OAuth2 Google]
  jbake --> [Articles (CRUD)]
  jbake --> [Commentaires]
  jbake --> [Images (Storage)]
  jbake --> [Notifications Realtime]

  [Articles (CRUD)] --> db
  [Commentaires] --> db
  [Newsletter Mensuelle] --> db
}

note bottom of "Spring Boot (Optional)"
**Spring Boot nicht obligatorisch**
Newsletter kann über einen Drittanbieter-Service (Mailchimp) verwaltet werden
end note
@enduml

Urteil: 100% Supabase reicht völlig aus.

SaaS-Anwendung

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "SaaS-Anwendung - Hybride Architektur" {
  component "JBake / React" as frontend #SkyBlue

  package "Supabase" #LightGreen {
    [Auth Multi-tenant]
    [Profils Utilisateurs]
    [Données Simples]
    [Storage Documents]
  }

  package "Spring Boot" #Coral {
    [Facturation (Stripe)]
    [Analytics Avancées]
    [Rapports Mensuels]
    [Quotas & Limites]
    [Webhooks Stripe]
  }

  cloud "Externe Dienste" {
    [Stripe API]
    [SendGrid Email]
  }

  database "Geteilte PostgreSQL" as db

  frontend --> [Auth Multi-tenant]
  frontend --> [Profils Utilisateurs]
  frontend --> [Données Simples]
  frontend --> [Facturation (Stripe)]
  frontend --> [Analytics Avancées]

  [Auth Multi-tenant] --> db
  [Profils Utilisateurs] --> db
  [Données Simples] --> db

  [Facturation (Stripe)] --> db
  [Facturation (Stripe)] --> [Stripe API]
  [Analytics Avancées] --> db
  [Rapports Mensuels] --> db
  [Rapports Mensuels] --> [SendGrid Email]
  [Webhooks Stripe] ..> [Stripe API] : Écoute
}

note right of "Spring Boot"
**Erforderlich für:**
• Abonnementverwaltung
• Wiederkehrende Abrechnung
• Dynamische Quotas
• Komplexe Analytics
• Zuverlässige Webhooks
end note
@enduml

UrteilHybride Architektur erforderlich. Supabase für das Wesentliche, Spring Boot für den kritischen Teil (Zahlungen, Rechnungsstellung).

E-Commerce

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "E-Commerce - 70% Spring Boot" {
  component "Storefront (JBake/React)" as frontend #SkyBlue

  package "Supabase" #LightGreen {
    [Auth Clients]
    [Catalogue Produits\n(lecture seule)]
    [Images Produits]
  }

  package "Spring Boot (Business-Logik)" #Coral {
    [Gestion Commandes]
    [Paiements Stripe]
    [Gestion Stock]
    [Calcul Frais Port]
    [Génération Factures]
    [Synchronisation ERP]
    [Emails Transactionnels]
  }

  cloud "Integrationen" {
    [Stripe]
    [Transporteur API]
    [ERP Externe]
  }

  database "PostgreSQL" as db

  frontend --> [Auth Clients]
  frontend --> [Catalogue Produits\n(lecture seule)]
  frontend --> [Gestion Commandes]

  [Auth Clients] --> db
  [Catalogue Produits\n(lecture seule)] --> db

  [Gestion Commandes] --> db
  [Paiements Stripe] --> [Stripe]
  [Gestion Stock] --> db
  [Calcul Frais Port] --> [Transporteur API]
  [Génération Factures] --> db
  [Synchronisation ERP] --> [ERP Externe]
  [Synchronisation ERP] --> db
}

note right of "Spring Boot (Business-Logik)"
**Spring Boot unverzichtbar:**
• Kritische Transaktionen
• Komplexe Orchestrierung
• Multiple Integrationen
• Gesetzliche Konformität
• Synchronisations-Jobs
end note
@enduml

UrteilSpring Boot unverzichtbar. Supabase nur für auth und Katalog.

Progressive Migrationsstrategie

@startuml
skinparam backgroundColor #FEFEFE

|Semaine 1-2|
start
:Créer projet Supabase;
:Configurer Auth (Google, GitHub);
:Définir schéma PostgreSQL initial;
:Implémenter CRUD de base sur JBake;
:Déployer MVP sur GitHub Pages;
note right
  **Livrable :** Application fonctionnelle
  **Coût :** 0€
  **Temps :** 1-2 semaines
end note

|Semaine 3-4|
:Observer utilisation réelle;
:Identifier limitations;

|Décision|
if (Logique complexe\némerge ?) then (non)
  |Supabase|
  :Continuer avec Supabase seul;
  :Ajouter Edge Functions si besoin;
  stop
else (oui)
  |Spring Boot|
  :Créer projet Spring Boot;
  :Configurer validation JWT Supabase;
  :Migrer logique complexe vers Spring Boot;
  note right
    **Migration sélective**
    Seulement ce qui est complexe
  end note
endif

|Semaines suivantes|
:Déployer Spring Boot (Cloud Run, EC2);
:Connecter à PostgreSQL Supabase;
:Implémenter premiers jobs planifiés;
:Intégrer APIs tierces;

stop

note right
  **Architecture finale hybride**
  Supabase + Spring Boot
  en parfaite harmonie
end note
@enduml

Kosten und betriebliche Überlegungen

Kostenstruktur

@startuml
skinparam backgroundColor #FEFEFE

package "Geschätzte monatliche Kosten" {

  rectangle "MVP-Phase\n(0-1000 Nutzer)" #LightGreen {
    [JBake (GitHub Pages): 0€]
    [Supabase: 0€]
    [Spring Boot: N/A]
    note bottom: **Gesamt: 0€/Monat**
  }

  rectangle "Wachstumsphase\n(1k-10k Nutzer)" #LightYellow {
    [JBake (GitHub Pages): 0€]
    [Supabase: 0€]
    [Spring Boot (Cloud Run): 20-50€]
    [PostgreSQL (si séparé): 0-30€]
    note bottom: **Gesamt: 20-80€/Monat**
  }

  rectangle "Scale-Phase\n(10k-100k Nutzer)" #LightCoral {
    [JBake (Netlify Pro): 19€]
    [Supabase Pro: 25€]
    [Spring Boot (instances multiples): 100-300€]
    [Redis Cache: 20-50€]
    [Monitoring: 20€]
    note bottom: **Gesamt: 184-414€/Monat**
  }
}

note right of "Scale-Phase\n(10k-100k Nutzer)"
An diesem Punkt rechtfertigen die Einnahmen die Kosten bei Weitem
end note
@enduml

Operative Verantwortlichkeiten

@startuml
skinparam backgroundColor #FEFEFE

package "Wer verwaltet was?" {

  rectangle "Verwaltet durch Supabase (0 Aufwand)" #LightGreen {
    [Authentification]
    [Base de données]
    [Backups automatiques]
    [Scaling automatique]
    [Monitoring DB]
    [Sécurité DB]
  }

  rectangle "Verwaltet durch GitHub (0 Aufwand)" #SkyBlue {
    [Hébergement site statique]
    [HTTPS/SSL]
    [CDN global]
    [Déploiement automatique]
  }

  rectangle "Zu verwalten (Spring Boot)" #LightCoral {
    [Déploiement application]
    [Monitoring APM]
    [Logs centralisés]
    [Scaling horizontal]
    [Mises à jour sécurité]
  }
}

note bottom of "Zu verwalten (Spring Boot)"
**Minimierbar mit:**
• Cloud Run (serverless)
• Kubernetes (falls erforderlich)
• Managed Services (RDS, etc.)
end note
@enduml

Fazit : Das perfekte Gleichgewicht

Die hybride Architektur Supabase + Spring Boot ist kein Kompromiss, sie ist eineSynergie.

Die zu beachtenden Prinzipien

@startmindmap
skinparam backgroundColor #FEFEFE
* Architecture\nHybride

** Commencer Simple
***_ MVP avec Supabase
***_ 0€ de coût initial
***_ Validation rapide

** Évoluer Intelligemment
***_ Ajouter Spring Boot\nsi nécessaire
***_ Migration progressive
***_ Pas de refonte totale

** Exploiter les Forces
***_ Supabase: Simplicité
***_ Spring Boot: Puissance
***_ PostgreSQL: Source unique

** Minimiser la Complexité
***_ Pas de synchronisation
***_ Pas de duplication
***_ Architecture claire

** Optimiser les Coûts
***_ Gratuit au départ
***_ Scaling progressif
***_ ROI évident

@endmindmap

Wann sollte diese Architektur gewählt werden?

�✅ Diese Architektur ist ideal wenn :

  • Sie möchten schnell starten (MVP in Tagen, nicht in Monaten)

  • Sie erwarten eine Zunahme der geschäftlichen Komplexität.

  • Sie wollen die Anfangskosten minimieren

  • Sie mögen PostgreSQL und möchten eine einzige Quelle der Wahrheit.

  • Sie schätzen Kotlin und Coroutines für den Geschäftslogik-Code

  • Sie wollen ein komplettes Vendor‑Lock‑In vermeiden.

❌ Diese Architektur ist NICHT geeignet, wenn :

  • Dein Projekt ist einfach und wird einfach bleiben (persönlicher Blog → 100 % Supabase reicht)

  • Du hast bereits einen etablierten Backend‑Stack, den du beherrschst.

  • Sie bevorzugen ein traditionelles Monolith

  • Sie benötigen .NET, Python oder eine andere Sprache für das Backend

Endgültiger Überblick

@startuml
skinparam backgroundColor #FEFEFE

package "Vollständige hybride Architektur" {

  actor "Benutzer" as users

  rectangle "Frontend (Statisch)" #SkyBlue {
    [JBake / GitHub Pages]
    note right: Kostenlos, globales CDN
  }

  rectangle "Einfaches Backend (Supabase)" #LightGreen {
    [Auth OAuth2]
    [CRUD APIs]
    [Storage]
    [Realtime]
    note right
Kostenlos bis zu 50k users
Null Serverkonfiguration
    end note
  }

  rectangle "Business-Backend (Spring Boot)" #Coral {
    [Orchestration]
    [Jobs Planifiés]
    [Intégrations]
    [Transactions]
    note right
Nur aktiviert,
falls erforderlich
    end note
  }

  database "PostgreSQL\nEinzige Quelle der Wahrheit" as db #LightGray

  users --> [JBake / GitHub Pages]

  [JBake / GitHub Pages] --> [Auth OAuth2]
  [JBake / GitHub Pages] --> [CRUD APIs]
  [JBake / GitHub Pages] --> [Storage]
  [JBake / GitHub Pages] --> [Realtime]
  [JBake / GitHub Pages] --> [Orchestration]

  [Auth OAuth2] --> db
  [CRUD APIs] --> db
  [Orchestration] --> db
  [Jobs Planifiés] --> db
  [Intégrations] --> db
}

note bottom of db
**Eine einzige Basis, zwei Konsumenten**
• Supabase für das Einfache
• Spring Boot für das Komplexe
• Keine Synchronisierung erforderlich
end note

@enduml

Das Beste aus beiden Welten

Diese Architektur gibt Ihnen:

🚀 Die Geschwindigkeit von Supabase

  • Start in Stunden, nicht in Wochen

  • OAuth2-Authentifizierung in wenigen Klicks

  • Automatisch generierte REST-APIs

  • Zero-Konfiguration für Server

�💪 Die Macht von Spring Boot

  • Kotlin und Coroutines für eleganten asynchronen Code

  • Orchestrierung komplexer Geschäftsprozesse

  • Zuverlässig geplante Jobs

  • ACID-Transaktionen garantiert

  • Vollständiges Spring-Ökosystem

�💰 Die progressive Wirtschaft

  • 0€ zum Starten und Validieren

  • Kosten, die dem Wachstum folgen

  • Kein vorzeitiges Über-Engineering

�🎯 Die architektonische Flexibilität

  • Progressive Migration ohne Neugestaltung

  • Hinzufügen von Spring Boot nur, wenn nötig

  • Kein vollständiger Vendor-Lock-in

  • Erweiterbare Architektur

Um weiter zu gehen

Technische Ressourcen

Dokumentation Supabase :

Dokumentation Spring Boot :

Zusatzartikel:

  • Sicherung der APIs mit JWT

  • Optimierung der PostgreSQL-Performance

  • Progressive Migrationsmuster

  • Fehlerbehandlung in verteilter Architektur

Reale Anwendungsfälle

Diese hybride Architektur wird erfolgreich in:

  • SaaS B2B: Supabase-Authentifizierung, Abrechnung Spring Boot

  • Marktplätze: Supabase-Katalog, Spring Boot-Transaktionen

  • InhaltsplattformenArtikel Supabase, Analytics Spring Boot

  • Interne Werkzeuge: CRUD Supabase, Workflows Spring Boot

Start-Checkliste

Phase 1 - Grundlagen (Woche 1)

  • Supabase-Konto erstellen - [ ] PostgreSQL-Projekt konfigurieren - [ ] Auth aktivieren (Google, GitHub) - [ ] Initialschema definieren - [ ] Row-Level-Sicherheit konfigurieren - [ ] APIs von JBake testen

Phase 2 - MVP (Woche 2-3)

  • Hauptseiten implementieren - [ ] OAuth2-Authentifizierung integrieren - [ ] CRUD-Formulare erstellen - [ ] Speicher für Dateien einrichten - [ ] Auf GitHub Pages bereitstellen - [ ] Testen unter realen Bedingungen

Phase 3 - Entwicklung (bei Bedarf)

  • Bedarf an komplexer Logik identifizieren - [ ] Spring Boot-Projekt erstellen falls nötig - [ ] JWT-Validierung in Supabase konfigurieren - [ ] Verbinden mit PostgreSQL Supabase - [ ] Komplexe Funktionen migrieren - [ ] Geplante Jobs implementieren - [ ] Spring Boot bereitstellen (Cloud Run usw.)

Anti-Patterns zu vermeiden

❌ Mach das nicht :

  • Dupliziere die Daten zwischen Supabase und Spring Boot

  • Zwei getrennte PostgreSQL-Datenbanken erstellen

  • Codieren Sie die Authentifizierung selbst

  • Verwenden Sie Spring Boot für simples CRUD

  • Von Anfang an über-architekturieren

  • Row Level Security von Supabase ignorieren

Machen Sie lieber:

  • Eine einzige PostgreSQL-Datenbank teilen

  • Supabase die Authentifizierung verwalten lassen

  • Spring Boot nur wegen der Komplexität verwenden

  • Einfach beginnen, sich schrittweise weiterentwickeln

  • Die Stärken jeder Technologie nutzen

  • Mit RLS auf Datenbankebene sichern

Entwicklungsperspektiven

Hinzufügen neuer Fähigkeiten

@startuml
skinparam backgroundColor #FEFEFE

rectangle "Aktuelle Architektur" #SkyBlue {
  [JBake]
  [Supabase]
  [Spring Boot]
}

rectangle "Mögliche Weiterentwicklungen" #LightYellow {

  package "Performance" {
    [Redis Cache]
    [CDN pour Assets]
    [PostgreSQL Replicas]
  }

  package "Monitoring" {
    [Grafana]
    [Prometheus]
    [Sentry]
  }

  package "CI/CD" {
    [GitHub Actions]
    [Tests Automatisés]
    [Déploiement Continu]
  }

  package "Funktionalitäten" {
    [Search (ElasticSearch)]
    [Queue (RabbitMQ)]
    [Event Sourcing]
  }
}

[Spring Boot] .down.> [Redis Cache] : Peut ajouter
[Spring Boot] .down.> [Queue (RabbitMQ)] : Peut ajouter
[Spring Boot] .down.> [Search (ElasticSearch)] : Peut ajouter

[Supabase] .down.> [PostgreSQL Replicas] : Peut ajouter

note bottom
**Erweiterbare Architektur**
Jede Ergänzung ist unabhängig
Keine globale Überarbeitung erforderlich
end note
@enduml

Horizontale Skalierung

Wenn Ihre Anwendung wächst, skaliert die hybride Architektur natürlich:

Supabase :

  • Scale skaliert automatisch bis zu Millionen von Operationen

  • Lese-Replikate für Leseleistung

  • Zeitpunktbezogene Wiederherstellung für die Sicherheit

Spring Boot :

  • Mehrere Instanzen hinter load balancer

  • Zustandsloses Design erleichtert die horizontale Skalierung.

  • Kubernetes für Orchestrierung bei Bedarf

PostgreSQL:

  • Partitionierung für große Tabellen

  • Verbindungspooling (PgBouncer)

  • Sharding ist wirklich notwendig (selten)

Architektonische Zeugnisse

Start-up SaaS (50k Nutzer)

_ Wir haben mit 100 % Supabase begonnen. Bei 5 k Nutzern haben wir Spring Boot ausschließlich für die Stripe‑Abrechnung und die monatlichen Berichte hinzugefügt. Ein Jahr später laufen immer noch 80 % unserer Vorgänge über Supabase. Spring Boot übernimmt nur den kritischen Teil. Diese Trennung hat es uns ermöglicht, zu skalieren, ohne eine Überarbeitung vorzunehmen. _

E-Learning-Plattform (10k Nutzer)

_ Die OAuth2-Authentifizierung von Supabase hat uns 3 Wochen Entwicklungszeit gespart. Die automatisch generierten APIs verwalten unseren gesamten Kurskatalog. Spring Boot wird nur für die PDF-Zertifikate und Fortschritts-E-Mails verwendet. Einfache, wartbare, skalierbare Architektur. _

Marketplace B2B (3k Nutzer)

_ Spring Boot verwaltet die Transaktionen zwischen Käufern und Verkäufern (kritisch). Supabase verwaltet alles andere: Profile, Echtzeit-Messaging, Dokumente. Der Umstand, dass sie dieselbe PostgreSQL-Datenbank teilen, erspart uns jede komplexe Synchronisation. Die beste architektonische Entscheidung, die wir je getroffen haben. _

Synthese: Ein modernes architektonisches Paradigma

Die hybride Architektur Supabase + Spring Boot repräsentiert ein neues Paradigma:architektonische Spezialisierung.

@startuml
skinparam backgroundColor #FEFEFE

rectangle "Altes Paradigma" #LightCoral {
  card "Alles im Backend" {
    [Auth]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [Storage]
    [Realtime]
  }
  note bottom
Maximale Komplexität
ab Tag 1
  end note
}

rectangle "Neues Paradigma" #LightGreen {
  card "Supabase\n(Commodity)" {
    [Auth]
    [CRUD Simple]
    [Storage]
    [Realtime]
  }

  card "Spring Boot\n(Differenzierung)" {
    [Logique Métier]
    [Jobs]
    [Intégrations]
  }

  note bottom
Progressive Komplexität
nur hinzugefügt, wenn erforderlich
  end note
}

[Ancien Paradigme] -right-> [Nouveau Paradigme] : Évolution

@enduml

Das grundlegende Prinzip :Bauen Sie nicht das, was bereits als Service existiert. Konzentrieren Sie sich auf das, was Ihre Anwendung unterscheidet.

Die 80/20-Regel

In den meisten Anwendungen:

  • 80 % der OperationenSie sind standardmäßiger CRUD → Supabase

  • 20% der Vorgängebenötigt Geschäftslogik → Spring Boot

Diese natürliche Regel rechtfertigt die hybride Architektur.

@startuml
skinparam backgroundColor #FEFEFE

package "Verteilung der Operationen" {

  rectangle "80% - Standardoperationen" #LightGreen {
    [Lecture de données]
    [Création d'entités]
    [Mise à jour simple]
    [Suppression]
    [Upload fichiers]
    [Authentification]

    note bottom: **Von Supabase verwaltet**
  }

  rectangle "20% - Geschäftslogik" #Coral {
    [Calculs complexes]
    [Workflows multi-étapes]
    [Transactions critiques]
    [Intégrations tierces]
    [Jobs planifiés]

    note bottom: **Von Spring Boot verwaltet**
  }
}

note right
**Optimaler Fokus:**
Ihre Entwicklungszeit
konzentriert auf die 20 %, die
Ihr Produkt differenzieren
end note
@enduml

Endgültige Schlussfolgerung

Die hybride Architektur ist kein technischer Kompromiss, sie ist einestrategische Entscheidung(No visible characters – output is empty.)

Es ermöglicht Ihnen:

  • ✅ Schnell mit einem funktionalen MVP starten

  • ✅ Ihren Markt ohne hohe Investitionen validieren

  • Schrittweise weiterentwickeln, wenn die Komplexität es erfordert.

  • Ihre Kosten bei jedem Schritt kontrollieren

  • Das Beste aus jeder Technologie nutzen

  • �✅ Vermeiden vorzeitiges Überengineering

  • Flexibilität für die Zukunft bewahren

Sie stellt dar:

  • �🎯PragmatismusJede Technologie, in der sie hervorragend ist

  • �🚀Geschwindigkeit: minimale Time-to-Market

  • �💰WirtschaftKosten, die am Wert ausgerichtet sind

  • �🔮Skalierbarkeit: Architektur, die mit Ihnen wächst

  • �🛡️Robustheit: Erprobte und zuverlässige Dienstleistungen

Ihr nächster Schritt

Wenn Ihnen diese Architektur zusagt, hier ist, wo Sie anfangen können:

  1. Erstellen Sie ein Supabase-Konto(kostenlos)

  2. Definieren Sie Ihr minimales Datenschema

  3. Konfigurieren Sie die OAuth2-Authentifizierung

  4. Erstelle deine erste JBake-Seite, die die API nutzt

  5. Stellen Sie auf GitHub Pages bereit

Sie werden ein funktionsfähiges MVP haben ineinige Tage.

Spring Boot wird natürlich kommen, wenn Sie es benötigen. Nicht früher.

Die hybride Architektur ist die Kunst, genau das zu bauen, was nötig ist, wenn es nötig ist.

Gute Entwicklung! 🚀

Teilen Sie diesen Artikel, wenn Sie denken, dass er anderen Entwicklern helfen kann, die richtigen architektonischen Entscheidungen zu treffen.

Verwandte Artikel

HyperFrames-Gradle: AsciiDoc in MP4-Video umwandeln
31 May 2026
Audit meines LLM-Verbrauchs: SQLite, OpenCode, Ollama Cloud, und warum mein Pro‑Abonnement den globalen Markt sprengt.
18 May 2026
Die Architektur « Unabhängiges Plugin + Konsumentenwurzel » : Warum meine Gradle-Builds sich duplizieren
14 May 2026
Le Knowledge Graph comme moteur de recommandation : comment j'ai tué les « articles connexes » chronologiques
12 May 2026