levi.2526
/
trello_fake
mirror of https://github.com/LeviPlanelles/trello_fake.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
trello_fake/presentaciones/levi/codigo_interno.md

6.2 KiB
Raw Blame History

Apuntes de codigo

1) Infraestructura (Docker)

Que capturar:

  • Archivo docker-compose.yml
  • Bloques mariadb y dolibarr
  • Puertos, variables y volumenes

Por que es importante:

  • El proyecto depende de Dolibarr y una base de datos real.
  • Docker permite reproducir el entorno en cualquier maquina.
  • Sin Dolibarr activo, la API devuelve errores de conexion.

Captura sugerida: Docker Compose

Guion corto:

  • Se levantan 2 servicios: MariaDB y Dolibarr.
  • Dolibarr expone el puerto 8200 para acceder al ERP.
  • Las credenciales y modulos se configuran por variables de entorno.
  • Los volumenes guardan datos persistentes.

2) Variables de entorno (configuracion)

Que capturar:

  • Archivo .env.local
  • Variables DOLIBARR_API_URL y DOLIBARR_API_KEY

Por que es importante:

  • La app no funciona sin apuntar a la API de Dolibarr.
  • La API key se mantiene en servidor y no se expone al cliente.

Captura sugerida (oculta la key real): Env Local

Guion corto:

  • La URL y la API key son el puente con Dolibarr.
  • Existen variables legacy NEXT_PUBLIC_* por compatibilidad.

3) Proxy API (seguridad de la API key)

Que capturar:

  • Archivo app/api/dolibarr/[...path]/route.ts
  • Construccion del endpoint y DOLAPIKEY
  • Metodos GET/POST/PUT/DELETE

Por que es importante:

  • El frontend nunca habla directamente con Dolibarr.
  • El proxy agrega la key en servidor y protege credenciales.

Captura sugerida: Proxy API

Guion corto:

  • Todas las llamadas pasan por /api/dolibarr/....
  • Se construye la URL real con DOLIBARR_API_URL.
  • Se reenvian los metodos HTTP y se manejan errores.

4) Cliente central de Dolibarr

Que capturar:

  • Archivo lib/dolibarrClient.ts
  • dolibarrDirectFetch y dolibarrProxyFetch
  • dolibarrFetch que decide segun entorno

Por que es importante:

  • Centraliza todas las llamadas a la API.
  • Simplifica los servicios (proyectos, tareas, usuarios).

Captura sugerida: Dolibarr Client

Guion corto:

  • Si es servidor usa llamada directa.
  • Si es cliente usa el proxy interno.
  • Se aplica cache corta (revalidate: 60).

5) Servicios de proyectos (CRUD)

Que capturar:

  • Archivo lib/projectsService.ts
  • getProjects, createProject, updateProject, deleteProject

Por que es importante:

  • Toda la logica de proyectos vive aqui.
  • La UI solo consume estos metodos, no la API directa.

Captura sugerida: Projects Service

Guion corto:

  • getProjects() obtiene datos y los mapea a formato UI.
  • createProject() crea en Dolibarr y devuelve el proyecto completo.
  • Se controla el flujo de errores en un solo lugar.

6) Mapeo de datos y estados

Que capturar:

  • Archivo types/project.ts
  • ProjectStatus y STATUS_CONFIG
  • mapDolibarrProject

Por que es importante:

  • Dolibarr devuelve datos crudos, la UI necesita formato amigable.
  • Se normalizan fechas, presupuesto y progreso.

Captura sugerida: Project Types

Guion corto:

  • Estados oficiales: 0 Borrador, 1 Activo, 2 Cerrado.
  • El mapper convierte campos y define etiquetas visibles.

7) Autenticacion (login)

Que capturar:

  • Archivo lib/authService.ts
  • login() (llamada a /login de Dolibarr)
  • saveAuthData() (localStorage + cookie)

Por que es importante:

  • El acceso esta protegido por credenciales reales de Dolibarr.
  • El token se guarda y permite navegar por la app.

Captura sugerida: Auth Service

Guion corto:

  • El login pide token a Dolibarr.
  • Si es correcto, se guarda en localStorage y cookie.
  • Se usa luego para validar sesiones.

8) Middleware de acceso

Que capturar:

  • Archivo middleware.ts
  • Lectura de cookie dolibarr_auth_token
  • Redireccion a /login

Por que es importante:

  • Protege rutas privadas cuando no hay token.
  • Bloquea acceso directo a la app sin autenticacion.

Captura sugerida: Middleware

Guion corto:

  • Si no hay token, redirige a login.
  • Si hay token, permite navegar.

9) Seed de datos (demo reproducible)

Que capturar:

  • Archivo scripts/seed-projects-via-api.js
  • Bloque de datos de proyectos
  • Logica de limpieza y cierre de proyectos

Por que es importante:

  • Permite crear datos realistas en minutos.
  • La demo es consistente para la presentacion.

Captura sugerida: Seed Script

Guion corto:

  • El seed elimina proyectos previos.
  • Crea 14 proyectos con tareas.
  • Los que estan al 100% se cierran (status 2).

10) Servicio de tareas

Que capturar:

  • Archivo lib/tasksService.ts
  • getTasksByProjectId() (filtra tareas por proyecto)

Por que es importante:

  • Dolibarr no filtra bien por proyecto y se corrige en el cliente.
  • Se calcula estadistica de tareas para el dashboard.

Captura sugerida: Tasks Service

Guion corto:

  • Se piden todas las tareas y se filtra por fk_project.
  • Se calcula progreso y estadisticas de tareas.

11) Manejo de errores y cache

Que capturar:

  • lib/dolibarrClient.ts (bloque de revalidate: 60)
  • app/api/dolibarr/[...path]/route.ts (log de errores)

Por que es importante:

  • Explica por que a veces se ven datos antiguos.
  • Muestra que los errores se controlan en el proxy.

Captura sugerida: Cache and Errors

Guion corto:

  • Se usa cache corta para no saturar Dolibarr.
  • Si Dolibarr esta apagado, la API responde con error.

12) Conexion entre piezas (flujo resumido)

Que capturar:

  • Un diagrama o esquema simple (puede ser dibujado) mostrando: UI -> Proxy -> Dolibarr -> DB

Guion corto:

  • La UI nunca toca la API directamente.
  • El proxy y el cliente central simplifican el acceso.
  • Dolibarr sigue siendo la fuente unica de verdad.

Anexo opcional: comandos utiles

Puedes anadir al final un mini bloque con comandos para mostrar que sabes levantar el entorno:

docker-compose up -d
npm run dev
npm run seed

Fin de las notas. Aqui solo pegas capturas y ajustas el texto que uses en la presentacion.