Creación de Cloud Functions para Autenticación de Usuarios en Firebase

Crear funciones robustas para autenticación en Firebase es más simple cuando se organiza el proyecto con capas claras. Aquí verás cómo activar Cloud Functions al crear o eliminar usuarios, separar la lógica en un controlador y una clase Usuario admin, y manejar promesas y errores sin acoplar todo a Firebase.

¿Cómo organizar el proyecto para funciones de autenticación?

Una buena base es una estructura por componentes con directorios por dominio. Se trabaja con un archivo index que solo registra funciones, un directorio Componentes y una carpeta Usuarios con su controlador. El controlador recibe el evento y delega en la lógica de negocio, evitando mezclar disparadores con reglas de aplicación.

• Arquitectura por capas: disparador mínimo, controlador y clase de utilidad.
• Desacoplamiento de Firebase: solo el index queda vinculado a Firebase. Si cambias de proveedor, ajustas ese archivo y poco más.
• Mantenibilidad: fácil agregar funciones y analizar código.

¿Qué arquitectura desacoplada evita el acoplamiento a Firebase?

Se define el disparador en index usando la librería de Firebase Functions y se delega la lógica al controlador. Así, el vínculo con Firebase queda en una línea y el resto del código es portable.

¿Dónde viven los controladores y clases de utilidad?

En Componentes/Usuarios: el controlador orquesta cada evento y la clase Usuario admin implementa la lógica como enviar correos, registrar datos en Firebase y sincronizar con CRM.

¿Qué hacen las Cloud Functions onCreate y onDelete?

Se crean funciones para dos eventos de autenticación: onCreate y onDelete sobre usuarios. El disparador se define con la librería instalada de Functions: auth para indicar que responde a eventos de usuarios.

• onCreate: se ejecuta al crear un usuario en Firebase Auth.
• onDelete: se ejecuta al eliminar un usuario.
• Varios disparos por el mismo evento: se pueden registrar múltiples funciones para onCreate, cada una autónoma.

¿Cómo declarar functions.auth.user().onCreate y onDelete?

En index se exportan funciones que usan auth.user().onCreate y auth.user().onDelete, apuntando al controlador correspondiente. La lógica de negocio no vive aquí, solo la referencia al método del controlador.

¿Se pueden registrar varias funciones por el mismo trigger?

Sí: es válido tener dos funciones que se ejecuten en el mismo onCreate. Por ejemplo, una para enviar correo de bienvenida y otra para registrar al usuario en un CRM. Cada una se ejecuta de forma independiente y mantiene su propia lógica.

¿Cómo implementar la lógica: emails, CRM y manejo de promesas?

El controlador crea una instancia de Usuario admin y encadena operaciones mediante promesas. Al dispararse onCreate se recibe el objeto del usuario con datos como displayName y email, que alimentan los métodos de negocio.

• Datos del evento: usuario.displayName y usuario.email.
• Promesas: se retorna la promesa y se encadenan acciones secuenciales.
• Errores: manejo con catch y console.error para diagnosticar fallas.

¿Qué hace la clase usuario admin en el envío de correos?

Implementa métodos como enviar email de bienvenida y enviar email de despedida. Usa una librería de correo con plantilla HTML y parámetros como from, to, subject y contenido. El HTML cambia según el caso: bienvenida o despedida.

• Bienvenida: se llama con nombre y email tras onCreate.
• Despedida: se llama con nombre y email tras onDelete.
• Plantillas: HTML predefinido para cada correo.

¿Cómo se pasan datos del usuario y se manejan errores?

El evento provee el objeto del usuario creado en Firebase. Se invocan métodos con usuario.displayName y usuario.email. Tras enviar el correo de bienvenida, se encadena el registro del email en Firebase para futuras campañas de mailing; si ocurre un error, se captura con catch e imprime con console.error.

• Secuencia típica (onCreate):
• Enviar email de bienvenida con nombre y correo.
• Registrar email en base de datos de Firebase para mailing.
• Sincronizar con CRM según necesidad.
• Capturar errores con catch y loguear con console.error.

¿Qué implica sincronizar con un CRM como HubSpot?

La clase Usuario admin incluye un método para sincronizar con HubSpot, que recibe nombre, apellidos y email. Si el apellido no está separado, se puede dividir displayName antes de enviarlo. El controlador retorna esta promesa para integrarla en el flujo.

• Parámetros: nombre, apellidos, email.
• Autonomía: esta función puede convivir con la de bienvenida bajo el mismo onCreate.
• Portabilidad: al estar en una clase, es fácil cambiar de CRM si se requiere.

¿Tienes dudas sobre la organización por controladores, el uso de onCreate/onDelete o el manejo de promesas y errores? Cuéntame en comentarios y ampliamos con ejemplos puntuales.