Architecture Hybride : Le Meilleur des Deux Mondes avec Supabase et Spring Boot

Veröffentlicht am 14 January 2026

Lesezeit : 12 minutes

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

Das falsche Dilemma der modernen Architektur

Wenn man eine moderne Anwendung mit einem statischen Frontend erstellt, steht man oft vor einer binären Wahl:

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

  • Einen vollständigen Backend erstellen(Spring Boot, Node.js) - mächtig aber komplex

Diese Wahl ist ein falsches Dilemma. Die hybride Architektur bietet einen dritten Weg: jede Technologie dort einzusetzen, wo sie ihre Stärken ausspielen kann

Architektonische Vision

Traditionelle Architektur : Monolithisch

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Architecture Traditionnelle" {
  actor Utilisateur as user
  component "Frontend" as frontend #LightBlue
  component "Backend Monolithique" as backend #LightCoral {
    [Authentification]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [APIs Tierces]
  }
  database "Base de Données" as db #LightGray

  user --> frontend
  frontend --> backend : Toutes les requêtes
  backend --> db
}

note right of backend
  Tout passe par le backend
  même les opérations simples

  ⚠️ Point de congestion unique
  ⚠️ Complexité dès le départ
  ⚠️ Couplage fort
end note
@enduml

Bei diesem Ansatz müssen sogar die einfachsten Vorgänge (Artikel lesen, Kommentar erstellen) über dein Backend laufen. Du zahlst den Preis der Komplexität ab dem ersten Tag.

Die BaaS-Architektur: Alles Delegierte

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

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

  user --> frontend
  frontend --> baas : Toutes les opérations
}

note right of baas
  Développement rapide
  Pas de serveur à gérer

  ⚠️ Limité pour logique complexe
  ⚠️ Vendor lock-in
  ⚠️ Edge Functions contraintes
end note
@enduml

Im Gegensatz dazu erscheint das Auslagern alles an einen BaaS zunächst attraktiv, aber es zeigt schnell seine Grenzen, sobald die Geschäftslogik komplexer wird.

Hybride Architektur: Trennung der Verantwortlichkeiten

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

actor Utilisateur as user #LightBlue

package "Couche Frontend" {
  component "Site Statique JBake" as frontend #SkyBlue
}

package "Couche Simple (Supabase)" #LightGreen {
  component "Authentification" as auth
  component "CRUD Basique" as crud
  component "Stockage Fichiers" as storage
  component "Temps Réel" as realtime
}

package "Couche Métier (Spring Boot)" #Coral {
  component "Logique Complexe" as logic
  component "Orchestration" as orchestration
  component "Jobs Planifiés" as jobs
  component "Intégrations" as integrations
}

database "PostgreSQL Partagé" as db #LightGray

user --> frontend

frontend --> auth : OAuth2, JWT
frontend --> crud : Articles, Profils
frontend --> storage : Images, Fichiers
frontend --> realtime : Notifications

frontend --> logic : Calculs, Rapports
frontend --> orchestration : Workflows
logic --> integrations : Stripe, APIs
orchestration --> db
jobs --> db

crud --> db
auth --> db

note bottom of db
  **Une seule source de vérité**
  Partagée entre Supabase et Spring Boot
end note

note right of auth
  **Gratuit jusqu'à 50k users**
  Configuration en quelques clics
  OAuth2 multi-providers
end note

note right of logic
  **Activé seulement si nécessaire**
  Kotlin + Coroutines
  Transactions complexes
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

Konstruieren Sie nicht Spring Boot, wenn Sie es nicht benötigen.Starten Sie mit Supabase, fügen Sie Spring Boot hinzu, wenn die Komplexität dies 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 an denselben Daten ohne komplexe Synchronisation.

Orchestrierung der Flüsse

Flux 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üsselpunktEin einzelner Authentifizierungsprozess, ein einzelnes JWT, überall verwendbar.

Flux 2 : Orchestrierung 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 mitbringtZuverlässige Orchestrierung komplexer Prozesse, die mehrere Systeme umfassen, mit transaktionssicherer Garantie.

Flux 3 : Geplante Jobs und Synchronisationen

@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ässig geplante Jobs mit Zustandsverwaltung, automatischem Retry und garantierter Ausführung.

Entscheidungsmatrix

Wann sollte Supabase verwendet werden?

@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 der 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 (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

Urteil: Hybride 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-Kern)" #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-Kern)"
**Spring Boot unverzichtbar:**
• Kritische Transaktionen
• Komplexe Orchestrierung
• Mehrfache Integrationen
• Gesetzliche Konformität
• Synchronisations-Jobs
end note
@enduml

Urteil: Spring 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 operationelle Ü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 Supabase + Spring Boot Architektur ist kein Kompromiss, sie ist eineSynergie.

Die zu behaltenden 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 diese Architektur wählen?

✅ Diese Architektur ist ideal, wenn:

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

  • Sie erwarten ein Wachstum der fachlichen Komplexität

  • Sie wollen die Anfangskosten minimieren

  • Sie mögen PostgreSQL und wünschen sich eine einzige Quelle der Wahrheit.

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

  • Sie wollen Vendor Lock-in vollständig vermeiden

�❌ Diese Architektur ist NICHT geeignet, wenn :

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

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

  • Sie bevorzugen einen traditionellen Monolith

  • Sie benötigen .NET, Python oder eine andere Backend-Programmiersprache

Finale Übersicht

@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 Usern
Null Server-Konfiguration
    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\nSingle Source of Truth" 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

  • Keine Serverkonfiguration

Die Stärke von Spring Boot

  • Kotlin und Coroutines für eleganten asynchronen Code

  • Orchestrierung komplexer Geschäftsprozesse

  • zuverlässige geplante Jobs

  • Garantierte ACID-Transaktionen

  • Vollständiges Spring‑Ökosystem

💰 Die progressive Wirtschaft

  • 0€ zum Starten und Bestätigen

  • Kosten, die dem Wachstum folgen

  • Keine vorzeitige Überentwicklung

🎯 Die architektonische Flexibilität

  • Schrittweise Migration ohne Neugestaltung

  • Hinzufügen von Spring Boot nur bei Bedarf

  • Kein vollständiger Vendor Lock-in

  • erweiterbare Architektur

Um weiter zu gehen

Technische Ressourcen

Supabase-Dokumentation:

Spring Boot-Dokumentation :

Zusatzartikel :

  • Absicherung der APIs mit JWT

  • Optimierung der PostgreSQL-Leistung

  • progressive Migrationsmuster

  • Fehlerverwaltung in verteilter Architektur

Reale Anwendungsfälle

Diese hybride Architektur wird erfolgreich in:

  • SaaS B2BAuthentifizierung Supabase, Abrechnung Spring Boot

  • Marktplätze: Katalog Supabase, Transaktionen Spring Boot

  • Inhaltsplattformen: Artikel Supabase, analytics Spring Boot

  • Interne Werkzeuge: CRUD Supabase, Spring-Boot-Workflows

Startcheckliste

Phase 1 - Fundamente (Woche 1)

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

Phase 2 - MVP (Woche 2-3)

  • Hauptseiten implementieren - [ ] OAuth2-Authentifizierung integrieren - [ ] CRUD-Formulare erstellen - [ ] Speicher für Dateien konfigurieren - [ ] Auf GitHub Pages bereitstellen - [ ] Unter realen Bedingungen testen

Phase 3 - Entwicklung (nach Bedarf)

  • Anforderungen an komplexe Logik identifizieren - [ ] Spring Boot Projekt erstellen, falls notwendig - [ ] Supabase JWT-Validierung konfigurieren - [ ] Verbinden mit PostgreSQL Supabase - [ ] Komplexe Funktionen migrieren - [ ] Geplante Jobs implementieren - [ ] Spring Boot bereitstellen (Cloud Run, usw.)

Anti-Patterns zu vermeiden

�❌ Nicht tun:

  • Dupliziere die Daten zwischen Supabase und Spring Boot

  • Zwei separate PostgreSQL-Datenbanken erstellen

  • Codier die Authentifizierung selbst

  • Verwenden Sie Spring Boot für ein einfaches CRUD

  • Überarchitecturieren von Anfang an

  • Row-Level-Security von Supabase ignorieren

Eher :

  • Teile eine einzige PostgreSQL-Datenbank

  • Lassen Sie Supabase die Authentifizierung verwalten

  • Spring Boot nur wegen der Komplexität verwenden

  • Einfach beginnen, 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 Entwicklungen" #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 "Funktionen" {
    [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 Erweiterung ist unabhängig
Keine globale Überarbeitung erforderlich
end note
@enduml

Horizontale Skalierung

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

Supabase:

  • Skaliert automatisch auf bis zu Millionen von Operationen

  • Lesereplikate für Leseleistung

  • Wiederherstellung zum Zeitpunkt für Sicherheit

Spring Boot :

  • Mehrere Instanzen hinter Load Balancer

  • Stateless design erleichtert das horizontale Skalieren

  • Kubernetes für Orchestrierung falls notwendig

PostgreSQL:

  • Partitionierung für große Tabellen

  • Verbindungspooling (PgBouncer)

  • Sharding, wenn es wirklich notwendig ist (selten)

Architektonische Zeugnisse

Startup SaaS (50k Nutzer)

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

E-Learning-Plattform (10k Nutzer)

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

B2B-Marktplatz (3k Nutzer)

_ Spring Boot verwaltet die Transaktionen zwischen Käufern und Verkäufern (kritisch). Supabase verwaltet alles andere: Profile, Echtzeit‑Messaging, Dokumente. Dass sie die gleiche PostgreSQL‑Datenbank teilen, erspart uns jegliche komplexe Synchronisation. Die beste architektonische Entscheidung, die wir getroffen haben. _

Synthese: ein modernes architektonisches Paradigma

Die hybride Supabase + Spring Boot-Architektur repräsentiert ein neues Paradigma:die 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 Dienst existiert. Konzentrieren Sie sich darauf, was Ihre Anwendung unterscheidet.

Die Regel 80/20

In den meisten Anwendungen:

  • 80% der Operationensind Standard-CRUD → Supabase

  • 20% der Operationenbenötigen 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

die finale Schlussfolgerung

Die hybride Architektur ist kein technischer Kompromiss, sie ist einestrategische Entscheidung.

Es ermöglicht Ihnen:

  • ✅ Schnell mit einem funktionsfähigen MVP starten

  • ✅ Prüfe deinen Markt ohne hohe Investitionen

  • �✅ Sich schrittweise weiterentwickeln, wenn die Komplexität es erfordert

  • Kontrollieren Sie Ihre Kosten in jedem Schritt.

  • Das Beste aus jeder Technologie nutzen

  • ✅ Vermeide vorzeitiges Überengineering

  • ✅ Flexibilität für die Zukunft bewahren

Sie repräsentiert :

  • �🎯Pragmatismus: Jede Technologie, in der sie hervorragend ist

  • �🚀Geschwindigkeit: Time-to-market minimale

  • �💰WirtschaftWertausgerichtete Kosten

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

  • 🛡️RobustheitBewährte und zuverlässige Dienstleistungen

Ihr nächster Schritt

Falls Ihnen diese Architektur zusagt, hier ein Einstiegspunkt:

  1. Erstellen Sie ein Supabase-Konto(kostenlos)

  2. Definieren Sie Ihr minimales Datenschema

  3. Konfigurieren Sie die OAuth2-Authentifizierung

  4. Erstellen Sie Ihre erste JBake-Seite, die die API nutzt

  5. Stellen Sie auf GitHub Pages bereit

Du wirst einen funktionsfähigen MVP ineinige Tage.

Spring Boot kommt von selbst, wenn Sie es benötigen. Nicht vorher.

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 glauben, dass er anderen Entwicklern dabei 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