CRUD

The same four ideas in three vocabularies

The value of the acronym is that it maps cleanly across layers:

• Create — SQL INSERT, HTTP POST.
• Read — SQL SELECT, HTTP GET.
• Update — SQL UPDATE, HTTP PUT for a full replacement or PATCH for a partial one.
• Delete — SQL DELETE, HTTP DELETE.

A REST API is essentially CRUD expressed over HTTP. In a NorthernGo app the same operations appear as window.NorthernGoDB.save(collection, data), .get(collection) and .delete(collection, field, value) — create, read and delete, with an update expressed as a save over an existing record.

Where CRUD stops being enough

Two failure modes are worth naming.

Deleting is rarely as simple as it sounds. Most production systems soft delete — set a deleted_at timestamp and filter it out — because real deletion breaks foreign keys, destroys audit trails and cannot be undone after a misclick. But if the data is personal, a soft delete does not satisfy a request for erasure under GDPR; the record still exists. Deciding which rows are recoverable and which must really disappear is a design decision, not an implementation detail.

Not everything is a record edit. "Cancel a subscription", "publish an article", "refund an order" each involve state transitions, side effects and rules about what is permitted from the current state. Modelling them as a bare update on a status column tends to scatter that logic across the codebase. This is the point where teams reach for domain-specific endpoints or an event-based model instead.

The misconception

CRUD is a description, not an architecture. Saying an app is "just CRUD" usually undersells it: validation, permissions, concurrent edits, pagination and audit history are where the real work lives, and all four letters look trivial until two users update the same row at the same time.