Ce se află de fapt înăuntrul unei aplicații construite cu IA: un tur pentru nedezvoltatori

Ai tastat o descriere, ai apăsat „go”, iar douăzeci de minute mai târziu aveai o aplicație funcțională. Grozav. Dar acum ai dat clic pe „vezi fișierele” și te holbezi la un arbore de foldere care pare scris într-o altă limbă. Ce e package.json? De ce sunt patruzeci de lucruri în node_modules? Ce înseamnă „schemă” și de ce ai una?

Articolul ăsta e un tur ghidat. Nu un tutorial — un tur. După ce-l citești, n-o să știi cum să scrii vreunul dintre fișierele astea tu însuți, dar data viitoare când ceva arată ciudat, vei ști spre ce colț al aplicației să arăți.

O să folosesc trei exemple recurente pe tot parcursul, ca părțile abstracte să aibă ceva concret de care să se agațe:

• Maya, șefă de marketing, care a construit un clasament de recomandări pentru echipa ei.
• Jordan, profesor de yoga, care a construit un site de rezervare a cursurilor.
• Sam, care conduce o brutărie, care a construit o pagină de „pre-comandă pentru croasantele de mâine”.

Toți trei au folosit un creator de aplicații cu IA. Toate cele trei aplicații arată complet diferit pentru un client. Sub capotă, sunt construite surprinzător de asemănător.

Frontend-ul: ce vede de fapt clientul tău

Frontend-ul e tot ce se încarcă în browserul cuiva. Butoane, aspecte, fonturi, animații, felul în care un formular se golește singur după ce-l trimiți. Dacă o poți vedea, e frontend.

Pentru Maya, frontend-ul e un clasament cu rang, nume și număr de recomandări. Pentru Jordan, e un calendar de cursuri cu un buton „rezervă”. Pentru Sam, e o listă de produse de patiserie cu mici butoane de plus și minus lângă fiecare.

În interiorul proiectului, frontend-ul trăiește de obicei într-un folder numit cumva app/, pages/ sau src/. Vei vedea fișiere care se termină în .tsx sau .jsx. Fiecare e cam „un ecran” sau „o bucată dintr-un ecran”. Rândul din clasament e un fișier. Antetul e alt fișier. Pagina care le leagă pe toate la un loc e al treilea.

Când îi ceri creatorului cu IA să „facă butoanele mai rotunde” sau să „mute clasamentul la dreapta”, asta e partea care se schimbă.

Backend-ul: partea care gândește

Backend-ul e partea pe care n-o vede nimeni, dar de care depind toți. E codul care rulează altundeva — pe un server, nu în browserul clientului — atunci când trebuie să se întâmple ceva în care nu se poate avea încredere că browserul clientului face singur.

De ce nu poate face browserul totul? Fiindcă browserul e mașina clientului, iar în el nu poți avea încredere. Dacă clasamentul Mayei ar actualiza numărul de recomandări exclusiv în browser, oricine ar putea da clic dreapta și să-și adauge 9.000 de recomandări. Așa că backend-ul e locul unde trăiesc regulile: „persoana asta poate face asta, dar nu și aia”, „chiar salvează asta în baza de date”, „trimite e-mailul ăsta”.

Backend-ul trăiește de obicei într-un folder numit api/, server/ sau app/api/. Fișierele de acolo sunt de obicei scurte. Fiecare gestionează o cerere specifică: „creează o rezervare”, „enumeră croasantele de azi”, „adaugă o recomandare”.

Când ceva funcționează în aplicația ta, dar rezultatul nu rămâne — apeși trimite, vezi o confirmare, dar mâine datele au dispărut — backend-ul e aproape întotdeauna locul unde stă bug-ul.

Baza de date: memoria aplicației tale

Imaginează-ți memoria aplicației tale ca pe un șir de dulapuri cu sertare. Fiecare dulap are o etichetă în față. Unul spune „utilizatori”. Unul spune „rezervări”. Unul spune „comenzi_croasante”. În interiorul fiecărui dulap, fiecare sertar e un rând. Fiecare sertar are același set de compartimente: un nume, un e-mail, o dată de creare, un status.

Structura aceea — „ce dulapuri există, ce compartimente are fiecare rând” — se numește schemă. E cel mai important fișier din proiect, chiar dacă e probabil și cel mai plictisitor la înfățișare. Găsește un fișier numit schema.ts, schema.prisma sau ceva dintr-un folder numit db/ sau migrations/. Deschide-l. Vei vedea o listă care oglindește ce-și amintește de fapt aplicația ta despre lume.

Schema lui Jordan are un tabel classes, un tabel bookings și un tabel users. A lui Sam are products, orders și order_items. A Mayei are members și referrals. Forma schemei e forma produsului, motiv pentru care s-o schimbi mai târziu e mai greu decât să schimbi cum arată butoanele.

Un truc util: dacă poți descrie ce-și amintește aplicația ta, în cuvinte simple, de obicei poți descrie schema. „Îmi amintesc numele și e-mailul fiecărui client. Pentru fiecare client, îmi amintesc comenzile pe care le-a plasat. Pentru fiecare comandă, îmi amintesc ce produse de patiserie și câte din fiecare.” Fraza aceea e, aproape cuvânt cu cuvânt, schema.

Auth: bodyguardul de la ușă

„Auth” sunt două cuvinte lipite la un loc: authentication (autentificare — cine ești?) și authorization (autorizare — ce ai voie să faci?). Ambele sunt de obicei gestionate de un mic set de fișiere dintr-un folder numit auth/ sau de un serviciu al cărui nume s-ar putea să-l recunoști: Clerk, Auth0, Supabase Auth, NextAuth.

Cele două întrebări sunt diferite. Autentificarea răspunde: „chiar e Maya asta?” — de obicei cu o parolă, un login Google sau un link magic trimis pe e-mailul ei. Autorizarea răspunde: „are Maya voie să șteargă recomandările altora?” — iar răspunsul sincer pentru majoritatea aplicațiilor construite cu IA în prima lor săptămână e „am uitat să verificăm”.

Asta e partea cel mai des stricată pe tăcute. Ecranul de autentificare funcționează, deci pare sigur. Dar backend-ul nu verifică întotdeauna că persoana autentificată e aceeași cu persoana ale cărei date încearcă să le citească. Dacă aplicația ta are vreun concept de „datele mele vs. datele tale”, cere-i explicit creatorului cu IA: „Asigură-te că utilizatorii pot vedea și edita doar propriile date.” Vei fi surprins cât de des dezvăluie fraza aia o verificare lipsă.

Integrări: lucrurile pe care nu le-ai construit, dar le folosești oricum

Aici majoritatea nedezvoltatorilor subestimează ce se întâmplă de fapt. Lucrul care trimite e-mailul „croasantele tale sunt gata” al lui Sam nu e cod — e un cont la SendGrid sau Resend. Lucrul care procesează plata cursului lui Jordan nu e cod — e Stripe. Lucrul care găzduiește pozele din clasamentul Mayei nu e cod — e un serviciu de stocare ca S3 sau Cloudinary.

Fiecare integrare apare în două locuri. E o bucățică de cod în backend care spune „hei, Stripe, taxează cardul ăsta”. Și e o cheie — un șir secret și lung — stocată undeva în siguranță (de obicei un fișier numit .env, pe care nimeni n-ar trebui să-l comită vreodată) care îi dovedește lui Stripe că cererea a venit de la brutăria lui Sam și nu de la un străin.

Dacă te întrebi vreodată de ce aplicația ta se oprește brusc din trimis e-mailuri sau din acceptat plăți, cauza e aproape întotdeauna una dintre: o cheie expirată, o limită de utilizare atinsă sau o schimbare în politicile integrării. Codul nu s-a stricat. S-a stricat strângerea de mână.

Deploy-ul: cum ajunge pe internet

Ultima piesă e partea care transformă folderul de pe discul tău într-un lucru pe care clientul tău îl poate vizita la un URL. De obicei asta înseamnă trei lucruri mici care lucrează împreună:

• Gazda: un serviciu ca Vercel, Netlify, Fly sau Render care rulează backend-ul tău și servește frontend-ul tău.
• Domeniul: un nume ca clasamentul-mayei.com care arată spre gazda ta.
• Build-ul: rețeta care ia fișierele tale sursă dezordonate și le transformă în versiunea mai suplă și mai rapidă care chiar rulează.

Când ceva funcționează local, dar se strică în producție, problema e de obicei aici. O cheie care e setată pe laptopul tău, dar nu pe gazdă. O bibliotecă instalată în dezvoltare, dar nu în producție. O bază de date care există în browserul tău, dar nu pe site-ul live.

Obiceiul de cinci minute care se merită

Nu trebuie să citești fiecare fișier din proiectul tău. Nu trebuie să știi ce face majoritatea lor. Dar ar trebui, o dată pe săptămână, să faci o parcurgere de cinci minute în care deschizi fiecare dintre folderele de mai sus și-l întrebi pe creatorul cu IA, în cuvinte simple, ce s-a schimbat.

Maya face asta în fiecare vineri după-amiază. Tastează: „Ce s-a schimbat în schemă săptămâna asta și de ce?” Și: „Există integrări noi în aplicația asta pe care nu le-am cerut?” Răspunsurile sunt aproape întotdeauna liniștitoare. Puținele dăți când nu sunt, prinde problemele cât sunt încă mici.

Ăsta e tot rostul înțelegerii pieselor. Nu să devii dezvoltator. Doar să poți pune întrebări mai bune.

Unde să mergi mai departe

Dacă turul ăsta a ajutat, două continuări merită timpul tău. Bug-ul „pare în regulă” acoperă ce să faci când una dintre piesele astea e stricată pe tăcute, iar pregătit-pentru-demo vs. pregătit-pentru-producție acoperă cum să-ți dai seama când aplicația ta a trecut de la prima etapă la a doua. Aceeași hartă, întrebuințări diferite pentru ea.