What are Database Triggers (BeforeSave and AfterSave)?

A database trigger is a code hook that runs automatically on data events — before a save to validate, after it to react. The idea has two lineages sharing one principle: the classical SQL trigger, procedural code living inside the database engine, and the modern application-level hook — beforeSave, afterSave, beforeDelete — JavaScript registered per class in the backend. Both encode the same promise: the rule fires for every write, no matter which client, SDK, or script performed it — which is precisely what client-side validation can never promise.

Key takeaways

The hook model in action

A validation rule and its enforcement, from both ends — the server defines it once, and every client everywhere inherits it:

// 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.

The full hook family extends the same shape across the data lifecycle: beforeSave/afterSave, beforeDelete (block deleting an Album that still has Photos) and afterDelete (clean up its children), plus beforeFind/afterFind to rewrite queries and strip fields from results — CRUD, wrapped.

The classical form: SQL triggers

CREATE TRIGGER audit_price_change
AFTER UPDATE ON products
FOR EACH ROW                              -- row-level: fires per affected row
WHEN (OLD.price IS DISTINCT FROM NEW.price)
EXECUTE FUNCTION log_price_change();      -- OLD and NEW hold both versions

The taxonomy every database shares, per the PostgreSQL and MySQL references: timing — BEFORE (may modify NEW or abort), AFTER (reacts to the committed row), INSTEAD OF (replaces the operation, mainly for views); event — insert, update, delete; granularity — row-level versus statement-level (a 10-row update fires a row trigger 10 times, a statement trigger once). Two semantics worth engraving: SQL triggers run inside the same transaction as the write — a trigger failure rolls the whole operation back — and AFTER triggers only fire for writes that actually succeeded.

Before vs. after: chosen by job

The corollaries no explainer states: a side effect in a before-hook is a bug by construction (the email sends, then the save fails), and an after-hook that isn’t idempotent is a duplicate counter waiting for a retry. In hook systems like Back4app’s, afterSave completes after the client already got its response — reactions are asynchronous by design, so their failures must be tolerable and logged.

Hooks vs. SQL triggers

The last row is the honest symmetry: each form’s guarantee is scoped to its layer. A SQL trigger catches even a rogue psql session but hides logic from application tooling; an API-level hook binds every client path through the backend but not raw database access — which is why platforms that own the API gateway (all traffic flows through it) get the practical best of both. The ORM footnote belongs here too: ORM hooks fire only through the ORM — bulk operations and raw SQL walk right past them.

The pitfalls, honestly

Hidden logic is the classic: a developer debugs their own code for hours while a trigger silently rewrites values — triggers are invisible at the call site, so document them and keep them few. Infinite loops: a trigger writing to its own table (or an afterSave saving its own object) re-fires itself; guard on what changed, and give recursion a terminating condition before it finds one for you. Synchronous cost: before-hooks sit inside every write’s latency — a 200 ms hook makes every save 200 ms slower, and bulk writes multiply row-level firings by the row count. Cascade chains: triggers that fire triggers that fire triggers turn one insert into an archaeology project. The umbrella rule from decades of practice: triggers enforce rules; the moment one starts orchestrating a workflow, move the workflow to functions or jobs and let the trigger just enqueue.

Common use cases

• Validation every client obeys — the stars-between-1-and-5 rule, enforced against forged requests and future SDKs alike.
• Audit trails — who changed what, when, written by the event itself rather than by cooperative clients.
• Denormalized counters and computed fields — averages, counts, and search-friendly duplicates kept true at write time.
• Cascading integrity — refuse deletes with children, or clean the children up after.
• Reactive side effects — an afterSave firing a push notification or an outgoing webhook: the database event becoming an integration event.

Which hook where? A decision matrix

Limitations and trade-offs

• Invisibility is the price of automaticity. Logic nobody calls is logic nobody remembers; naming, docs, and code review keep the magic auditable.
• Hooks scope to their layer. API hooks miss direct DB writes; SQL triggers miss nothing but hide from your tooling — know which blind spot you chose.
• Write latency is the budget. Every before-hook spends it; measure hooks like you measure queries.
• After-hooks are eventually consistent. Counters lag by milliseconds and can double-fire — design reads (and retries) accordingly.
• Triggers don’t replace constraints. Unique indexes, foreign keys, and ACLs enforce cheaper and earlier; triggers pick up where declarative rules stop.

Triggers on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Triggers here are the data-event family of Cloud Code: register Parse.Cloud.beforeSave('Review', …) once — the code tabs show the whole pattern — and the rule binds every write arriving through REST, GraphQL, any SDK, or the dashboard, because the API gateway is the one path to the data. Hooks receive rich context (request.object, request.original, request.user, master-key status), so validation can differ for admins, beforeFind can scope queries per user on top of ACLs, and after-hooks have the full JavaScript ecosystem for the reactions SQL triggers can’t reach — push notifications, outgoing webhooks, job enqueues. Deployed with your code, versioned in git, testable like any function: the trigger’s guarantee, without the trigger’s archaeology.