Skip to main content

Estructura del backend

Esta página describe cómo está organizado el backend de Apolo, basado en NestJS y estructurado en múltiples aplicaciones API dentro del monorepo Nx.

APIs disponibles​

En la carpeta apps/ encontrarás los siguientes servicios backend:

apps/
├── bff-api/            # Backend for Frontend (agregación y orquestación)
├── auth-api/           # Autenticación, usuarios y flujos de login
├── applications-api/   # Gestión de aplicaciones / módulos
├── core-api/           # Dominio core de seguridad/auditoría
├── reports-api/        # Reportes y exportaciones
└── tenants-api/        # Gestión multi-tenant

Cada API es una aplicación NestJS independiente, pero comparten contratos, DTOs y lógica de dominio a través de librerías en libs/.

Estructura típica de una API​

La estructura de referencia dentro de una API (apps/<service>/src/) sigue el estilo estándar de NestJS adaptado a un enfoque modular:

apps/bff-api/src/
├── main.ts                 # Punto de entrada de NestJS
├── app.module.ts           # Módulo raíz
├── config/                 # Configuración (secrets, env, providers)
├── app/
│   ├── auth/               # Módulo de autenticación
│   ├── applications/       # Módulo de aplicaciones
│   ├── reports/            # Módulo de reportes
│   ├── tenants/            # Módulo de tenants
│   └── ...                 # Otros módulos específicos
└── shared/                 # Helpers, interceptors, guards, etc. (si aplica)

⚠️ La estructura exacta puede variar ligeramente por servicio, pero la idea general es:

  • Módulos por dominio funcional
  • Reutilización de contratos y lógica desde libs/
  • Configuración desacoplada en config/

Organización por dominio​

Cada módulo suele incluir:

  • Controller(s): definen los endpoints HTTP (con Swagger).
  • Service(s): encapsulan la lógica de negocio y orquestación.
  • DTOs / Schemas: importados desde @apolo-app-platcom-platform/libs (Zod, tipos compartidos, etc.).
  • Guards / Pipes / Interceptors: para autenticación, validación, logging, etc.

Ejemplo (simplificado) de importación de contratos compartidos:

import { UserCreateDto, EmailPasswordLoginDto, UsersGetDto } from '@apolo-app-platcom-platform/libs';

BFF (Backend for Frontend)​

El servicio bff-api actúa como una capa de orquestación:

  • Expone una API unificada para el portal-web.
  • Agrega datos desde los distintos microservicios (auth-api, core-api, reports-api, etc.).
  • Centraliza:
    • Autenticación/autorización del frontend.
    • Validaciones transversales.
    • Enrutamiento hacia servicios internos.
    • Exposición del Swagger unificado con todos los endpoints.

Para detalles sobre cómo consumir las APIs y el Swagger, consulta:

Convenciones recomendadas​

  • Un bounded context por API (auth, applications, tenants, etc.).
  • Controladores delgados, delegando lógica a servicios.
  • Contracts first: DTOs/schemas definidos en libs y consumidos por las APIs.
  • Configuración centralizada a través de Seki y config/.secretsrc.json.
  • Uso consistente de Swagger para documentación de endpoints.