Løser Prisma Error 500 på Vercel-distribusjon for ReactJS-prosjekter

Feilsøking av Prisma-databaseproblemer på Vercel-distribusjon

Å distribuere et prosjekt fra et lokalt utviklingsmiljø til en plattform som Vercel kan være et spennende skritt, som signaliserer at appen din nesten er klar for verden. 🌍 Det er imidlertid ikke uvanlig å møte uventede problemer underveis. For eksempel kan en build som fungerer perfekt på din lokale maskin plutselig støte på feil når den distribueres til en server.

Denne utfordringen er spesielt kjent når du arbeider med verktøy som Prisma for databasebehandling. Selv om Prisma gjør det enkelt å samhandle med databasen din lokalt, kan du distribuere den til en plattform som Vercel kan noen ganger utløse mystiske problemer, for eksempel den fryktede "Feil 500" når du prøver å få tilgang til databasen.

I mitt tilfelle, etter å ha satt opp Prisma med CockroachDB som datakilde, traff jeg en vegg under distribusjon: en vedvarende feilmelding, "Forespørsel mislyktes med statuskode 500," dukket opp når jeg forsøkte å samhandle med databasen. Selv om den samme koden fungerte lokalt, avslørte distribusjonsprosessen på Vercel et skjult problem.

I denne artikkelen skal vi dykke ned i hvordan jeg diagnostiserte og taklet dette problemet, ved å bruke eksempler fra virkeligheten for å illustrere feilsøkingstrinnene. Enten du støter på en lignende feil eller bare er nysgjerrig på vanlige Prisma-distribusjonsfeller, les videre for å lære mer! ⚙️

Forstå Prisma og Next.js-integrasjon for feilfrie Vercel-implementeringer

Det første skriptet handler om å håndtere API-forespørsler i Next.js ved hjelp av Prisma. I denne koden definerer vi et POST-endepunkt for å fange opp en e-postinndata og opprette en ny post i databasen. Her bruker Next.js-funksjonen `POST` metoden `await req.json()` for å analysere JSON-nyttelasten, slik at vi kan trekke ut e-postfeltet gitt av brukeren. Ved å pakke databasekallet inn i en `try`-`catch`-blokk, fanger dette oppsettet effektivt opp potensielle databasefeil, som er avgjørende for å overvåke for jevne distribusjoner. Uten denne feilhåndteringen kan problemer som dupliserte oppføringer bli ukontrollert, noe som kan føre til uklare serverfeil. En slik forsiktig håndtering av kjente feil, som unike begrensninger, hjelper til med å vise brukervennlige meldinger – avgjørende i apper som håndterer brukerdata regelmessig, som registreringsskjemaer eller kontaktlister. 📝

`PrismaClientKnownRequestError`-kontrollen i catch-blokken lar oss oppdage vanlige feil som å forsøke å legge til en allerede eksisterende e-post. Denne håndteringen forbedrer appens pålitelighet på Vercel ved å returnere en spesifikk 520-statuskode når en slik kjent feil oppstår, noe som gjør det lettere å finne og håndtere i frontend. `NextResponse.json()`-metoden sender svar i JSON-format, slik at vi kan tilpasse HTTP-statuser basert på feiltypen. Dette lar frontend-applikasjoner håndtere serverfeil konsekvent, og viser relevante meldinger til brukere uten å avsløre sensitive feildetaljer.

I det andre skriptet definerer koden hvordan Prisma kobles til databasen, enten det er i utvikling eller produksjon. Her bruker vi `globalThis` for å unngå å lage flere forekomster av `PrismaClient` under utvikling, som ellers kan forårsake minneproblemer med hyppige databasetilkoblinger. Ved å sette `globalThis.prisma = db` betinget, opprettholder applikasjonen en enkelt Prisma-forekomst per økt under utvikling. Til produksjon miljøer der minnelekkasjer fra flere tilkoblinger ville være enda mer problematisk, sikrer dette oppsettet en stabil, høyytende tilkobling til databasen. Slik modulær tilkoblingsadministrasjon er avgjørende når de distribueres til plattformer som Vercel, som optimerer miljøene deres for skalerbarhet. 🌐

Skjemafilen definerer hvordan databasen er strukturert. Ved å spesifisere CockroachDB som leverandør, kan Prisma generere optimaliserte spørringer for denne spesifikke databasemotoren. Modellen for "Kontakt"-tabellen bruker "e-post" som en unik identifikator med attributtene "@id" og "@unique", noe som tillater raske oppslag og sikrer at hver kontaktpost har en distinkt e-postadresse. Denne strukturen er effektiv for applikasjoner som trenger unike brukeroppføringer, for eksempel brukerautentiseringssystemer. I tillegg tildeler `@default(now())` automatisk et tidsstempel for opprettelse, som kan være nyttig for revisjonsformål eller bestilling av poster etter opprettelsesdato. Prismas skjemakonfigurasjon er optimalisert for både lokale og distribuerte miljøer, noe som gjør den svært tilpasningsdyktig til endringer.

Til slutt validerer enhetstester hver funksjon, og kontrollerer at databaseinteraksjoner fungerer som forventet og feilhåndtering er effektiv. For eksempel, ved å bruke Jests 'beskriv'- og 'forvente'-funksjoner, kan vi bekrefte at spesifikke databasesvar, for eksempel unike begrensningsfeil, returnerer riktig statuskode. I virkelige applikasjoner hjelper tester med å fange opp problemer tidlig, spesielt når du håndterer input som ellers kunne bryte en produksjonsdistribusjon. Disse enhetstestene dekker tilfeller som å opprette nye poster, administrere dupliserte data og returnere passende HTTP-statuser. På denne måten, selv om nye funksjoner legges til eller backend endres, bidrar testene til å sikre at API-en forblir pålitelig og feilfri.

import { db } from "@/lib/db";
import { Prisma } from "@prisma/client";
import { NextResponse } from "next/server";
export async function POST(req: Request) {
    try {
        const { email } = await req.json();
        const contact = await db.contact.create({
            data: { email }
        });
        return NextResponse.json(contact);
    } catch (error) {
        if (error instanceof Prisma.PrismaClientKnownRequestError) {
            console.log("[CONTACT]", "Email already exists");
            return NextResponse.json({ message: "Email already exists" }, { status: 520 });
        } else {
            console.log("[CONTACT]", error);
            return NextResponse.json({ message: "Server error" }, { status: 500 });
        }
    }
}

import { PrismaClient } from "@prisma/client";
declare global {
    var prisma: PrismaClient | undefined;
};
export const db = globalThis.prisma || new PrismaClient();
if (process.env.NODE_ENV !== "production") globalThis.prisma = db;

generator client {
    provider = "prisma-client-js"
}
datasource db {
    provider      = "cockroachdb"
    url           = env("DATABASE_URL")
    relationMode  = "prisma"
}
model Contact {
    email         String  @id @unique
    creation      DateTime @default(now())
}

import { db } from "@/lib/db";
import { POST } from "@/pages/api/contact";
import { NextResponse } from "next/server";
describe("POST /api/contact", () => {
    it("should create a new contact and return the data", async () => {
        const request = new Request("http://localhost/api/contact", {
            method: "POST",
            body: JSON.stringify({ email: "test@example.com" }),
        });
        const response = await POST(request);
        const data = await response.json();
        expect(data.email).toBe("test@example.com");
    });
    it("should handle known Prisma errors (e.g., duplicate email)", async () => {
        const request = new Request("http://localhost/api/contact", {
            method: "POST",
            body: JSON.stringify({ email: "duplicate@example.com" }),
        });
        const response = await POST(request);
        expect(response.status).toBe(520);
    });
});

Optimalisering av Prisma- og Vercel-distribusjoner for pålitelig produksjon

Distribuere applikasjoner med Prisma og Vercel bringer en kraftig, fleksibel kombinasjon for håndtering av databaser i produksjonsmiljøer. Forskjeller mellom lokal utvikling og servermiljøer kan imidlertid føre til problemer som en status 500-feil ved tilgang til databasen. Denne feilen stammer ofte fra databasetilkoblingskonfigurasjoner som ikke stemmer overens mellom miljøer eller manglende miljøvariabler i Vercels innstillinger. For å forhindre slike problemer er det viktig å forstå hvordan Prisma håndterer tilkoblinger i produksjon, spesielt når du bruker en skydatabase som CockroachDB. I motsetning til lokal utvikling, kan produksjonsdatabaser ha ekstra sikkerhet eller tilkoblingsbegrensninger som kan påvirke Prismas tilkoblingsatferd.

Et annet viktig aspekt er å administrere Prisma-klientforekomsten effektivt. Under utvikling er det vanlig å reinitialisere Prisma hver gang en fil endres, men dette kan forårsake minnelekkasjer i et produksjonsmiljø. Med plattformer som Vercel som ofte omstarter forekomster, hjelper bruk av `globalThis` i konfigurasjonsfilen til å begrense Prisma-klientinitialiseringen til en enkelt forekomst. Innstilling DATABASE_URL sikkert gjennom Vercels miljøvariabler og bruk av den innenfor `schema.prisma` sikrer at databaselegitimasjonen din er tilgjengelig samtidig som sikkerheten opprettholdes. Dette er spesielt aktuelt for prosjekter med brukerdata, hvor sikkerhet er avgjørende. 🔒

Optimalisering av distribusjonsinnstillinger og håndtering av feilhåndtering for kjente problemer, som dupliserte poster, bidrar til å sikre at applikasjonen din kjører jevnt. For eksempel, i produksjon, vil du kanskje fange Prisma-feil ved å bruke `PrismaClientKnownRequestError` for å returnere klare, brukervennlige meldinger til frontend. Ved å finjustere Prisma-konfigurasjonen og håndtere miljøspesifikke innstillinger riktig, kan du forhindre 500-feilene og sikre en mer pålitelig databasetilkobling. Testing av ulike deler av applikasjonen, spesielt databaseinteraksjoner, gir trygghet til distribusjonsstabiliteten. 🛠️