tiempo de lectura : 12 minutes

En lugar de elegir entre la simplicidad de Supabase y la potencia de Spring Boot, ¿por qué no combinar ambos? Descubre una arquitectura híbrida que aproveche lo mejor de cada tecnología.

toc

[]

El Falso Dilema de la Arquitectura Moderna

Cuando se construye una aplicación moderna con un frontend estático, a menudo nos encontramos frente a una opción binaria:

  • Apostarlo todo a una solución Backend-as-a-Service(Supabase, Firebase) - simple pero limitada

  • Construir un backend completo(Spring Boot, Node.js) - poderoso pero complejo

Esta elección es un falso dilema. La arquitectura híbrida propone una tercera vía: usar cada tecnología donde sobresale.

Visión Arquitectónica

La Arquitectura Tradicional: Monolítica

traditional architecture

En este enfoque, incluso las operaciones más simples (lectura de un artículo, creación de un comentario) deben transitar por tu backend. Pagas el costo de la complejidad desde el primer día.

La arquitectura BaaS : Todo delegado

baas architecture

Al contrario, delegar todo a un BaaS resulta atractivo al principio, pero muestra rápidamente sus límites cuando la lógica de negocio se complica.

La Arquitectura Híbrida: Separación de Responsabilidades

hybrid overview

La arquitectura híbrida separa claramente las responsabilidades según la complejidad y la naturaleza de las operaciones.

Principios de Diseño

Principio 1: Empezar simple, evolucionar inteligentemente

evolution phases

No construyas Spring Boot si no lo necesitas.Empiece con Supabase, añada Spring Boot cuando la complejidad lo justifica.

Principio 2 : Separación por naturaleza de la operación

operation types

Principio 3 : Una única fuente de verdad

single source truth

Al compartir la misma instancia de PostgreSQL, Supabase y Spring Boot trabajan en los mismos datos sin sincronización compleja.

Orquestación de los flujos

Flujo 1: Autenticación centralizada

auth orchestration

Punto claveUn solo proceso de autenticación, un solo JWT, utilizable en todas partes.

Flujo 2: Orquestación de un proceso de negocio complejo

business orchestration

Lo que Spring Boot aporta: Orquestación fiable de procesos complejos que involucran varios sistemas con garantía transaccional.

Flujo 3: Trabajos Programados y Sincronizaciones

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 4) ]

@startuml
skinparam backgroundColor #FEFEFE

participant "Scheduler
^^^^^
 Syntax Error? (Assumed diagram type: sequence)

@startuml
skinparam backgroundColor #FEFEFE

participant "Scheduler
(Spring Boot)" as scheduler
participant "Report Service" as report
participant "PostgreSQL" as db
participant "API externa" as api
participant "Servicio de correo electrónico" 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

Lo que Spring Boot aporta: Trabajos programados fiables con gestión de estado, reintento automático y ejecución garantizada.

Matriz de Decisión

¿Cuándo usar Supabase?

supabase decision

¿Cuándo usar Spring Boot?

springboot decision

Ejemplos de Arquitectura por Tipo de Proyecto

Blog / Portafolio

blog architecture

Veredicto: 100% Supabase es más que suficiente.

Aplicación SaaS

saas architecture

Veredicto: Arquitectura híbrida necesaria. Supabase para lo esencial, Spring Boot para la parte crítica (pagos, facturación).

e‑commerce

ecommerce architecture

VeredictoSpring Boot indispensable. Supabase solo para auth y catálogo.

Estrategia de Migración Progresiva

migration strategy

Costos y consideraciones operacionales

Estructura de Costos

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 7) ]

@startuml
skinparam backgroundColor #FEFEFE

package "Costos Mensuales Estimados" {

  rectangle "Fase MVP
(0-1000 usuarios)" #LightGreen {
^^^^^
 Syntax Error? (Assumed diagram type: activity)

@startuml
skinparam backgroundColor #FEFEFE

package "Costos Mensuales Estimados" {

  rectangle "Fase MVP
(0-1000 usuarios)" #LightGreen {
    [JBake (GitHub Pages): 0€]
    [Supabase: 0€]
    [Spring Boot: N/A]
    note bottom: **Total: 0€/mois**
  }

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

  rectangle "Escala de fase
(10k-100k usuarios)" #LightCoral {
    [JBake (Netlify Pro): 19€]
    [Supabase Pro: 25€]
    [Spring Boot (instances multiples): 100-300€]
    [Redis Cache: 20-50€]
    [Monitoring: 20€]
    note bottom: **Total: 184-414€/mois**
  }
}

note right of "Escala de fase
(10k-100k usuarios)"
  À ce stade, les revenus
  justifient largement les coûts
end note
@enduml

Responsabilidades Operativas

operational responsibilities

Conclusión: El Equilibrio Perfecto

La arquitectura híbrida Supabase + Spring Boot no es un compromiso, es unasinergia.

Los principios a retener

key principles

¿Cuándo elegir esta arquitectura?

✅ Esta arquitectura es ideal si:

  • Quieres arrancar rápidamente (MVP en días, no en meses)

  • Anticipas un crecimiento de la complejidad del negocio

  • Quieres minimizar los costos iniciales

  • Te gusta PostgreSQL y quieres una única fuente de verdad

  • Ustedes aprecian Kotlin y las Corrutinas para el código de negocio

  • Quieres evitar el vendor lock-in total

�❌ Esta arquitectura NO es adecuada si :

  • Tu proyecto es simple y lo seguirá siendo (blog personal → 100% Supabase es suficiente)

  • Ya tienes una stack backend establecida que dominas

  • Prefiere un monolito tradicional

  • Necesitas .NET, Python, u otro lenguaje backend

Visión General Final

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 35) ]

@startuml
skinparam backgroundColor #FEFEFE

package "Arquitectura Híbrida Completa" {

  actor "Usuarios" as users

  rectangle "Frontend (Estático)" #SkyBlue {
    [JBake / GitHub Pages]
    note right: Gratuit, CDN global
  }

  rectangle "Backend simple (Supabase)" #LightGreen {
    [Auth OAuth2]
    [CRUD APIs]
    [Storage]
    [Realtime]
    note right
      Gratuit jusqu'à 50k users
      Zéro configuration serveur
    end note
  }

  rectangle "Backend de negocio (Spring Boot)" #Coral {
    [Orchestration]
    [Jobs Planifiés]
    [Intégrations]
    [Transactions]
    note right
      Activé uniquement
      si nécessaire
    end note
  }

  database "PostgreSQL
^^^^^
 Syntax Error? (Assumed diagram type: component)

@startuml
skinparam backgroundColor #FEFEFE

package "Arquitectura Híbrida Completa" {

  actor "Usuarios" as users

  rectangle "Frontend (Estático)" #SkyBlue {
    [JBake / GitHub Pages]
    note right: Gratuit, CDN global
  }

  rectangle "Backend simple (Supabase)" #LightGreen {
    [Auth OAuth2]
    [CRUD APIs]
    [Storage]
    [Realtime]
    note right
      Gratuit jusqu'à 50k users
      Zéro configuration serveur
    end note
  }

  rectangle "Backend de negocio (Spring Boot)" #Coral {
    [Orchestration]
    [Jobs Planifiés]
    [Intégrations]
    [Transactions]
    note right
      Activé uniquement
      si nécessaire
    end note
  }

  database "PostgreSQL
Fuente Única de Verdad" 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
  **Une seule base, deux consommateurs**
  • Supabase pour le simple
  • Spring Boot pour le complexe
  • Aucune synchronisation requise
end note

@enduml

Lo mejor de los dos mundos

Esta arquitectura le da :

🚀 La velocidad de Supabase

  • Inicio en horas, no en semanas

  • Autenticación OAuth2 en unos pocos clics

  • APIs REST generados automáticamente

  • Cero configuración de servidor

💪 La potencia de Spring Boot

  • Kotlin y Coroutines para código asíncrono elegante

  • Orquestación de procesos de negocio complejos

  • Trabajos programados confiables

  • Transacciones ACID garantizadas

  • Ecosistema Spring completo

💰 La Economía Progresiva

  • 0€ para empezar y validar

  • Costos que siguen el crecimiento

  • No hay sobreingeniería prematura

🎯 La Flexibilidad Arquitectónica

  • Migración progresiva sin rediseño

  • Añadir Spring Boot solo si es necesario

  • Sin vendor lock-in total

  • Arquitectura evolutiva

Para ir más lejos

Recursos Técnicos

Documentación Supabase :

Documentación Spring Boot :

Artículos Complementarios :

  • Seguridad de las APIs con JWT

  • Optimización del rendimiento de PostgreSQL

  • Patrones de migración progresiva

  • Manejo de errores en arquitectura distribuida

Casos de uso reales

Esta arquitectura híbrida se utiliza con éxito en :

  • SaaS B2BAutenticación Supabase, facturación Spring Boot

  • marketplaces: Catálogo Supabase, transactions Spring Boot

  • Plataformas de contenido: Artículos Supabase, analítica Spring Boot

  • Herramientas internasCRUD Supabase, workflows Spring Boot

Checklist de Arranque

Fase 1 - Fundamentos (Semana 1)

  • Crear cuenta Supabase - [ ] Configurar proyecto PostgreSQL - [ ] Activar Autenticación (Google, GitHub) - [ ] Definir esquema inicial - [ ] Configurar la seguridad a nivel de fila - [ ] Probar APIs desde JBake

Fase 2 - MVP (Semana 2-3)

  • Implementar páginas principales - [ ] Integrar autenticación OAuth2 - [ ] Crear formularios CRUD - [ ] Configurar Storage para archivos - [ ] Desplegar en GitHub Pages - [ ] Probar en condiciones reales

Phase 3 - Evolución (Según necesidades)

  • Identificar necesidades de lógica compleja - [ ] Crear proyecto Spring Boot si es necesario - [ ] Configurar validación JWT Supabase - [ ] Conectar a PostgreSQL Supabase - [ ] Migrar funcionalidades complejas - [ ] Implementar trabajos programados - [ ] Desplegar Spring Boot (Cloud Run, etc.)

Antipatrones a evitar

No hacer:

  • Duplicar los datos entre Supabase y Spring Boot

  • Crear dos bases de datos PostgreSQL separadas

  • Codificar la autenticación usted mismo

  • Usar Spring Boot para un CRUD sencillo

  • sobrediseñar desde el principio

  • Ignorar Row Level Security de Supabase

✅ Hacer mejor :

  • Compartir una única base de datos PostgreSQL

  • Dejar que Supabase gestione la autenticación

  • Utilizar Spring Boot solo para la complejidad

  • Empezar simple, evolucionar gradualmente

  • Explotar las fortalezas de cada tecnología

  • Asegurar con RLS a nivel de base de datos

Perspectivas de Evolución

Adición de Nuevas Capacidades

future capabilities

Escalado Horizontal

Cuando su aplicación crece, la arquitectura híbrida escala naturalmente :

Supabase:

  • escala automáticamente hasta millones de operaciones

  • Réplicas de lectura para rendimiento de lectura

  • Point-in-time recovery para seguridad

Spring Boot :

  • Múltiples instancias detrás de balanceador de carga

  • Diseño sin estado facilita el escalado horizontal

  • Kubernetes para orquestación si es necesario

PostgreSQL :

  • Particionamiento para tablas voluminosas

  • Pooling de conexiones (PgBouncer)

  • Sharding si realmente necesario (raro)

Testimonios arquitectónicos

Startup SaaS (50k usuarios)

_ Empezamos con Supabase al 100%. Con 5k usuarios, agregamos Spring Boot solo para la facturación de Stripe y los informes mensuales. Un año después, el 80% de nuestras operaciones sigue pasando por Supabase. Spring Boot gestiona solo la parte crítica. Esta separación nos permitió escalar sin rediseño. _

Plataforma E-learning (10k usuarios)

_ La autenticación OAuth2 de Supabase nos ha ahorrado 3 semanas de desarrollo. Las APIs autogeneradas gestionan todo nuestro catálogo de cursos. Spring Boot solo se utiliza para los certificados PDF y los correos de progreso. Arquitectura simple, mantenible y escalable. _

Marketplace B2B (3k usuarios)

_ Spring Boot gestiona las transacciones entre compradores y vendedores (crítica). Supabase gestiona todo lo demás: perfiles, mensajería en tiempo real, documentos. El hecho de que compartan la misma base de datos PostgreSQL nos evita cualquier sincronización compleja. Mejor elección arquitectónica que hayamos hecho. _

Síntesis : Un Paradigma Arquitectónico Moderno

La arquitectura híbrida Supabase + Spring Boot representa un nuevo paradigma:la especialización arquitectónica.

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 20) ]

@startuml
skinparam backgroundColor #FEFEFE

rectangle "paradigma antiguo" #LightCoral {
  card "Todo en el Backend" {
    [Auth]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [Storage]
    [Realtime]
  }
  note bottom
    Complexité maximale
    dès le jour 1
  end note
}

rectangle "Nuevo Paradigma" #LightGreen {
  card "Supabase
^^^^^
 Syntax Error? (Assumed diagram type: component)

@startuml
skinparam backgroundColor #FEFEFE

rectangle "paradigma antiguo" #LightCoral {
  card "Todo en el Backend" {
    [Auth]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [Storage]
    [Realtime]
  }
  note bottom
    Complexité maximale
    dès le jour 1
  end note
}

rectangle "Nuevo Paradigma" #LightGreen {
  card "Supabase
(Comodidad)" {
    [Auth]
    [CRUD Simple]
    [Storage]
    [Realtime]
  }

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

  note bottom
    Complexité progressive
    ajoutée seulement si nécessaire
  end note
}

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

@enduml

El principio fundamental :No construyas lo que ya existe como servicio. Concéntrate en lo que diferencia tu aplicación.

La regla del 80/20

En la mayoría de las aplicaciones :

  • 80% de las operacionesson CRUD estándar → Supabase

  • 20% de las operacionesnecesitan de la lógica de negocio → Spring Boot

Esta regla natural justifica la arquitectura híbrida.

8020 rule

Conclusión Final

La arquitectura híbrida no es un compromiso técnico, es unadecisión estratégica.

Le permite:

  • �✅ Iniciar rápidamente con un MVP funcional

  • ✅ Validar su mercado sin una inversión pesada

  • �✅ Evolucionar progresivamente cuando la complejidad lo exija

  • �✅ Controlar tus costos en cada paso

  • ✅ Aprovechar lo mejor de cada tecnología

  • �✅ Evitar la sobre-ingeniería prematura

  • �✅ Conservar la flexibilidad para el futuro

Ella representa :

  • 🎯Pragmatismo: Cada tecnología en la que destaca

  • 🚀velocidad: Tiempo de comercialización mínimo

  • 💰EconomíaCostos alineados con el valor

  • 🔮EscalabilidadArquitectura que crece contigo

  • �🛡️robustezServicios probados y confiables

Tu próximo paso

Si esta arquitectura te habla, aquí tienes por dónde comenzar:

  1. Crear una cuenta Supabase(gratuito)

  2. Define tu esquema de datos mínimo

  3. Configura la autenticación OAuth2

  4. Cree su primera página JBake que consume la API

  5. Despliega en GitHub Pages

Tendrás un MVP funcional enunos días.

Spring Boot llegará naturalmente cuando lo necesites. No antes.


La arquitectura híbrida es el arte de construir exactamente lo que se necesita, cuando se necesita.

Buen desarrollo ! 🚀


Comparte este artículo si crees que puede ayudar a otros desarrolladores a tomar las decisiones arquitectónicas correctas.

Articles connexes