Si e prisha pa dashje faqen time personale të internetit
(Dhe si rindërtimi i saj më mësoi gjithçka që nuk e dija se më duhej)
Kur nisa të ndërtoja faqen time personale të internetit, qëllimi ishte i thjeshtë: të krijoja një shtëpi digjitale për punën, projektet dhe, më vonë, idetë e mia. Si shumica e projekteve anësore, ajo nisi si një portofol statik. Faqe të shkruara drejtpërdrejt në kod. HTML me komponentë React të shpërndarë këtu e atje. Funksiononte, por çdo përditësim kërkonte të ndërhyja në kod. Për të shtuar një shembull të ri pune, duhej të hapja një skedar. Për të përditësuar fundfaqen, duhej ta publikoja sërish aplikacionin. Nuk më dukej një faqe me të cilën mund të punoja rehat. Doja diçka më dinamike: një CMS të mirëfilltë që mund ta kontrolloja nga shfletuesi.
Pikërisht atëherë më pëlqeu ideja e përdorimit të Next.js App Router, Prisma dhe Supabase. Renderim modern me React, modele me tipe të përcaktuara fort, një bazë të vërtetë të dhënash dhe autentikim me email e fjalëkalim. Brenda një fundjave, kisha një panel administrimi funksional, ku mund të shtoja përvoja, mjete dhe aplikacione pa hapur VS Code. Më dukej si magji.
Kalimi në një faqe dinamike (me shpejtësi) Prisma e bëri të thjeshtë modelimin e përmbajtjes sime. Krijova modelet: Post Experience WorkSample WebApp Tool SiteSettings Supabase merrej me autentikimin me email e fjalëkalim, ndërsa komponentët server të Next.js e bënin të lehtë ndërtimin e rrugëve të mbrojtura. Brenda pak ditësh, kisha: një sistem blogu një panel administrimi të tipit CMS një menaxhues përvojash një seksion mjetesh dhe aplikacionesh një fundfaqe që ngarkohej nga baza e të dhënave Në momentet më të mira, faqja dukej si një produkt i vërtetë. Kur gjithçka dukej në rregull… derisa nuk ishte më Pastaj, papritur… gjithçka u prish. Faqet që më parë ngarkoheshin ishin bosh. Administrimi i blogut shfaqte gabime të kuqe nga Prisma. Paneli thoshte: “Database connection is not configured.” edhe pse DATABASE_URL e kisha të përcaktuar. Faqja kryesore rrëzohej me gabimin: “Cannot read properties of undefined (reading ‘slice’)” Faqja e aplikacioneve me temë të errët nuk ngjante aspak me pjesën tjetër të faqes. Lidhjet në krye i dërgonin vizitorët në rrugë të gabuara. Fundfaqja ishte zhdukur fare. Për njëfarë kohe, më dukej sikur po shuaja zjarre pa e ditur nga vinte tymi. Problemet e para që gjeta Pasi kërkova më thellë, zbulova dy shkaqe të para: 1. Variabla mjedisi të pasakta ose të munguara Prisma nuk inicializohet nëse DATABASE_URL mungon ose është e gabuar, shpesh pa e bërë të qartë arsyen. Kisha ndryshuar fjalëkalimin e Supabase (zakon i mirë), por kisha harruar të përditësoja variablat e mjedisit në Netlify. Prandaj paneli i administrimit nuk lidhej, raportonte “database not configured” dhe nuk ngarkonte përvojat, postimet apo regjistrat e auditimit. Përditësimi i adresës së lidhjes në të gjitha mjediset e zgjidhi menjëherë këtë pjesë. 2. Migrime që nuk ishin zbatuar kurrë Edhe kur autentikimi funksiononte, tabelat e mia nuk funksiononin. Nuk i kisha zbatuar migrimet në bazën e të dhënave në prodhim, ndaj Prisma vazhdonte të jepte mesazhin: “Unable to load posts. Verify your DATABASE_URL and run pnpm prisma migrate deploy.” Ekzekutimi i migrimeve krijoi më në fund tabelat që mungonin dhe paneli i administrimit u rikthye në jetë. Por kjo ishte vetëm sipërfaqja e problemit të vërtetë. Problemi i thellë: një bazë të dhënash e ndarë mes dy botësh Gjërat u bënë vërtet interesante ditën kur klonova projektin me Lovable.dev, një mjet që mund të gjenerojë dhe të ristrukturojë automatikisht projekte të tëra. Për habinë time: Versioni i Lovable funksiononte në mënyrë të përsosur. Versioni im origjinal… jo. Të dy ishin të lidhur me të njëjtën bazë të dhënash Supabase, por njëri funksiononte dhe tjetri jo. Atëherë e kuptova: Projekti im kishte një konfigurim baze të dhënash të përzier si një Frankenstein. Me kalimin e kohës, kisha: kaluar nga SQLite → Postgres ndryshuar adresat e lidhjes bashkuar kodin e vjetër me kodin e ri grumbulluar migrime që nuk përputheshin me njëri-tjetrin Disa skedarë migrimi të Prisma përmbanin ende SQL për SQLite, si: INTEGER PRIMARY KEY AUTOINCREMENT DATETIME DEFAULT CURRENT_TIMESTAMP Prisma përpiqej t'i zbatonte në PostgreSQL, gjë që, natyrisht, dështonte. Kjo shpjegonte vargun e pafund të gabimeve. Zgjidhja e vërtetë: rivendosje dhe rindërtim i plotë Në fund, e vetmja zgjidhje e vërtetë ishte ajo që po përpiqesha vazhdimisht të shmangia: Ta rivendosja të gjithë bazën e të dhënave dhe të nisja nga e para. Ja çfarë bëra konkretisht: Hoqa të gjitha tabelat e përmbajtjes në Supabase Fshiva çdo migrim të vjetër të Prisma, duke mbajtur vetëm migration_lock.toml Hoqa tabelën _prisma_migrations në Supabase E lashë Prisma të rindërtonte gjithçka me: npx prisma migrate dev --name init Rigjenerova Prisma Client Rilidha panelin e administrimit Testova rrjedhën e të dhënave nga paneli → Supabase → faqja publike Këtë herë, gjithçka përputhej në mënyrë të përsosur. Migrimet ishin të sakta. Skema përputhej me bazën e të dhënave. Autentikimi i Supabase funksiononte. Paneli i administrimit më në fund ngarkohej pa asnjë paralajmërim. Për herë të parë pas javësh, çdo faqe funksiononte dhe rifreskimi nuk shfaqte asnjë gabim të kuq. Rregullimi i ndërfaqes gjatë rrugës Disa probleme të ndërfaqes nuk lidheshin me bazën e të dhënave: Shiriti i sipërm i panelit u prish sepse një komponent klient ishte mbështjellë nga një komponent server. Shembujt e punës rrëzonin faqen kryesore sepse thërrisja .slice() mbi undefined. Kryefaqja, fundfaqja dhe faqet e mjeteve e aplikacioneve nuk kishin një pamje të njëtrajtshme. Lidhjet e navigimit të çonin në rrugë që nuk ekzistonin më. Ndërsa rindërtoja pjesën e serverit, pastrova edhe ndërfaqen: Riktheva ndërveprimin duke i mbajtur komponentët klient aty ku duhej Shtova kontrolle për vlera bosh (title?.slice(0,160)) Rindërtova faqet e mjeteve dhe aplikacioneve me strukturën kryesore të faqes Shtova një fundfaqe rezervë që shfaqet gjithmonë, edhe kur baza e të dhënave është bosh Përditësova lidhjet e navigimit drejt rrugëve kanonike Faqja më në fund dukej sërish e unifikuar. Çfarë mësova nga rindërtimi i gjithçkaje Duke parë pas, mësova më shumë nga prishja e faqes sesa nga ndërtimi i saj: 1. Qëndrueshmëria e një faqeje dinamike varet nga variablat e mjedisit. Një DATABASE_URL e gabuar rrëzoi të gjithë panelin e administrimit. 2. Migrimet nuk janë sugjerime: duhen zbatuar me përpikëri. Edhe nëse skema ka një model, ai nuk ekziston në bazën e të dhënave derisa të ekzekutohet migrimi. 3. Përzierja e migrimeve të SQLite dhe Postgres është recetë për kaos. Një AUTOINCREMENT i vetëm mund të prishë të gjithë publikimin në prodhim. 4. Komponentët klient mund të pushojnë së funksionuari pa sinjal të qartë kur mbështillen gabim. Problemet e hidratimit janë reale. 5. Njëtrajtshmëria është më e vlefshme se zgjidhjet e zgjuara. Një strukturë e unifikuar është më e mirë se një koleksion faqesh të bukura, por të shkëputura nga njëra-tjetra. 6. Rivendosja dhe nisja nga e para është ndonjëherë rruga më e shpejtë përpara. Është e dhimbshme. Është e frikshme. Por ndonjëherë është e nevojshme. Pjesa më e mirë: faqja tani është më e mirë se kurrë Ajo që nisi si: një portofol statik u bë një CMS dinamik pastaj u prish dhe më pas u shndërrua në një platformë më të pastër, më të lehtë për t'u mirëmbajtur dhe me baza të forta Kishte momente zhgënjimi, por edhe momente jashtëzakonisht shpërblyese: ato çaste kur gjithçka funksionon sërish pas orësh (ose ditësh) kërkimi dhe zgjidhjeje gabimesh. Nëse po ndërton faqen tënde: Prit që të prishet. Prit të ndjekësh probleme që nuk i kishe imagjinuar kurrë. Prit të rivendosësh gjëra të paktën një herë. Dhe prit të mësosh shumë më tepër nga sa kishe planifikuar. Sepse kjo është vlera e vërtetë e një projekti personal: jo vetëm ajo në të cilën shndërrohet, por edhe ajo që të mëson gjatë rrugës.