¿Qué son los Triggers de Base de Datos (beforeSave y afterSave)?

Un trigger de base de datos es un hook de código que se ejecuta solo en eventos de datos: antes del save para validar, después del save para reaccionar. La idea tiene dos linajes que comparten un principio: el trigger SQL clásico, código procedural que vive dentro del motor de la base de datos, y el hook a nivel de aplicación moderno — beforeSave, afterSave, beforeDelete — JavaScript registrado por clase en el backend. Ambos codifican la misma promesa: la regla se dispara para toda escritura, sin importar qué cliente, SDK o script la ejecutó — que es exactamente lo que la validación del lado del cliente nunca puede prometer.

Puntos clave

El modelo de hooks en acción

Una regla de validación y su aplicación, vistas desde ambos extremos — el servidor la define una vez, y todos los clientes en todas partes la heredan:

// JavaScript — Cloud Code (cloud/main.js)
// beforeSave: validate + normalize — can still change or ABORT the write
Parse.Cloud.beforeSave('Review', (req) => {
  const stars = req.object.get('stars');
  if (stars < 1 || stars > 5) throw 'Stars must be between 1 and 5';
  const comment = req.object.get('comment');
  if (comment && comment.length > 500) {
    req.object.set('comment', comment.slice(0, 497) + '…');
  }
});

// afterSave: side effects — the write already happened; be idempotent
Parse.Cloud.afterSave('Review', async (req) => {
  if (req.object.existed()) return; // count only NEW reviews, once
  await updateAverageStars(req.object.get('movie'));
});

// Flutter / Dart — Back4app Flutter SDK
// The hook fires for EVERY write path — this client included
final review = ParseObject('Review')
  ..set('movie', 'Arrival')
  ..set('stars', 9); // invalid — no client-side check needed
final response = await review.save();
print(response.error?.message); // "Stars must be between 1 and 5"
// The beforeSave hook rejected it server-side. A forged REST call,
// another SDK, an admin script — same rule, same rejection.

// iOS / Swift — Back4app Swift SDK
// The hook fires for EVERY write path — this client included
var review = Review()
review.movie = "Arrival"
review.stars = 9 // invalid — no client-side check needed
do {
    _ = try await review.save()
} catch {
    print(error.localizedDescription) // "Stars must be between 1 and 5"
}
// The beforeSave hook rejected it server-side. A forged REST call,
// another SDK, an admin script — same rule, same rejection.

// Android / Kotlin — Back4app Android SDK
// The hook fires for EVERY write path — this client included
val review = ParseObject("Review")
review.put("movie", "Arrival")
review.put("stars", 9) // invalid — no client-side check needed
try {
    review.save()
} catch (e: ParseException) {
    println(e.message) // "Stars must be between 1 and 5"
}
// The beforeSave hook rejected it server-side. A forged REST call,
// another SDK, an admin script — same rule, same rejection.

La familia completa de hooks extiende la misma forma a todo el ciclo de vida de los datos: beforeSave/afterSave, beforeDelete (bloquear la eliminación de un Album que todavía tiene Photos) y afterDelete (limpiar sus hijos), más beforeFind/afterFind para reescribir consultas y quitar campos de los resultados — el CRUD, envuelto.

La forma clásica: triggers SQL

CREATE TRIGGER audit_price_change
AFTER UPDATE ON products
FOR EACH ROW                              -- nivel de fila: se dispara por fila afectada
WHEN (OLD.price IS DISTINCT FROM NEW.price)
EXECUTE FUNCTION log_price_change();      -- OLD y NEW guardan ambas versiones

La taxonomía que toda base de datos comparte, según las referencias de PostgreSQL y MySQL: timing — BEFORE (puede modificar NEW o abortar), AFTER (reacciona a la fila confirmada), INSTEAD OF (reemplaza la operación, principalmente en vistas); evento — insert, update, delete; granularidad — nivel de fila versus nivel de sentencia (un update de 10 filas dispara un trigger de fila 10 veces, uno de sentencia una vez). Dos semánticas que vale la pena grabarse: los triggers SQL corren dentro de la misma transacción que la escritura — una falla en el trigger revierte la operación entera — y los triggers AFTER solo se disparan para escrituras que de verdad tuvieron éxito.

Before vs. after: elegidos por el trabajo

Los corolarios que ningún explicador enuncia: un efecto secundario en un before-hook es un bug por construcción (el correo sale, y luego el save falla), y un after-hook que no es idempotente es un contador duplicado esperando un reintento. En sistemas de hooks como el de Back4app, afterSave se completa después de que el cliente ya recibió su respuesta — las reacciones son asíncronas por diseño, así que sus fallas deben ser tolerables y quedar en los logs.

Hooks vs. triggers SQL

La última fila es la simetría honesta: la garantía de cada forma está limitada a su capa. Un trigger SQL atrapa hasta una sesión psql renegada, pero esconde lógica del instrumental de la aplicación; un hook a nivel de API cubre todo camino de cliente a través del backend, pero no el acceso crudo a la base — y por eso las plataformas dueñas del gateway de API (todo el tráfico fluye por él) obtienen, en la práctica, lo mejor de ambos. La nota al pie sobre ORMs entra aquí también: los hooks de ORM solo se disparan a través del ORM — las operaciones masivas y el SQL crudo pasan de largo.

Las trampas, con honestidad

La lógica oculta es el clásico: un desarrollador depura su propio código por horas mientras un trigger reescribe valores en silencio — los triggers son invisibles en el punto de llamada, así que documéntalos y mantenlos pocos. Loops infinitos: un trigger que escribe en su propia tabla se vuelve a disparar (y un afterSave que guarda su propio objeto también); protégete comprobando qué cambió, y dale a la recursión una condición de parada antes de que ella encuentre una por ti. Costo síncrono: los before-hooks viven dentro de la latencia de cada escritura — un hook de 200 ms vuelve cada save 200 ms más lento, y las escrituras masivas multiplican los disparos por fila por el número de filas. Cadenas en cascada: triggers que disparan triggers que disparan triggers convierten un insert en un proyecto de arqueología. La regla paraguas de décadas de práctica: los triggers aplican reglas; en el momento en que uno empieza a orquestar un workflow, mueve el workflow a funciones o jobs y deja que el trigger solo encole.

Casos de uso comunes

• Validación que todo cliente obedece — la regla de estrellas-entre-1-y-5, aplicada por igual contra solicitudes falsificadas y SDKs futuros.
• Trazas de auditoría — quién cambió qué y cuándo, escritas por el propio evento en lugar de por clientes cooperativos.
• Contadores desnormalizados y campos calculados — promedios, conteos y duplicados amigables con la búsqueda mantenidos al día en el momento de escribir.
• Integridad en cascada — rechazar eliminaciones con hijos, o limpiar a los hijos después.
• Efectos secundarios reactivos — un afterSave que dispara una notificación push o un webhook saliente: el evento de base de datos convertido en evento de integración.

¿Qué hook y dónde? Matriz de decisión

Limitaciones y trade-offs

• La invisibilidad es el precio de lo automático. Lógica que nadie llama es lógica que nadie recuerda; nombres, docs y code review mantienen la magia auditable.
• Los hooks tienen el alcance de su capa. Los hooks de API no ven escrituras directas a la base; los triggers SQL no pierden nada, pero se esconden de tu instrumental — sabe qué punto ciego elegiste.
• La latencia de escritura es el presupuesto. Todo before-hook gasta de él; mide los hooks como mides las consultas.
• Los after-hooks son eventualmente consistentes. Los contadores se atrasan milisegundos y pueden dispararse doble — diseña las lecturas (y los reintentos) en consecuencia.
• Los triggers no reemplazan constraints. Índices únicos, claves foráneas y ACLs se aplican más barato y más temprano; los triggers empiezan donde las reglas declarativas terminan.

Triggers de Base de Datos en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Los triggers aquí son la familia de eventos de datos de Cloud Code: registra Parse.Cloud.beforeSave('Review', …) una vez — las pestañas de código muestran el patrón completo — y la regla aplica a toda escritura que llega por REST, GraphQL, cualquier SDK o el dashboard, porque el gateway de API es el único camino hacia los datos. Los hooks reciben contexto rico (request.object, request.original, request.user, estado de master key), así que la validación puede diferir para admins, beforeFind puede acotar consultas por usuario encima de las ACLs, y los after-hooks tienen todo el ecosistema JavaScript para las reacciones que los triggers SQL no alcanzan — notificaciones push, webhooks salientes, encolado de jobs. Desplegado con tu código, versionado en git, testeable como cualquier función: la garantía del trigger, sin la arqueología del trigger.