De flesta buggar som når produktion är inte smarta — de är tråkiga felmatchningar. API:et döpte om ett fält; frontenden läser fortfarande det gamla. Databaskolumnen är nullbar; koden antar att den inte är det. En ny parameter är obligatorisk; en gammal anropare skickar den aldrig. Var för sig triviala, sammantaget är de en enorm andel av incidenterna och de bortslösade felsökningstimmarna. Heltäckande typsäkerhet gör de flesta av dem omöjliga. Så här får vi det med tRPC och Drizzle.
Problemet: typerna stannar vid nätverksgränsen
I en typisk uppsättning är backenden och frontenden typade separat och kommer överens genom konvention. Kontraktet mellan dem — API:et — är där typer historiskt går för att dö. Team lappar över det med OpenAPI-specifikationer, genererade klienter eller handskrivna typer som driver isär i samma stund någon glömmer att regenerera. Gapet mellan “vad servern skickar” och “vad klienten väntar sig” är där buggarna bor.
tRPC: API:et som ett typat funktionsanrop
tRPC sluter det gapet. Du definierar dina backend-procedurer i TypeScript, och frontenden anropar dem som om de vore lokala funktioner — fullt typade, med autokomplettering, och utan kodgenereringssteg. Om du döper om ett fält eller lägger till en obligatorisk indata på servern blir varje berörd anropsplats på frontenden ett kompileringsfel omedelbart. Felmatchningen kan inte levereras eftersom bygget inte godkänns.
Det finns ingen schemafil att hålla i synk, ingen genererad klient att regenerera, ingen runtime-överraskning. Typerna är kontraktet, och de tvingas av kompilatorn.
Drizzle: databasen är också typad
Typsäkerhet som stannar vid databasen är bara halva historien. Drizzle ORM definierar ditt schema i TypeScript och gör dina frågor typkontrollerade: välj en kolumn som inte finns och bygget misslyckas; formen på varje frågeresultat är känd vid kompilering. Eftersom Drizzle är ett tunt, SQL-likt lager snarare än en tung abstraktion behåller du Postgres fulla kraft och prestanda — inklusive tillägg som pgvector för AI/RAG-funktioner — utan att slåss mot en ORM som döljer databasen för dig.
Kedjan som eliminerar buggklassen
Sätt ihop dem och typerna flödar obrutet från databasen, genom API:et, till gränssnittet:
Postgres-schema (Drizzle) → backend-procedur (tRPC) → frontend-anrop → komponentprops
Ändra något i den kedjan och kompilatorn pekar på varje ställe som behöver ändras. “API:et returnerade något frontenden inte väntade sig”-klassen av bugg — en av de vanligaste i webbappar — är borta genom konstruktion, inte genom noggrann testning.
”Men bromsar inte all den typningen er?”
Det är den vanligaste invändningen, och den är baklänges. Ja, du skriver typdefinitioner i förväg. Men du slutar skriva limkoden, den manuella klienten, runtime-valideringsställningen och — avgörande — du slutar felsöka felmatchningarna i produktion. Tiden flyttas från smärtsam, oförutsägbar felsökning till billig definition i förväg. Netto levererar team snabbare, och hastigheten håller när kodbasen växer i stället för att försämras.
Det gör också refaktorering orädd. Vill du forma om en central datastruktur sex månader in? Ändra den och följ kompileringsfelen. Utan heltäckande typer är samma refaktorering ett flerdagars arkeologiprojekt ingen frivilligt tar på sig.
Varför det spelar roll för ett företag, inte bara ingenjörer
Färre produktionsbuggar, snabbare iterationer och en kodbas som förblir refaktorerbar betyder lägre total ägandekostnad och en produkt som kan fortsätta utvecklas i stället för att frysa under sin egen vikt. Det är det verkliga skälet till att vi standardiserar på den här stacken — täckt tillsammans med resten i Den heltäckande TypeScript-stacken vi bygger med.
Om du startar ett bygge och vill att det ska förbli snabbt att ändra när det växer, är det så här vi sätter upp projekt från dag ett.
