Deszcz czy Prisma? Sprawdź typ połączenia oraz zapisany SQL przed podjęciem decyzji.

Debaty na temat ORM zwykle toczą się wokół wykresów pobierania danych i hasłów konferencyjnych, jednak pytanie istotne w środowisku produkcyjnym jest znacznie prostsze: gdy łączysz użytkownika z jego fakturami, jaki typ ma total, i czy możesz odczytać SQL, który go wygenerował? Ten przewodnik tworzy te same dwie tabele w Drizzle i Prisma, wykonywa w każdym z nich jedną operację wprowadzania danych i jedno połączenie, a następnie porównuje typy TypeScript wywnioskowane przez narzędzia, zapisane zapytania, wyniki migracji oraz zachowanie w czasie wykonywania kodu w natywnym środowisku TypeScript Node’a. Otrzymasz krótkie, powtarzalne ćwiczenie, które odpowiada na pytanie dotyczące ORM dla twojego własnego kodu, a nie na podstawie benchmarków kogoś innego. Aby uzyskać szerszą ramę decyzyjną, która uwzględnia również surowy SQL, zapoznaj się z wskazówkami dotyczącymi wyboru warstwy bazodanowej pomiędzy surowym SQL, Prismą i Drizzle.

Dla czego optymalizuje się każde narzędzie

Dwie te biblioteki dają różne obietnice. Drizzle oferuje kod zapytań przypominający SQL napisany w TypeScript, bez oddzielnego procesu silnika zapytań oraz projekt dostosowany do środowisk edge. Prisma zapewnia podejście oparte na schemacie, wykorzystujące specjalny plik schema.prisma oraz generowany klient; w najnowszych wersjach silnik zapytań przenosi się od Rustu ku TypeScriptowi. W momencie pisania tego tekstu ta migracja wciąż trwała, dlatego sprawdź aktualne notatki wydawnicze Prismy, aby dowiedzieć się, jaki silnik jest używany w danej wersji.

Popularność też ma dwa oblicza: Prisma wciąż przewodzi pod względem liczby zainstalowań, natomiast Drizzle dominuje w dyskusjach na temat wzrostu. Nic z tego nie mówi nic o Twoim dołączeniu. Dwa kryteria użyte poniżej są celowo wąskie i praktyczne: to, czy total przychodzi w formie number, oraz to, czy SQL z logu to coś, co chętnie wkleiłbyś do psql podczas incydentu.

Sytuacja dotyczy małej aplikacji do wystawiania faktur, w której strona /invoices musi wyświetlić łączną kwotę. Coś w architekturze musi nadać tej kwocie odpowiedni typ, i właśnie tutaj zaczyna się porównanie.

Dwie te same tabele, dwa razy

Utwórz dwie oddzielne foldery projektów wobec tej samej instancji PostgreSQL i nadaj każdemu własną nazwę schematu. Dzielenie się tablicami między dwoma ORM prowadzi do powstania podwójnie zapisanych wierszy, które wyglądają jak dane dotyczące wydajności, ale w rzeczywistości są błędami.

W Drizzle schemat znajduje się w pliku src/schema.ts jako zwykły kod TypeScript. Zauważ, że nazwy kolumn są deklarowane wyraźnie w formacie snake_case (user_id), podczas gdy właściwość ma format camelCase (userId), a klucz obcy to odwołanie do funkcji users.id:

import { integer, pgTable, uuid, varchar } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: uuid("id").primaryKey().defaultRandom(),
  email: varchar("email", { length: 255 }).notNull().unique(),
});

export const invoices = pgTable("invoices", {
  id: uuid("id").primaryKey().defaultRandom(),
  userId: uuid("user_id").notNull().references(() => users.id),
  total: integer("total").notNull(),
});

W Prisma ten sam model znajduje się w pliku prisma/schema.prisma. Związek jest deklarowany po obu stronach: User ma tablicę invoices, a Invoice zawiera wartość skalarową userId wraz z tagiem @relation, który łączy je ze sobą:

model User {
  id       String    @id @default(uuid())
  email    String    @unique
  invoices Invoice[]
}

model Invoice {
  id     String @id @default(uuid())
  userId String
  total  Int
  user   User   @relation(fields: [userId], references: [id])
}

A teraz zapytanie, które jest istotne: pobranie faktur użytkownika na podstawie adresu e-mail. Drizzle realizuje to poprzez wyraźne połączenie wewnętrzne z klauzulą where, natomiast Prisma prosi o dostarczenie użytkownika i dodaje instrukcję „włącz faktury”:

// drizzle
const rows = await db
  .select()
  .from(invoices)
  .innerJoin(users, eq(invoices.userId, users.id))
  .where(eq(users.email, email));

// prisma
const user = await prisma.user.findUnique({
  where: { email },
  include: { invoices: true },
});

Rodzaje wyników odzwierciedlają te dwa modele myślowe. Drizzle zwraca wiersze w formie połączenia tabel, gdzie każdy wiersz zawiera klucz users oraz klucz invoices. Prisma zwraca User & { invoices: Invoice[] }, czyli zagnieżdżony obiekt. Obie metody są poprawne. Struktura danych w Drizzle odpowiada SQL, natomiast struktura w Prismie odpowiada stronie, którą zamierzasz wyświetlić.

Gdy jest włączone logowanie zapytań, różnica utrzymuje się. Wynik generowany przez Drizzle to połączenie tabel, które programista może bezpośrednio odczytać. Wynik Prismy jest w pełni użyteczny, ale stanowi SQL wygenerowany automatycznie, którego nie chciałoby się edytować ręcznie.

Migracje przebiegły bez problemów przy tak małym schemacie. drizzle-kit generate wygenerował pliki SQL, które można zapisać; prisma migrate stworzył własną historię migracji, którą również można zapisać. Żaden z tych narzędzi nie miał trudności z dwiema tabelami, a schemat takiej wielkości nie pozwala na wykrycie trudniejszych przypadków migracji, więc nie należy wyciągać z tego żadnych wniosków.

Odtworzenie laboratorium lokalnie

Zainstaluj każdy zestaw narzędzi w osobnej folderze. Drizzle wymaga ORM, sterownika (tutaj postgres) oraz drizzle-kit do przeprowadzania migracji; Prisma wymaga interfejsu wiersza poleceń oraz klienta, a następnie prisma init do utworzenia szkieletu pliku schematu:

pnpm add drizzle-orm postgres
pnpm add -D drizzle-kit

pnpm add prisma @prisma/client
pnpm exec prisma init

W każdej folderze należy dodać jednego użytkownika i dwie faktury, wykonać operację połączenia raz oraz wyświetlić wartość total pierwszej faktury wraz z jej typem w czasie wykonywania. Zwróć uwagę na różne ścieżki dostępu: rows[0].invoices.total w przypadku rzędów połączonych przez Drizzle, natomiast user.invoices[0].total w przypadku zagnieżdżonego obiektu w Prismie.

console.log(rows[0]?.invoices.total, typeof rows[0]?.invoices.total);
console.log(user?.invoices[0]?.total, typeof user?.invoices[0]?.total);

Jeśli jedno narzędzie raportuje typ string, a drugie number, przyczyną jest niemal zawsze mapowanie typów dostawcy bazy danych, a nie filozofia ORM. Dostawcy PostgreSQL często zwracają kolumny typu bigint i numeric jako łańcuchy, aby uniknąć utraty precyzji liczby w JavaScript, podczas gdy zwykłe kolumny typu integer wracają jako liczby. Suma w formie łańcucha to sytuacja, gdy "1200" + 50 potajemnie zamienia się na "120050" w fakturze. Zapisz wynik typeof przed wyborem biblioteki.

Uruchamianie pliku z zapytaniem za pomocą natywnego TypeScript

Następnie sprawdź, czy kod działa bezpośrednio przy użyciu wbudowanego w Node mechanizmu usuwania informacji typowych, który uruchamia pliki .ts, usuwając adnotacje typowe bez konieczności osobnego procesu budowania aplikacji:

node src/query.ts

Moduł Drizzle składający się wyłącznie z funkcji i adnotacji typów działał bez problemów. Klient Prisma wygenerowany do katalogu node_modules również funkcjonował po wywołaniu z małego wrappera. Problem pojawił się w przypadku pliku, który importował enumy wygenerowane przez Prisma w starszym stylu. Deklaracje enum w TypeScript to nie tylko typy; są one kompilowane do obiektów w czasie wykonywania, a tryb strip-only w Node nie może ich usunąć, przez co wykonywanie programu zawodzi. To nie jest wada Prisma, lecz cecha kodu generowanego do czasu wykonywania. Jeśli twoja wersja Prisma używa nowszego silnika i generatora opartych na TypeScript, sprawdź, co faktycznie wytwarza polecenie prisma generate, zanim założysz, że to nadal ma zastosowanie, oraz określ dokładną wersję, którą testowałeś.

Włączanie logowania zapytań

Domysły dotyczące SQL powodują, że incydenty się przedłużają. Obie biblioteki mogą rejestrować każde zapytanie – Drizzle za pomocą opcji logger, a Prisma poprzez tablicę log w klienta:

const db = drizzle(client, { logger: true });
const prisma = new PrismaClient({ log: ["query"] });

Umieść obie zapisane strony SQL obok dwóch wyników typeof total. Te cztery linie stanowią cały zestaw danych potrzebny w tym laboratorium.

Koszty posługiwania się każdym narzędziem

Kompromisy pojawiły się w pięciu obszarach.

Typy danych. Funkcja include w Prismie dostarczyła dokładnie taką strukturę, jakiej wymagała strona /invoices. Operacja łączenia w Drizzle dała dokładnie taki wynik, jakiego potrzebujesz podczas debugowania sytuacji, gdy suma się podwoiła. Obie metody są przydatne w różnych sytuacjach, co jest argumentem za wyborem jednej biblioteki na każdą bazę danych, a nie za używaniem obu do obsługi tych samych tabel.

Gdy suma wygląda niepoprawnie, dzięki czytelnej zapytaniu log Drizzle szybciej rozstrzyga ten problem. Gdy nowy członek zespołu musi dodać pole, plik schematu Prismy jest szybszym rozwiązaniem. To różne sytuacje, w których zwycięzca jest inny.

node -v
pnpm exec tsc -v
pnpm exec next --version

pnpm exec next dev

pnpm exec tsc --noEmit --pretty false
echo $?