Utilizando el Patrón de Fábrica para administrar diferentes canales de notificación en un producto SaaS

Introducción: El desafío de la notificación en SaaS

Los productos modernos de SaaS dependen de notificaciones personalizadas y oportunas para atraer usuarios, retener unidades y comunicar eventos de sistema crítico. Los usuarios esperan recibir alertas a través de sus canales preferidos: correo electrónico, SMS, notificaciones de empuje, mensajes en aplicación, o incluso webhooks a servicios de terceros. A medida que el producto evoluciona, el número de canales crece y la gestión a través de la lógica condicional dispersa se convierte en una pesadilla de mantenimiento.

Directus, una plataforma CMS sin cabeza de código abierto y backend, proporciona una base flexible para la construcción de aplicaciones SaaS. Su modelo de datos, motor Flows y ganchos extensibles lo convierten en un entorno ideal para implementar un sistema de notificación robusto. Al aplicar un patrón de diseño clásico de creación, el patrón de fábrica, puede encapsular la lógica de creación específica de canales, descodificar su código de negocio central de detalles de entrega, y su producto sin esfuerzo.

Comprender el patrón de fábrica

El Patrón de Fábrica es un patrón de diseño creacional que proporciona una interfaz para crear objetos en una superclase, pero permite que subclases alteren el tipo de objetos que se crearán. Promueve acoplamiento suelto y se adhiere al Principio Abierto/Cerrado: las entidades de software deben estar abiertas para la extensión pero cerradas para la modificación.

Este patrón brilla cuando usted tiene una familia de objetos relacionados y el tipo exacto a instantiate se determina en tiempo de ejecución basado en entrada dinámica, como las preferencias de notificación de un usuario o el evento que se activa. En un contexto de notificación, cada canal es un “producto diferente”, sin embargo todos comparten una interfaz común (por ejemplo, un método ).

Canales de notificación en un producto SaaS

Los canales de notificación comunes incluyen:

Sin un patrón, su código podría parecer así:

function sendNotification(channel, message, recipient) {
 if (channel === 'email') {
 // Email logic here
 } else if (channel === 'sms') {
 // SMS logic here
 } else if (channel === 'push') {
 // Push logic here
 } else {
 throw new Error('Unknown channel');
 }
}

Este enfoque funciona para unos pocos canales, pero cada nuevo canal le obliga a modificar su función de envío y a retestiguar toda la lógica existente. El patrón de fábrica elimina esta fragilidad.

Implementación del Patrón de Fábrica para las Notificaciones

A continuación caminamos a través de una implementación de TipoScript que puede adaptarse para un SaaS basado en Directus. TipoScript es natural para Directus porque la plataforma en sí se construye con ella y proporciona un sistema de tipo rico.

1. Definir la interfaz de notificación

interface Notification {
 send(message: string, recipient: string): Promise<void>
}

2. Clases de notificación concretas

class EmailNotification implements Notification {
 async send(message: string, recipient: string): Promise<void> {
 // Use Directus’s internal mailer or an external SDK
 console.log(`Sending email to ${recipient}: ${message}`);
 }
}

class SMSNotification implements Notification {
 async send(message: string, recipient: string): Promise<void> {
 // Call Twilio API
 console.log(`Sending SMS to ${recipient}: ${message}`);
 }
}

class PushNotification implements Notification {
 async send(message: string, recipient: string): Promise<void> {
 // Use Firebase or OneSignal SDK
 console.log(`Sending push to ${recipient}: ${message}`);
 }
}

3. La fábrica de notificaciones

type ChannelType = 'email' | 'sms' | 'push';

class NotificationFactory {
 static createNotification(channel: ChannelType): Notification {
 switch (channel) {
 case 'email':
 return new EmailNotification();
 case 'sms':
 return new SMSNotification();
 case 'push':
 return new PushNotification();
 default:
 throw new Error(`Unknown notification channel: ${channel}`);
 }
 }
}

4. Usando la fábrica en su aplicación

async function notifyUser(event: string, userId: string, channel: ChannelType) {
 const notification = NotificationFactory.createNotification(channel);
 await notification.send(event, userId);
}

El código del cliente nunca necesita saber el tipo de hormigón. Sólo depende de la interfaz . Este desacoplamiento hace pruebas de unidad directamente—puede burlar el objeto de notificación sin tocar la fábrica o las clases de hormigón.

Integrando el Patrón de Fábrica con Directus

Directus ofrece múltiples puntos de entrada para activar notificaciones:

En un proyecto Directus, puede instalar su fábrica de notificación como un servicio dentro de un módulo personalizado o una extensión. Por ejemplo, dentro de un Flow podría llamar un punto final de API interno que instantánea el canal correcto basado en las preferencias almacenadas de un usuario. Alternativamente, puede envolver la fábrica en un hook

Debido a que la fábrica vive en un solo lugar, puede actualizar sus asignaciones sin tocar cada gancho o flujo. Y como Directus Flows puede pasar datos JSON arbitrarios, puede alimentar fácilmente la fábrica con identificadores de canales de su base de datos.

Beneficios del enfoque de Patrón de Fábrica

Escalabilidad

Añadiendo un nuevo canal significa escribir una nueva clase que implementa y añadir una línea a la declaración de conmutación de la fábrica. No se requieren cambios de código de cliente. Esto es especialmente valioso en los productos de SaaS multi-teniente donde diferentes inquilinos pueden habilitar diferentes conjuntos de canales.

Mantener la capacidad de mantener la capacidad de mantener la capacidad de mantener la capacidad de mantenerla.

La lógica de entrega de notificaciones está aislada de la lógica de negocio. Cada clase de concreto se puede mantener independientemente. Si el proveedor de SMS cambia su API, usted modifica solamente . La fábrica y todos los consumidores permanecen inalterados.

Pruebas

Usted puede probar cada clase de notificación en forma aislada, y puede burlarse de la interfaz cuando se prueban funciones de nivel superior. La fábrica en sí puede ser verificada con una prueba simple que comprueba que devuelve las instancias del tipo correcto para cada canal.

Flexibilidad

La fábrica puede ampliarse para construir objetos complejos. Por ejemplo, puede que desee pasar la configuración (clave de API, políticas de retry) en el momento de la creación. Puede sobrecargar el método de fábrica o utilizar un patrón de construcción dentro de la fábrica para montar objetos de notificación totalmente configurados.Las variables de entorno de Directus o la configuración de bases de datos (por ejemplo, una ] son fuentes ideales.

Posibles retrocesos y consideraciones

Mientras que el patrón de fábrica es una herramienta poderosa, no es una bala de plata:

En una extensión Directus, puede aprovechar la inyección de dependencia integrada de la plataforma (la función y los servicios ) para pasar instancias compartidas como el registrador o el acceso a la base de datos a la fábrica.

Ejemplo real-World: Notificaciones multicanal en un B2B SaaS

Considere una herramienta de gestión de proyectos construida en Directus. Cuando se asigna una tarea, el sistema debe notificar:

Usando la fábrica, el código bajo un gancho Directus se convierte en:

import { NotificationFactory } from './services/NotificationFactory';

async function onTaskCreate(payload, { accountability }) {
 const { assigneeId } = payload;
 const userPreferences = await getUserNotificationPreferences(assigneeId);
 for (const channel of userPreferences.channels) {
 const notifier = NotificationFactory.createNotification(channel);
 await notifier.send(`You have a new task!`, assigneeId);
 }
}

Cada clase de notificación maneja su propia entrega idiomática. La fábrica sigue siendo la única fuente de verdad para la cartografía de canales.

Para ver una implementación completa de tal sistema, consulte La documentación oficial de Directus sobre la creación de ganchos y servicios personalizados. Para una comprensión más profunda del patrón de fábrica en sí, la página Refactoring Guru en Método de fábrica es un recurso excelente. También podría interesarle cómo otras plataformas manejan la orquestación de notificación de TLT4[Flio]

Conclusión

El Patrón de fábrica proporciona una manera limpia y sostenible para gestionar múltiples canales de notificación en un producto SaaS. Al encapsular la creación de objetos, descodifica su lógica de aplicación básica de los específicos de entrega, lo que facilita añadir, eliminar o modificar canales sin efectos de onda en la base de código. Cuando se combina con los ganchos y Flujos flexibles de Directus, obtiene una arquitectura de notificación que se escala con el crecimiento de su producto.

Ya sea que usted está construyendo un simple notificador de correo electrónico o un complejo motor multicanal, comenzando con el patrón de fábrica paga temprano a medida que su conjunto de características se expande. La inversión en una pequeña cantidad de abstracción hoy ahorra días de refactorización mañana.