CRUD

Samma fyra idéer i tre vokabulär

Värdet i förkortningen är att den översätts rent mellan lager:

• Create – SQL INSERT, HTTP POST.
• Read – SQL SELECT, HTTP GET.
• Update – SQL UPDATE, HTTP PUT för en fullständig ersättning eller PATCH för en delvis.
• Delete – SQL DELETE, HTTP DELETE.

Ett REST-API är i grunden CRUD uttryckt över HTTP. I en NorthernGo-app dyker samma operationer upp som window.NorthernGoDB.save(collection, data), .get(collection) och .delete(collection, field, value) – skapa, läsa och ta bort, där en uppdatering uttrycks som en sparning över en befintlig post.

Där CRUD slutar räcka

Två fallgropar är värda att namnge.

Att ta bort är sällan så enkelt som det låter. De flesta system i drift raderar mjukt – sätter en tidsstämpel i deleted_at och filtrerar bort raden – eftersom verklig radering bryter främmande nycklar, förstör spårbarhet och inte går att ångra efter en felklickning. Men om datan är personuppgifter uppfyller en mjuk radering inte en begäran om radering enligt GDPR, eftersom posten fortfarande finns. Att avgöra vilka rader som ska gå att återställa och vilka som måste försvinna på riktigt är ett designbeslut, inte en implementationsdetalj.

Allt är inte en postredigering. "Säg upp prenumerationen", "publicera artikeln" och "återbetala ordern" innebär tillståndsövergångar, sidoeffekter och regler för vad som är tillåtet från nuvarande läge. Att modellera dem som en naken uppdatering av en statuskolumn brukar sprida ut den logiken över kodbasen. Det är här team i stället väljer domänspecifika endpoints eller en händelsebaserad modell.

Missuppfattningen

CRUD är en beskrivning, inte en arkitektur. Att kalla en app "bara CRUD" undervärderar den oftast: validering, behörigheter, samtidiga ändringar, sidindelning och ändringshistorik är där arbetet ligger, och alla fyra bokstäverna ser triviala ut tills två användare uppdaterar samma rad samtidigt.