RPC i moderne webudvikling: Hvorfor vi går tilbage til rødderne

I mange år har debatten handlet om REST vs. GraphQL. Men i 2026 ser vi en markant bevægelse mod noget meget ældre: RPC (Remote Procedure Call).

Hvis du arbejder med moderne værktøjer som Supabase, serverless functions eller endda bare komplekse B2B-systemer, så er RPC sandsynligvis det værktøj, du har ledt efter uden at vide det.

Hvad er RPC egentlig?

Simpelt forklaret: RPC lader dig kalde en funktion på en anden maskine (serveren), som om den var lokal på din egen maskine (klienten).

I stedet for at tænke i "ressourcer" (REST) eller "grafer" (GraphQL), tænker du i aktioner. Du siger ikke "OPDATER /users/123", du siger "Kald funktionen arkivér_bruger(123)".

Hvorfor er det relevant nu?

Der er tre hovedårsager til, at RPC er blevet uundværligt i moderne web-arkitektur:

1. Atomicitet og komplekse handlinger

Forestil dig en invitation i et B2B-system. Du skal både:

1. Tjekke om der er ledige pladser (billing).
2. Oprette en invitations-række.
3. Sende en e-mail.
4. Logge handlingen i en audit log.

Hvis du gør dette via REST fra frontenden, risikerer du, at noget fejler halvvejs (et "race condition"). Med RPC samler du alt logikken i én atomar database-funktion. Enten sker det hele, eller også sker intet.

2. Sikkerhed og "Security Definers"

Med værktøjer som Supabase kan du køre RPC-funktioner som en SECURITY DEFINER. Det betyder, at funktionen kører med højere privilegier end den normale bruger, men kun inden for de strengt definerede rammer af funktionen.

CREATE FUNCTION accept_invitation(invite_token TEXT)
RETURNS void
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = ''  -- KRITISK: Forhindrer privilege escalation
AS $$
BEGIN
  -- Kun denne funktion kan opdatere invitations-tabellen
  UPDATE public.invitations 
  SET accepted_at = NOW()
  WHERE token = invite_token;
END;
$$;
 
-- Fjern direkte skriveadgang
REVOKE UPDATE ON invitations FROM authenticated;

Sikkerhedsadvarsel: Uden SET search_path = '' kan en angriber oprette ondsindede funktioner i public-schema, der maskerer legitime funktioner. Dette er en kritisk sårbarhed i SECURITY DEFINER funktioner.

Dette fjerner behovet for at give frontenden adgang til følsomme tabeller via RLS (Row Level Security), da kun funktionen har adgang.

3. Performance og Developer Experience

I 2026 er vi trætte af "over-fetching". Men vi er også trætte af kompleksiteten i GraphQL's caching. RPC giver dig det bedste fra begge verdener:

• Præcis data: Du returnerer præcis det, funktionen har brug for.
• Type-sikkerhed: Med TypeScript og værktøjer som Supabase-js får du autocompletion på dine database-funktioner direkte i din kode.

Hvornår skal du bruge hvad?

Konklusion

RPC er ikke en erstatning for REST eller GraphQL, men det er det manglende led i mange moderne backends. Ved at flytte din vigtigste forretningslogik ind i veldefinerede funktioner på serveren (eller direkte i databasen), gør du din app mere sikker, hurtigere og langt nemmere at vedligeholde.