Saltar al contenido principal

Frontend: datos e integraciones

Como viajan los datos​

El frontend consume principalmente informacion del backend REST y la combina con infraestructura de Firebase.

La secuencia normal es:

  1. la pantalla dispara una accion
  2. el hook de feature organiza la peticion
  3. el service hace la llamada HTTP
  4. apiClient agrega headers e intercepta errores
  5. React Query cachea o invalida segun el caso

apiClient​

src/config/apiClient.ts centraliza la capa HTTP.

Sus responsabilidades principales son:

  • usar VITE_BACKEND_URL
  • enviar Authorization cuando hay sesion
  • inyectar businessId solo cuando la ruta actual pertenece al contexto activo de negocio
  • mostrar feedback global
  • reaccionar a errores 401 y 403

Contexto en requests​

Requests de negocio​

Cuando existe membresia activa y la ruta esta dentro del panel del negocio:

  • el frontend agrega businessId
  • los servicios consultan o mutan informacion de ese tenant
  • si la cookie apunta a una membresia que ya no existe, el guard limpia el contexto y devuelve a seleccion

Requests globales​

Cuando la persona esta en Panel de control:

  • no se inyecta businessId
  • la autorizacion depende de la membresia global y sus permisos
  • GET /auth/me entrega el globalAccess usado por los guards y menus

Esto es clave porque Cutlyy ahora distingue entre contexto global y contexto multiempresa de negocio.

Hidratacion de sesion​

Despues de que Firebase confirma sesion, el frontend llama GET /auth/me.

Esa respuesta llena:

  • useUserStore
  • useSessionAccessStore
  • useGlobalAccessStore
  • useRoleStore
  • useBusinessMembershipStore si la cookie businessMembershipId todavia apunta a una membresia valida

useRefreshSessionAccess permite repetir esa hidratacion desde la seleccion de negocio para reflejar membresias recien creadas o reactivadas.

Integraciones del lado cliente​

Firebase Auth​

Se usa para:

  • mantener la sesion primaria
  • obtener el token que luego valida el backend

Firestore​

Se usa para listeners en tiempo real sobre:

  • membresia activa del negocio
  • permisos del rol activo

Firebase Storage​

Se usa en flujos de carga de imagenes y archivos asociados a perfiles o negocio.

La limpieza de archivos por URL valida el bucket contra VITE_FIREBASE_STORAGE_BUCKET. Si una URL apunta a otro bucket, el frontend evita borrarla para no eliminar recursos de otro ambiente por accidente.

Firebase Messaging​

Se usa para push web cuando:

  • el navegador lo soporta
  • la persona otorga permisos
  • la app esta instalada como PWA
  • existe configuracion VAPID valida

Google Maps​

Se usa sobre todo para formularios y experiencia de sedes:

  • autocompletado
  • ubicacion
  • coordenadas

Variables de entorno esperadas​

VariableUso
VITE_BACKEND_URLBase URL del backend
VITE_FIREBASE_API_KEYConfiguracion cliente de Firebase
VITE_FIREBASE_AUTH_DOMAINAuth de Firebase
VITE_FIREBASE_PROJECT_IDProyecto Firebase
VITE_FIREBASE_STORAGE_BUCKETStorage
VITE_FIREBASE_MESSAGING_SENDER_IDMessaging
VITE_FIREBASE_APP_IDApp Firebase
VITE_FIREBASE_VAPID_KEYPush web
VITE_GOOGLE_MAPS_API_KEYGoogle Maps
VITE_PUSH_NOTIFICATIONS_ENABLEDFeature flag de push

Setup local minimo​

npm install
npm run dev

Validaciones recomendadas antes de cerrar cambios:

npm run typecheck
npm run lint
npm run build:check
npm run build:check:dev
npm run build:check:prod

Comandos de build y deploy​

Segun el package.json actual:

npm run build
npm run build:dev
npm run build:prod
npm run deploy:dev
npm run deploy:prod

deploy:dev construye con modo development y despliega hosting al proyecto barber-app-dev-c7f59. deploy:prod construye con modo prod y despliega hosting a cutlyy-prd.

Puntos de integracion sensibles​

  • auth y claims del token
  • hidratacion de sesion via GET /auth/me
  • resolucion de membresia global
  • header businessId en contexto de negocio
  • listeners de Firestore
  • registro y limpieza de suscripciones push
  • llaves de Google Maps y VAPID
  • bucket correcto en cargas y borrados de Firebase Storage

Riesgos actuales​

  • si cambia el contrato del backend, muchos hooks dependen de esa compatibilidad
  • si falla la resolucion de usuario o membresia, la sesion puede cerrarse
  • el frontend hace validaciones utiles, pero la proteccion final sigue del lado del backend

Documentos relacionados​