Araponga Logo

Wiki Araponga

Documentação Completa

Reavaliação: BFF como Módulo vs Aplicação Externa

Data: 2026-01-28
Status: 🔄 Reavaliação Estratégica
Objetivo: Reavaliar se o BFF deve ser um módulo na arquitetura modular ou uma aplicação externa que consome a API de serviços e módulos

A avaliação inicial do BFF (AVALIACAO_BFF_BACKEND_FOR_FRONTEND.md) propôs o BFF como um módulo adicional na arquitetura modular existente. No entanto, considerando:

  1. Evolução arquitetural planejada (Monolito → APIs Modulares → Microserviços)
  2. Natureza do BFF (camada de apresentação/agregação, não lógica de negócio)
  3. Separação de responsabilidades (BFF é específico para frontend, não é domínio de negócio)
  4. Escalabilidade independente (BFF pode precisar escalar diferente dos módulos de negócio)

É necessário reavaliar se o BFF deve ser:

  • Opção A: Módulo interno (como proposto inicialmente)
  • Opção B: Aplicação externa que consome a API

🎯 Análise Comparativa

Opção A: BFF como Módulo Interno

┌─────────────────────────────────────────────────────────┐
│              Arah.Api (Aplicação Única)              │
│  ┌────────────────────────────────────────────────────┐  │
│  │  BFF Module (Journey Controllers)                 │  │
│  │  - FeedJourneyController                           │  │
│  │  - EventJourneyController                         │  │
│  │  - MarketplaceJourneyController                    │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Módulos de Negócio (Controllers)                  │  │
│  │  - FeedController                                  │  │
│  │  - EventsController                                │  │
│  │  - MarketplaceController                            │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Application Services (lógica de negócio)          │  │
│  │  - FeedService                                     │  │
│  │  - EventsService                                  │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Modules (arquitetura modular)                    │  │
│  │  - FeedModule                                      │  │
│  │  - EventsModule                                   │  │
│  │  - MarketplaceModule                               │  │
│  │  - BffModule (novo)                                │  │
│  └────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────┘

  1. Simplicidade de Deploy

    • ✅ Um único deploy
    • ✅ Compartilha recursos (memória, CPU)
    • ✅ Comunicação in-process (sem latência de rede)
    • ✅ Compartilha autenticação/autorização

  2. Desenvolvimento Simplificado

    • ✅ Acesso direto aos serviços de aplicação
    • ✅ Sem necessidade de HTTP client entre BFF e API
    • ✅ Debugging mais simples (mesmo processo)
    • ✅ Compartilha configuração e secrets

  3. Custo Operacional

    • ✅ Zero custo adicional (mesmo servidor)
    • ✅ Sem overhead de rede entre BFF e API
    • ✅ Ideal para Fase 1 (Monolito)

  4. Coexistência com API Existente

    • ✅ BFF e API RESTful podem coexistir na mesma aplicação
    • ✅ Rotas diferentes (/api/v1/* vs /api/v2/journeys/*)
    • ✅ Migração gradual possível

  1. Acoplamento com API Principal

    • ❌ BFF não pode evoluir independentemente
    • ❌ Deploy do BFF requer deploy de toda a API
    • ❌ Falha no BFF pode afetar API principal (mesmo processo)
    • ❌ Não pode escalar BFF independentemente

  2. Limitações para Evolução Arquitetural

    • ❌ Dificulta migração para APIs Modulares (Fase 2)
    • ❌ Dificulta migração para Microserviços (Fase 3)
    • ❌ BFF ficaria acoplado a todos os módulos

  3. Responsabilidades Misturadas

    • ❌ BFF (camada de apresentação) misturado com lógica de negócio
    • ❌ Violação de separação de responsabilidades
    • ❌ Dificulta manutenção e testes

  4. Escalabilidade

    • ❌ Não pode escalar BFF separadamente (escala tudo junto)
    • ❌ BFF pode ter padrões de carga diferentes dos módulos de negócio
    • ❌ Recursos compartilhados podem causar contenção

Opção B: BFF como Aplicação Externa

┌─────────────────────────────────────────────────────────┐
│              Aplicações de Interface Visual              │
│  (Flutter App, Web App, Admin Dashboard, etc.)          │
└────────────────────┬────────────────────────────────────┘
                     │
                     │ HTTP/REST
                     │
┌────────────────────▼────────────────────────────────────┐
│         Arah.Api.Bff (Aplicação Externa)            │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Journey Controllers                               │  │
│  │  - FeedJourneyController                          │  │
│  │  - EventJourneyController                        │  │
│  │  - MarketplaceJourneyController                   │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Journey Services (orquestração)                   │  │
│  │  - FeedJourneyService                            │  │
│  │  - EventJourneyService                          │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Response Transformers (UI formatting)            │  │
│  │  - FeedResponseTransformer                        │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  HTTP Clients (consome API principal)              │  │
│  │  - IApiHttpClient                                 │  │
│  └────────────────────────────────────────────────────┘  │
└────────────────────┬────────────────────────────────────┘
                     │
                     │ HTTP/REST
                     │
┌────────────────────▼────────────────────────────────────┐
│         Arah.Api (API Principal)                    │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Controllers (por recurso)                        │  │
│  │  - FeedController                                  │  │
│  │  - EventsController                                │  │
│  │  - MarketplaceController                           │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Application Services (lógica de negócio)          │  │
│  │  - FeedService                                     │  │
│  │  - EventsService                                  │  │
│  └────────────────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Modules (arquitetura modular)                    │  │
│  │  - FeedModule                                      │  │
│  │  - EventsModule                                   │  │
│  │  - MarketplaceModule                               │  │
│  └────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────┘

  1. Separação de Responsabilidades

    • ✅ BFF é claramente uma camada de apresentação
    • ✅ API principal foca em lógica de negócio
    • ✅ Responsabilidades bem definidas

  2. Evolução Independente

    • ✅ BFF pode evoluir independentemente da API
    • ✅ Deploy do BFF não requer deploy da API
    • ✅ Versões diferentes do BFF podem coexistir
    • ✅ Facilita migração para APIs Modulares/Microserviços

  3. Escalabilidade Independente

    • ✅ BFF pode escalar separadamente da API
    • ✅ BFF pode ter padrões de carga diferentes
    • ✅ Recursos dedicados para BFF
    • ✅ Ideal para alta demanda de frontend

  4. Resiliência

    • ✅ Falha no BFF não afeta API principal
    • ✅ Falha na API principal pode ser tratada no BFF (cache, fallback)
    • ✅ Circuit breakers e retry policies

  5. Preparado para Evolução Arquitetural

    • ✅ Facilita migração para APIs Modulares (Fase 2)
    • ✅ Facilita migração para Microserviços (Fase 3)
    • ✅ BFF pode consumir múltiplas APIs/microserviços
    • ✅ Pode ter BFFs diferentes para diferentes clientes

  6. Testabilidade

    • ✅ BFF pode ser testado isoladamente (mock da API)
    • ✅ API pode ser testada isoladamente
    • ✅ Testes de integração mais claros

  1. Complexidade Adicional

    • ❌ Mais uma aplicação para gerenciar
    • ❌ Mais um deploy para configurar
    • ❌ Mais um ponto de falha
    • ❌ Requer HTTP client entre BFF e API

  2. Overhead de Rede

    • ❌ Latência adicional (BFF → API)
    • ❌ Serialização/deserialização de dados
    • ❌ Possibilidade de falhas de rede
    • ❌ Mais tráfego de rede

  3. Custo Operacional

    • ❌ Mais recursos (servidor adicional ou mais instâncias)
    • ❌ Mais complexidade de infraestrutura
    • ❌ Pode aumentar custos (especialmente em Fase 1)

  4. Autenticação/Autorização

    • ❌ Precisa repassar tokens entre BFF e API
    • ❌ Pode precisar de autenticação adicional
    • ❌ Mais complexidade de segurança

  5. Desenvolvimento Inicial

    • ❌ Mais setup inicial
    • ❌ Precisa implementar HTTP client
    • ❌ Debugging mais complexo (dois processos)

🔄 Análise por Fase Arquitetural

Recomendação: Opção A (Módulo Interno) ⭐

Justificativa:

  • ✅ Simplicidade é prioridade
  • ✅ Custo zero adicional
  • ✅ Comunicação in-process é mais eficiente
  • ✅ Um único deploy é mais simples
  • ✅ Não há necessidade de escalabilidade independente ainda

Estrutura:

Arah.Api/
├── Controllers/
│   ├── FeedController.cs (API v1)
│   ├── EventsController.cs (API v1)
│   └── Journeys/
│       ├── FeedJourneyController.cs (BFF - API v2)
│       └── EventJourneyController.cs (BFF - API v2)
├── Services/
│   ├── FeedService.cs
│   └── Journeys/
│       └── FeedJourneyService.cs (BFF)
└── Modules/
    ├── FeedModule.cs
    └── BffModule.cs (novo)

Rotas:

  • /api/v1/feed/* - API RESTful existente
  • /api/v2/journeys/feed/* - BFF (novo)

Recomendação: Opção B (Aplicação Externa) ⭐

Justificativa:

  • ✅ BFF precisa consumir múltiplas APIs modulares
  • ✅ Escalabilidade independente se torna importante
  • ✅ Separação de responsabilidades é crítica
  • ✅ Facilita migração gradual

Estrutura:

Arah.Api.Bff/ (aplicação separada)
├── Controllers/
│   └── Journeys/
│       ├── FeedJourneyController.cs
│       └── EventJourneyController.cs
├── Services/
│   └── Journeys/
│       └── FeedJourneyService.cs
└── Clients/
    ├── FeedApiClient.cs (consome Feed API :5001)
    └── EventsApiClient.cs (consome Events API :5002)

Arah.Api.Feed/ (API modular)
├── Controllers/
│   └── FeedController.cs
└── Modules/
    └── FeedModule.cs

Arah.Api.Events/ (API modular)
├── Controllers/
│   └── EventsController.cs
└── Modules/
    └── EventsModule.cs

Comunicação:

  • BFF → Feed API: http://feed-api:5001/api/v1/feed/*
  • BFF → Events API: http://events-api:5002/api/v1/events/*

Recomendação: Opção B (Aplicação Externa) ⭐⭐

Justificativa:

  • ✅ BFF é essencial para agregar múltiplos microserviços
  • ✅ Escalabilidade independente é crítica
  • ✅ Pode ter BFFs diferentes para diferentes clientes
  • ✅ Resiliência e circuit breakers são necessários

Estrutura:

Arah.Api.Bff/ (aplicação separada)
├── Controllers/
│   └── Journeys/
│       ├── FeedJourneyController.cs
│       └── EventJourneyController.cs
├── Services/
│   └── Journeys/
│       └── FeedJourneyService.cs
└── Clients/
    ├── FeedServiceClient.cs (consome Feed Service)
    └── EventsServiceClient.cs (consome Events Service)
    └── ResilientHttpClient.cs (com retry, circuit breaker)

Feed.Service/ (microserviço)
├── Controllers/
│   └── FeedController.cs
└── Modules/
    └── FeedModule.cs

Events.Service/ (microserviço)
├── Controllers/
│   └── EventsController.cs
└── Modules/
    └── EventsModule.cs

Comunicação:

  • BFF → Feed Service: http://feed-service/api/v1/feed/*
  • BFF → Events Service: http://events-service/api/v1/events/*
  • Service Discovery: Consul/Kubernetes
Critério Opção A (Módulo) Opção B (Aplicação Externa) Vencedor
Fase 1: Monolito ✅ Simples, zero custo ❌ Complexidade desnecessária A
Fase 2: APIs Modulares ❌ Acoplamento problemático ✅ Separação clara B
Fase 3: Microserviços ❌ Não adequado ✅ Essencial B
Escalabilidade Independente ❌ Não ✅ Sim B
Evolução Independente ❌ Não ✅ Sim B
Simplicidade Inicial ✅ Simples ❌ Mais complexo A
Custo Operacional (Fase 1) ✅ Zero ❌ Mais recursos A
Separação de Responsabilidades ❌ Misturado ✅ Clara B
Resiliência ❌ Falha compartilhada ✅ Isolada B
Preparação para Evolução ❌ Dificulta ✅ Facilita B

🎯 Recomendação Final

Fase 1 (Atual): BFF como Módulo Interno

  • ✅ Implementar BFF como módulo dentro de Arah.Api
  • ✅ Rotas em /api/v2/journeys/*
  • ✅ Coexiste com API v1 existente
  • ✅ Simplicidade e zero custo

Fase 2 (APIs Modulares): Migrar BFF para Aplicação Externa

  • ✅ Extrair BFF para Arah.Api.Bff (aplicação separada)
  • ✅ BFF consome APIs modulares via HTTP
  • ✅ Escalabilidade independente
  • ✅ Preparado para microserviços

Fase 3 (Microserviços): BFF como Gateway de Agregação

  • ✅ BFF já está como aplicação externa
  • ✅ Consome múltiplos microserviços
  • ✅ Resiliência e circuit breakers
  • ✅ Pode ter múltiplos BFFs (mobile, web, admin)

📋 Plano de Implementação

Objetivo: Implementar BFF básico como módulo interno

Tarefas:

  1. Criar Arah.Modules.Bff (módulo)
  2. Criar BffModule.cs que registra serviços de jornadas
  3. Criar controllers em Arah.Api/Controllers/Journeys/
  4. Criar services em Arah.Application/Services/Journeys/
  5. Implementar jornadas prioritárias:
    • Onboarding
    • Feed (criar e visualizar)
    • Eventos (criar e participar)
  6. Rotas em /api/v2/journeys/*
  7. Testes unitários e de integração

Estrutura:

backend/
├── Arah.Api/
│   ├── Controllers/
│   │   └── Journeys/
│   │       ├── FeedJourneyController.cs
│   │       └── EventJourneyController.cs
│   └── ...
├── Arah.Application/
│   └── Services/
│       └── Journeys/
│           ├── FeedJourneyService.cs
│           └── EventJourneyService.cs
└── Arah.Modules.Bff/
    └── BffModule.cs

Vantagens:

  • ✅ Implementação rápida
  • ✅ Zero custo adicional
  • ✅ Comunicação in-process eficiente
  • ✅ Coexiste com API v1

Objetivo: Extrair BFF para aplicação separada quando migrar para APIs Modulares

⚠️ PLANO DETALHADO: Ver PLANO_EXTRACAO_BFF_APLICACAO_EXTERNA.md

Tarefas Principais:

  1. Criar projeto Arah.Api.Bff (aplicação ASP.NET Core separada)
  2. Implementar OAuth2 Authorization Server (Client Credentials Flow)
  3. Sistema de registro de múltiplos apps consumidores
  4. Mover controllers de Arah.Api para Arah.Api.Bff
  5. Mover services de Arah.Application para Arah.Api.Bff/Services
  6. Criar HTTP clients para consumir APIs modulares:
    • FeedApiClient → http://feed-api:5001
    • EventsApiClient → http://events-api:5002
  7. Implementar retry e circuit breaker
  8. Configurar autenticação própria (OAuth2) e repasse de tokens
  9. Atualizar documentação e deploy

Estrutura:

backend/
├── Arah.Api.Bff/ (nova aplicação)
│   ├── Controllers/
│   │   ├── OAuthController.cs (OAuth2 token endpoint)
│   │   ├── Journeys/
│   │   │   ├── FeedJourneyController.cs
│   │   │   └── EventJourneyController.cs
│   │   └── Admin/
│   │       └── ClientRegistrationController.cs
│   ├── Services/
│   │   ├── Journeys/
│   │   │   ├── FeedJourneyService.cs
│   │   │   └── EventJourneyService.cs
│   │   └── OAuth/
│   │       └── ClientRegistrationService.cs
│   ├── Clients/
│   │   └── ApiHttpClient.cs
│   └── Security/
│       ├── BffTokenService.cs
│       └── BffAuthenticationMiddleware.cs
├── Arah.Domain.OAuth/ (novo)
│   └── ClientApplication.cs
├── Arah.Api.Feed/ (API modular)
│   └── ...
└── Arah.Api.Events/ (API modular)
    └── ...

Esforço Estimado: 5 semanas (200 horas)

Vantagens:

  • ✅ Escalabilidade independente
  • ✅ Separação de responsabilidades
  • ✅ Autenticação própria (OAuth2)
  • ✅ Suporte a múltiplos apps consumidores
  • ✅ Preparado para microserviços
  • ✅ Evolução independente

Recomendação: Estratégia Híbrida - Evolução Gradual

  1. Fase 1 (Agora): Implementar BFF como módulo interno

    • Simplicidade e zero custo
    • Comunicação in-process eficiente
    • Coexiste com API v1

  2. Fase 2 (APIs Modulares): Migrar BFF para aplicação externa

    • Escalabilidade independente
    • Separação de responsabilidades
    • Preparado para evolução

  3. Fase 3 (Microserviços): BFF já está como aplicação externa

    • Consome múltiplos microserviços
    • Resiliência e circuit breakers
    • Pode ter múltiplos BFFs

Benefícios da Estratégia Híbrida:

  • ✅ Começa simples (Fase 1)
  • ✅ Evolui conforme necessidade (Fase 2-3)
  • ✅ Não requer reescrita completa
  • ✅ Minimiza custos iniciais
  • ✅ Maximiza flexibilidade futura

Última Atualização: 2026-01-28
Status: ✅ Reavaliação Completa - Recomendação Definida

← Voltar às Boas-VindasVer Todos os Docs →