Arquitetura Híbrida : O Melhor dos Dois Mundos com Supabase e Spring Boot

Publicado em 14 January 2026

tempo de leitura : 12 minutes

Em vez de escolher entre a simplicidade do Supabase e a potência do Spring Boot, por que não combinar os dois? Descubra uma arquitetura híbrida que aproveita o melhor de cada tecnologia.

O Falso Dilema da Arquitetura Moderna

Ao construir uma aplicação moderna com um frontend estático, frequentemente nos deparamos com uma escolha binária:

  • Apostar tudo numa solução Backend-as-a-Service(Supabase, Firebase) - simples mas limitada

  • Construir um backend completo(Spring Boot, Node.js) - poderoso mas complexo

Esta escolha é um falso dilema. A arquitetura híbrida propõe um terceiro caminho: utilizar cada tecnologia onde ela se destaca

Visão Arquitetônica

A Arquitetura Tradicional : Monolítica

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Arquitetura Tradicional" {
  actor Utilisateur as user
  component "frontend" as frontend #LightBlue
  component "Backend monolítico" as backend #LightCoral {
    [Authentification]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [APIs Tierces]
  }
  database "banco de dados" as db #LightGray

  user --> frontend
  frontend --> backend : Todas as solicitações
  backend --> db
}

note right of backend
Tudo passa pelo backend
Mesmo as operações simples
⚠️ Ponto único de congestão
⚠️ Complexidade desde o início
⚠️ Acoplamento forte
end note
@enduml

Nessa abordagem, até mesmo as operações mais simples (leitura de um artigo, criação de um comentário) precisam passar pelo seu backend. Você paga o custo da complexidade desde o primeiro dia.

A Arquitetura BaaS: Todo Delegado

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

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

  user --> frontend
  frontend --> baas : Todas as operações
}

note right of baas
Desenvolvimento rápido
Sem servidor a gerir
⚠️ Limitado para lógica complexa
⚠️ Bloqueio de fornecedor
⚠️ Edge Functions restritas
end note
@enduml

Do contrário, delegar tudo a um BaaS é sedutor no início, mas mostra rapidamente seus limites assim que a lógica de negócios se complexifica.

A Arquitetura Híbrida : Separação das Responsabilidades

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

actor Utilisateur as user #LightBlue

package "Camada Frontend" {
  component "Site Estático JBake" as frontend #SkyBlue
}

package "Camada Simples (Supabase)" #LightGreen {
  component "Autenticação" as auth
  component "CRUD Básico" as crud
  component "Armazenamento de Arquivos" as storage
  component "Tempo Real" as realtime
}

package "Camada de Negócio (Spring Boot)" #Coral {
  component "Lógica Complexa" as logic
  component "Orquestração" as orchestration
  component "Jobs Agendados" as jobs
  component "Integrações" as integrations
}

database "PostgreSQL Compartilhado" as db #LightGray

user --> frontend

frontend --> auth : OAuth2, JWT
frontend --> crud : Artigos, Perfis
frontend --> storage : Imagens, arquivos
frontend --> realtime : Notificações

frontend --> logic : Cálculos, Relatórios
frontend --> orchestration : Fluxos de trabalho
logic --> integrations : Stripe, APIs
orchestration --> db
jobs --> db

crud --> db
auth --> db

note bottom of db
Uma única fonte de verdade
Compartilhada entre Supabase e Spring Boot
end note

note right of auth
Gratuit até 50k usuários
Configuração em poucos cliques
OAuth2 multi-fornecedores
end note

note right of logic
Ativado apenas se necessário
Kotlin + Corrotinas
Transações complexas
end note
@enduml

A arquitetura híbrida separa claramente as responsabilidades de acordo com a complexidade e a natureza das operações.

Princípios de Design

Princípio 1 : Começar Simples, Evoluir Inteligentemente

@startuml
skinparam backgroundColor #FEFEFE

rectangle "Fase 1 : MVP" #LightGreen {
  component "JBake + Supabase" as mvp
  note right
✓ Desenvolvimento em dias
✓ Custo : 0€
✓ Validação de conceito
  end note
}

rectangle "**Fase 2 : Crescimento**" #LightYellow {
  component "JBake + Supabase\n+ Spring Boot (opcional)" as growth
  note right
✓ Lógica de negócio surge
✓ Primeiros trabalhos planejados
✓ Integrações de terceiros
es
✓ Primeiros trabalhos planejados
✓ Integrações de terceiros
es
  end note
}

rectangle "**Fase 3 : Escala**" #LightCoral {
  component "Arquitetura Completa" as scale
  note right
✓ Orquestração complexa
✓ Performances otimizadas
✓ Cache distribuído
  end note
}

mvp -down-> growth : Quando a complexidade\njustifica
growth -down-> scale : Otimização\ncontinuar
@enduml

Não construa o Spring Boot se você não precisar.Comece com o Supabase, adicione o Spring Boot quando a complexidade justificar.

Princípio 2: Separação por natureza da operação

@startmindmap
skinparam backgroundColor #FEFEFE
* Operações\nAplicativos

left side

** Operações Simples\n(Supabase)
***_ CRUD Padrão
****_ Leitura
****_ Criação
****_ Atualização
****_ Supressão
***_ Autenticação
****_ Login/Logout
****_ OAuth2
****_Gerenciamento de sessão
***_ Armazenamento
****_ Carregar arquivos
****_ CDN automático
***_ Tempo Real
****_ WebSocket
****_ Notificações

right side

** Operações Complexas\n(Spring Boot)
***_ Lógica de negócio
****_ Cálculos complexos
****_ Regras de negócio
****_ Validações avançadas
***_ Orquestração
****_ Multisserviços
****_ Transações distribuídas
****_ padrões de saga
***_ Tarefas Agendadas
****_ Relatórios periódicos
****_ Sincronizações
****_ Limpezas
***_ Integrações
****_ Pagamentos (Stripe)
****_ APIs terços
****_Serviços ML/AI

@endmindmap

Princípio 3 : Uma Única Fonte de Verdade

@startuml
skinparam backgroundColor #FEFEFE

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

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

  package "Esquema: negócio (Spring Boot)" #Coral {
    [orders]
    [payments]
    [reports]
  }
}

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

supabase -down-> users : Gerencia
supabase -down-> sessions : Gerencia
supabase -down-> articles : accede
supabase -down-> comments : Acesso
supabase -down-> profiles : Acesso

spring -down-> articles : Acesse
spring -down-> profiles : Acesse
spring -down-> orders : Gerencia
spring -down-> payments : Gere
spring -down-> reports : Gerencia

note right of db
**Vantagens :**
• Sem sincronização complexa
• JOINs possíveis entre tabelas
• Consistência garantida
• Migrações unificadas
end note
@enduml

Ao compartilhar a mesma instância PostgreSQL, o Supabase e o Spring Boot trabalham nos mesmos dados sem sincronização complexa.

Orquestração dos Fluxos

Flux 1 : Autenticação Centralizada

@startuml
skinparam backgroundColor #FEFEFE
autonumber

actor "" as user
participant "JBake" as jbake
participant "Supabase Autenticação" as auth
participant "Spring Boot" as spring
database "PostgreSQL" as db

== Authentification ==
user -> jbake : Clique "Entrar"
jbake -> auth : Redirecionar OAuth2 (Google/GitHub)
auth -> user : Tela de consentimento
user -> auth : autoriza
auth -> auth : Gere JWT
auth -> jbake : Retorna JWT + Refresh Token
jbake -> jbake : Armazena tokens (sessionStorage)

== Accès aux Ressources ==
group Opération Simple (CRUD)
  user -> jbake : Crie um artigo
  jbake -> db : POST com JWT
  note right: Supabase Row Level Security\nverifica o JWT automaticamente
  db -> jbake : Artigo criado
end

group Opération Complexe (Métier)
  user -> jbake : Gere um relatório
  jbake -> spring : POST /api/reports\ncom JWT
  spring -> spring : Valida JWT Supabase
  spring -> spring : Reivindicações do extrato (user_id, roles)
  spring -> db : Consultas complexas
  spring -> jbake : Relatório gerado
end

note over auth, spring
O JWT é universal
Válido por Supabase e Spring Boot
Sem autenticação double
end note
@enduml

ponto-chave: Um único processo de autenticação, um único JWT, utilizável em qualquer lugar.

Flux 2 : Orquestração de um Processo de Negócio Complexo

@startuml
skinparam backgroundColor #FEFEFE
autonumber

actor "Cliente" as user
participant "JBake" as jbake
participant "Spring Boot" as spring
participant "Supabase BD" as supadb
participant "Stripe API" as stripe
participant "Serviço de Inventário" as inventory
participant "Serviço de E-mail" as email
database "PostgreSQL" as db

user -> jbake : Faça o pedido
jbake -> spring : POST /api/orders/create

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

par Vérifications Parallèles
  spring -> inventory : Verificar estoque
  inventory -> spring : Estoque OK
else
  spring -> db : Verificar perfil do cliente
  db -> spring : Cliente verificado
end

spring -> stripe : Criar Payment Intent
stripe -> spring : Intent criado (ID: pi_xxx)

spring -> db : Criar Order (status: PENDING)
db -> spring : Ordem criada

spring -> stripe : Confirmar pagamento
stripe -> spring : Pagamento confirmado

spring -> db : Atualizar Pedido (status: PAID)
spring -> inventory : Decrementar estoque
spring -> db : COMMIT TRANSACTION

par Notifications Asynchrones
  spring -> email : Confirmação de e-mail
else
  spring -> supadb : Inserir notificação
  note right: Notificação em tempo real\nvia Supabase Realtime
end

spring -> jbake : Pedido confirmado
jbake -> user : Exibe confirmação

note over spring
Responsabilidades do Spring Boot :
• Transação ACID
• Orquestração multi‑services
• Rollback automático em caso de erro
• Gestão dos casos limites
end note
@enduml

O que o Spring Boot trazOrquestração fiável de processos complexos envolvendo vários sistemas com garantia transacional.

Flux 3 : Trabalhos Agendados e Sincronizações

@startuml
skinparam backgroundColor #FEFEFE

participant "Scheduler\n(Spring Boot)" as scheduler
participant "Serviço de Relatório" as report
participant "PostgreSQL" as db
participant "Externo API" as api
participant "Serviço de E-mail" as email
participant "Supabase Armazenamento" as storage

== Job Quotidien : 2h00
activate scheduler
scheduler -> report : Disparar geração relatório

activate report
report -> db : Recupera dados\ndas últimas 24h
db -> report : Dataset

report -> report : Cálculos & Agregações
report -> report : Geração PDF

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

report -> email : Envie aos administradores  \ncom o link PDF
deactivate report

== Job Hebdomadaire : Domingo 3h00 ==
scheduler -> report : Sincronização externa

activate report
report -> api : Buscar dados externos
api -> report : Novos dados

report -> db : Atualização de tabelas
report -> db : Limpeza de dados obsoletos
deactivate report

== Job Mensuel : 1º do mês ==
scheduler -> report : Faturação

activate report
report -> db : Lista de clientes ativos
report -> report : Cálculo de valores
report -> api : Geração de faturas (Stripe)
report -> email : envio de faturas
deactivate report

deactivate scheduler

note right of scheduler
Impossível apenas com Supabase
Edge Functions não adaptadas
para jobs longos e recorrentes
end note
@enduml

O que o Spring Boot traz: Trabalhos agendados confiáveis com gerenciamento de estado, retry automático e execução garantida.

Matriz de Decisão

Quando usar Supabase?

@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

Quando usar o Spring Boot?

@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

Exemplos de Arquitetura por Tipo de Projeto

Blog / Portfólio

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Blog Pessoal - 95% Supabase" {
  component "JBake" as jbake #SkyBlue

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

  package "Spring Boot (Opcional)" #LightCoral {
    [Newsletter Mensuelle]
    note bottom: Apenas tarefa agendada
  }

  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 (Opcional)"
**Spring Boot não obrigatório**
Newsletter pode ser gerida
por um serviço terceirizado (Mailchimp)
end note
@enduml

Veredicto: 100% Supabase é mais que suficiente.

Aplicação SaaS

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Aplicação SaaS - Arquitetura Híbrida" {
  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 "Serviços Externos" {
    [Stripe API]
    [SendGrid Email]
  }

  database "PostgreSQL Compartilhado" 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"
**Necessário para:**
• Gestão de assinaturas
• Faturação recorrente
• Quotas dinâmicas
• Analytics complexos
• Webhooks fiáveis
end note
@enduml

Veredito: Arquitetura híbrida necessária. Supabase para o essencial, Spring Boot para a parte crítica (pagamentos, faturamento).

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 (Núcleo do Negócio)" #Coral {
    [Gestion Commandes]
    [Paiements Stripe]
    [Gestion Stock]
    [Calcul Frais Port]
    [Génération Factures]
    [Synchronisation ERP]
    [Emails Transactionnels]
  }

  cloud "Integrações" {
    [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 (Núcleo do Negócio)"
**Spring Boot indispensável :**
• Transações críticas
• Orquestração complexa
• Integrações múltiplas
• Conformidade legal
• Jobs de sincronização
end note
@enduml

veredicto: Spring Boot indispensável. Supabase para autenticação e catálogo apenas.

Estratégia de Migração Progressiva

@startuml
skinparam backgroundColor #FEFEFE

|Semaine 1-2|
start
:Criar projeto Supabase;
:Configure Auth (Google, GitHub);
:Definir esquema PostgreSQL inicial;
:Implementar o CRUD básico em JBake;
:Implementar MVP em GitHub Páginas;
note right
**Entregável :** Aplicação funcional
**Custo :** 0€
**Tempo :** 1-2 semanas
end note

|Semaine 3-4|
:Observar utilização real;
:Limitações do identificador;

|Décision|
if (Logique complexe\némerge ?) then (non)
  |Supabase|
  :Continuar apenas com Supabase;
  :Adicionar Edge Functions se necessário;
  stop
else (oui)
  |Spring Boot|
  :Criar projeto Spring Boot;
  :Configurar validação JWT Supabase;
  :Migrar lógica complexa para Spring Boot;
  note right
Migração seletiva
Apenas o que é complexo
  end note
endif

|Semaines suivantes|
:Implantar Spring Boot (Cloud Run, EC2);
:Conectar a PostgreSQL Supabase;
:Implementar os primeiros trabalhos agendados;
:Integrar APIs terceiros;

stop

note right
Arquitetura híbrida final
Supabase + Spring Boot
em perfeita harmonia
end note
@enduml

Custos e Considerações Operacionais

Estrutura dos Custos

@startuml
skinparam backgroundColor #FEFEFE

package "Custos Mensais Estimados" {

  rectangle "Fase MVP\n(0-1000 usuários)" #LightGreen {
    [JBake (GitHub Pages): 0€]
    [Supabase: 0€]
    [Spring Boot: N/A]
    note bottom: **Total: 0€/mês**
  }

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

  rectangle "Fase de Escala\n(10k-100k usuários)" #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€/mês**
  }
}

note right of "Fase de Escala\n(10k-100k usuários)"
Neste estágio, as receitas
justificam amplamente os custos
end note
@enduml

Responsabilidades Operacionais

@startuml
skinparam backgroundColor #FEFEFE

package "Quem Gere O Quê?" {

  rectangle "Gerido pelo Supabase (0 esforço)" #LightGreen {
    [Authentification]
    [Base de données]
    [Backups automatiques]
    [Scaling automatique]
    [Monitoring DB]
    [Sécurité DB]
  }

  rectangle "Gerido pelo GitHub (0 esforço)" #SkyBlue {
    [Hébergement site statique]
    [HTTPS/SSL]
    [CDN global]
    [Déploiement automatique]
  }

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

note bottom of "A Gerir (Spring Boot)"
**Minimizável com:**
• Cloud Run (serverless)
• Kubernetes (se necessário)
• Serviços gerenciados (RDS, etc.)
end note
@enduml

Conclusão: O Equilíbrio Perfeito

A arquitetura híbrida Supabase + Spring Boot não é um compromisso, é umasinergia.

Os princípios a reter

@startmindmap
skinparam backgroundColor #FEFEFE
* Arquitetura\nHíbrido

** Começar Simples
***_ MVP com Supabase
***_ 0€ de custo inicial
***_ Validação rápida

** Evoluir Inteligentemente
***_ Adicionar Spring Boot\nse necessário
***Migração progressiva
***_ Sem reformulação total

** Aproveitar as forças
***_ Supabase: Simplicité
***_ Spring Boot: Potência
***_ PostgreSQL: Fonte única

** Minimizar a complexidade
***_Sem sincronização
***_Não há duplicação
***_ Arquitetura clara

** Otimizar os Custos
***_ gratuito no início
***_ Escalonamento progressivo
***_ ROI evidente

@endmindmap

Quando escolher esta arquitetura?

✅ Esta arquitetura é ideal se :

  • Você quer começar rapidamente (MVP em dias, não em meses)

  • Você antecipa um crescimento da complexidade de negócio

  • Você deseja minimizar os custos iniciais

  • Você gosta de PostgreSQL e quer uma fonte de verdade única

  • Você aprecia Kotlin e as Coroutines para o código de negócio

  • Você quer evitar o vendor lock-in total

❌ Esta arquitetura NÃO é adequada se:

  • Seu projeto é simples e permanecerá assim (blog pessoal → 100% Supabase basta)

  • Você já tem uma stack de backend estabelecida que você domina.

  • Você prefere um monolito tradicional

  • Você precisa de .NET, Python, ou outra linguagem do lado do backend

Visão Geral Final

@startuml
skinparam backgroundColor #FEFEFE

package "Arquitetura Híbrida Completa" {

  actor "Usuários" as users

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

  rectangle "Backend Simples (Supabase)" #LightGreen {
    [Auth OAuth2]
    [CRUD APIs]
    [Storage]
    [Realtime]
    note right
Gratuito até 50k users
Zero configuração de servidor
    end note
  }

  rectangle "Backend de Negócio (Spring Boot)" #Coral {
    [Orchestration]
    [Jobs Planifiés]
    [Intégrations]
    [Transactions]
    note right
Ativado apenas
se necessário
    end note
  }

  database "PostgreSQL\nFonte Única da Verdade" 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
**Uma única base, dois consumidores**
• Supabase para o simples
• Spring Boot para o complexo
• Nenhuma sincronização necessária
end note

@enduml

O Melhor dos Dois Mundos

Esta arquitetura lhe dá:

🚀 A Velocidade do Supabase

  • Início em horas, não em semanas

  • Autenticação OAuth2 em poucos cliques

  • APIs REST geradas automaticamente

  • Zero configuração de servidor

�💪 O Poder do Spring Boot

  • Kotlin e Coroutines para código assíncrono elegante

  • Orquestração de processos de negócio complexos

  • Jobs agendados confiáveis

  • Transações ACID garantidas

  • Ecossistema Spring completo

💰 A Economia Progressiva

  • 0€ para iniciar e validar

  • Custos que acompanham o crescimento

  • Não há sobre-engenharia prematura

�🎯 A Flexibilidade Arquitetônica

  • Migração progressiva sem reformulação

  • Adicionar Spring Boot apenas se necessário

  • Sem bloqueio total de fornecedor

  • arquitetura evolutiva

Para Ir Mais Longe

Recursos Técnicos

Documentação Supabase :

Documentação Spring Boot:

Artigos Complementares:

  • Proteção das APIs com JWT

  • Otimização de desempenho PostgreSQL

  • Padrões de migração progressiva

  • Gestão de erros em arquitetura distribuída

Casos de Uso Reais

Esta arquitetura híbrida é utilizada com sucesso em :

  • SaaS B2B: Autenticação Supabase, faturamento Spring Boot

  • Mercados: Catálogo Supabase, transações Spring Boot

  • Plataformas de conteúdo: Artigos Supabase, analítica Spring Boot

  • Ferramentas internas: CRUD Supabase, fluxos de trabalho Spring Boot

Checklist de partida

Fase 1 - Fundações (Semana 1)

  • Criar conta Supabase - [ ] Configurar projeto PostgreSQL - [ ] Ativar Auth (Google, GitHub) - [ ] Definir esquema inicial - [ ] Configurar Row Level Security - [ ] Testar APIs desde JBake

Fase 2 - MVP (Semana 2-3)

  • Implementar páginas principais - [ ] Integrar autenticação OAuth2 - [ ] Criar formulários CRUD - [ ] Configurar Storage para arquivos - [ ] Implantar no GitHub Pages - [ ] Testar em condições reais

Fase 3 - Evolução (Conforme as necessidades)

  • Identificar necessidades de lógica complexa - [ ] Criar projeto Spring Boot se necessário - [ ] Configurar validação JWT Supabase - [ ] Conectar ao PostgreSQL Supabase - [ ] Migrar funcionalidades complexas - [ ] Implementar trabalhos agendados - [ ] Implementar Spring Boot (Cloud Run, etc.)

Anti-Padrões a Evitar

�❌ Não fazer:

  • Duplicar os dados entre Supabase e Spring Boot

  • Criar duas bases PostgreSQL separadas

  • Codifique a autenticação você mesmo

  • Utilizar Spring Boot para CRUD simples

  • Sobre-arquitetar desde o início

  • Ignorar a Segurança de Nível de Linha do Supabase

Fazer de preferência :

  • Compartilhar um único banco de dados PostgreSQL

  • Deixe o Supabase gerenciar a autenticação

  • Usar o Spring Boot apenas pela complexidade

  • Começar simples, evoluir gradualmente

  • Aproveitar as forças de cada tecnologia

  • Proteger com RLS no nível da base de dados

Perspectivas de Evolução

Adição de Novas Capacidades

@startuml
skinparam backgroundColor #FEFEFE

rectangle "Arquitetura Atual" #SkyBlue {
  [JBake]
  [Supabase]
  [Spring Boot]
}

rectangle "Evoluções Possíveis" #LightYellow {

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

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

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

  package "Funcionalidades" {
    [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
**Arquitetura extensível**
Cada adição é independente
Não é necessária uma reformulação global
end note
@enduml

Escalonamento Horizontal

Quando seu aplicativo cresce, a arquitetura híbrida escala naturalmente:

Supabase :

  • Escala automaticamente até milhões de operações

  • Réplicas de leitura para desempenho de leitura

  • Point-in-time recovery para segurança

Spring Boot:

  • Múltiplas instâncias atrás do load balancer

  • O design stateless facilita o escalonamento horizontal

  • Kubernetes para orquestração se necessário

PostgreSQL :

  • Particionamento para tabelas volumosas

  • Pooling de conexões (PgBouncer)

  • Sharding é realmente necessário (raro)

Testemunhos Arquitetônicos

Startup SaaS (50k utilizadores)

_ Começamos 100% Supabase. Aos 5k usuários, adicionamos Spring Boot apenas para a cobrança Stripe e os relatórios mensais. Um ano depois, 80% das nossas operações ainda passam pelo Supabase. Spring Boot cuida apenas da parte crítica. Essa separação nos permitiu escalar sem reformulação. _

Plataforma E-learning (10k usuários)

_ A autenticação OAuth2 da Supabase nos fez ganhar 3 semanas de desenvolvimento. As APIs auto-geradas gerenciam todo o nosso catálogo de cursos. Spring Boot serve apenas para os certificados PDF e os e-mails de progresso. Arquitetura simples, manutenível, escalável. _

Marketplace B2B (3k utilizadores)

_ Spring Boot gere as transações entre compradores e vendedores (crítico). Supabase gere o resto: perfis, mensagens em tempo real, documentos. O fato de compartilharem o mesmo banco de dados PostgreSQL nos evita qualquer sincronização complexa. Melhor escolha arquitetônica que já fizemos. _

Síntese: Um Paradigma Arquitetônico Moderno

A arquitetura híbrida Supabase + Spring Boot representa um novo paradigma:especialização arquitetônica.

@startuml
skinparam backgroundColor #FEFEFE

rectangle "Antigo Paradigma" #LightCoral {
  card "Tudo no Backend" {
    [Auth]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [Storage]
    [Realtime]
  }
  note bottom
Complexidade máxima
desde o dia 1
  end note
}

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

  card "Spring Boot\n(Diferenciação)" {
    [Logique Métier]
    [Jobs]
    [Intégrations]
  }

  note bottom
Complexidade progressiva
adicionada apenas se necessário
  end note
}

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

@enduml

O princípio fundamental:Não construa o que já existe como serviço. Concentre-se no que diferencia sua aplicação.

A Regra dos 80/20

Na maioria das aplicações :

  • 80% das operaçõessão CRUD padrão → Supabase

  • 20% das operaçõesnecessitam de lógica de negócio → Spring Boot

Esta regra natural justifica a arquitetura híbrida.

@startuml
skinparam backgroundColor #FEFEFE

package "Distribuição das Operações" {

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

    note bottom: Gerido por Supabase
  }

  rectangle "20% - Lógica de Negócio" #Coral {
    [Calculs complexes]
    [Workflows multi-étapes]
    [Transactions critiques]
    [Intégrations tierces]
    [Jobs planifiés]

    note bottom: Gerenciado pelo Spring Boot
  }
}

note right
**Foco ótimo :**
Seu tempo de desenvolvimento
concentrado nos 20% que
diferenciam seu produto
end note
@enduml

Conclusão Final

A arquitetura híbrida não é um compromisso técnico, é umadecisão estratégica.

Ela permite que você:

  • �✅ Comece rapidamente com um MVP funcional

  • �✅ Validar seu mercado sem investimento pesado

  • ✅ Evoluir gradualmente quando a complexidade o exige

  • Domine seus custos em cada etapa

  • ✅ Explorar o melhor de cada tecnologia

  • �✅ Evitar a sobreengenharia prematura

  • ✅ Manter a flexibilidade para o futuro

Ela representa :

  • �🎯Pragmatismo: Cada tecnologia onde ela se destaca

  • �🚀velocidade: Tempo de lançamento mínimo

  • �💰EconomiaCustos alinhados ao valor

  • �🔮Escalabilidade: Arquitetura que cresce com você

  • �🛡️Robustez: Serviços testados e confiáveis

Seu Próximo Passo

Se essa arquitetura fala com você, aqui está por onde começar:

  1. Crie uma conta Supabase(gratuito)

  2. Defina seu esquema de dados mínimo

  3. Configure a autenticação OAuth2

  4. Crie sua primeira página JBake que consome a API

  5. Implante no GitHub Pages

Você terá um MVP funcional emalguns dias.

Spring Boot virá naturalmente quando você precisar. Não antes.

A arquitetura híbrida é a arte de construir exatamente o que é necessário, quando é necessário.

Bom desenvolvimento! 🚀

Compartilhe este artigo se você pensar que pode ajudar outros desenvolvedores a fazer as boas escolhas arquitetônicas.

Artigos relacionados

HyperFrames-Gradle : Transformar o AsciiDoc em Vídeo MP4
31 May 2026
Auditoria do meu Consumo LLM : SQLite, OpenCode, Ollama Cloud, e Por Que Minha Assinatura Profissional Está Explodindo o Mercado Mundial
18 May 2026
A Arquitetura “Plugin Independente + Raiz Consumidor”: Por que meus builds Gradle se duplicam
14 May 2026
O Knowledge Graph como motor de recomendação: como eu matei os « artigos relacionados» cronológicos
12 May 2026