Ce este o aplicație full-stack? Explicație simplă

O aplicație full-stack este o aplicație care include tot ce are nevoie ca să funcționeze: frontend-ul pe care oamenii îl văd și îl apasă, backend-ul care rulează pe un server și aplică regulile, și baza de date care ține minte totul. O listă de sarcini care îți salvează task-urile, te lasă să te autentifici de pe orice dispozitiv și nu arată nimănui altcuiva lista ta este full-stack. O singură pagină care arată doar programul tău de funcționare nu este.

„Stack” înseamnă pur și simplu straturile de tehnologie puse unul peste altul. „Full” înseamnă că toate sunt prezente.

De ce contează când construiești cu AI

Când descrii o aplicație unui constructor AI, cuvintele pe care le folosești decid ce straturi construiește. „Fă o pagină care arată meniul nostru” produce un frontend. „Lasă clienții să comande din meniul nostru și lasă bucătăria să vadă comenzile noi” cere toate cele trei straturi, pentru că comenzile trebuie salvate, împărtășite între două tipuri de utilizatori și păstrate private.

Cunoașterea diferenței te ajută în trei moduri:

• Ceri lucrul potrivit. Dacă vrei date salvate, spune-o. Un constructor care face doar frontend-ul va arăta terminat, dar va uita totul la reîmprospătare.
• Recunoști finalizarea falsă. O demonstrație cu date de exemplu poate arăta identic cu o aplicație funcțională. Cunoașterea straturilor îți permite să verifici că datele chiar ajung undeva.
• Înțelegi costurile de rulare. Un frontend singur poate fi servit ca fișiere statice. Un backend și o bază de date sunt programe care rulează pe servere, iar acolo se duce cea mai mare parte a costului de găzduire.

O analogie: un restaurant

Gândește-te la un restaurant.

• Sala de mese este frontend-ul. Meniurile, mesele și carnetelul chelnerului. Este ceea ce văd oaspeții și trebuie să fie plăcut și ușor de folosit.
• Bucătăria este backend-ul. Oaspeții nu intră acolo. Ea primește comenzile, verifică dacă un fel este disponibil, îl gătește și refuză cererile ciudate. Regulile stau aici.
• Magazia și registrul de comenzi sunt baza de date. Țin evidența a ceea ce există și a ceea ce s-a comandat, ca să nu se uite nimic când se schimbă tura.

Un restaurant cu doar sală de mese îți poate arăta un meniu frumos, dar nu te poate hrăni. Asta este o aplicație doar cu frontend care se dă drept full-stack.

Cele trei straturi, în detaliu

Straturile vorbesc între ele într-o ordine fixă. Frontend-ul cere backend-ului ceva printr-un API — un set definit de cereri pe care le acceptă backend-ul. Backend-ul verifică cererea, citește sau scrie în baza de date și trimite un răspuns. Frontend-ul nu vorbește niciodată direct cu baza de date.

Această ordine este cea mai importantă idee de securitate din întreaga stivă. Orice e în frontend poate fi citit și modificat de vizitator, pentru că rulează pe dispozitivul lui. Deci regulile — „doar proprietarul poate vedea această factură”, „un cupon poate fi folosit o singură dată” — trebuie aplicate în backend. Pentru mai multe despre împărțire, vezi frontend vs. backend.

Un exemplu practic: o aplicație de rezervări la cursuri de yoga

Să zicem că ții un studio de yoga și vrei ca oamenii să rezerve cursuri online.

Ce face vizitatorul: deschide site-ul, vede orarul cursurilor din săptămâna aceasta, apasă pe unul, se autentifică și rezervă un loc.

Ce se întâmplă dedesubt:

1. Frontend-ul afișează orarul. Ca să îl completeze, cere backend-ului: „Ce cursuri sunt în această săptămână și câte locuri au rămas?”
2. Backend-ul cere bazei de date cursurile și numără rezervările pentru fiecare, apoi răspunde.
3. Vizitatorul apasă Rezervă. Frontend-ul trimite „rezervă cursul 42 pentru această persoană autentificată”.
4. Backend-ul verifică: este persoana chiar autentificată? Este cursul plin? Și-a rezervat deja locul? Doar dacă totul este în regulă scrie un rând nou de rezervare în baza de date.
5. Backend-ul răspunde „rezervat”, iar frontend-ul afișează o confirmare.
6. Mai târziu, proprietara studioului se autentifică și vede lista cursurilor. Backend-ul verifică că este administrator înainte de a arăta numele tuturor.

Acum imaginează-ți că asta ar fi fost construit doar ca frontend. Orarul s-ar putea afișa, iar butonul de rezervare ar putea arăta un semn de bifă drăguț, dar rezervarea ar dispărea la reîmprospătare, numărul de „locuri rămase” ar fi greșit pentru ceilalți, iar proprietara nu ar vedea-o niciodată. Pasul 4 — verificările — ar lipsi complet. Acesta este diferența practică.

Termeni cheie

• Frontend (partea de client): partea care rulează în browser.
• Backend (partea de server): partea care rulează pe server. Se mai numește și server API.
• Baza de date: locul unde datele sunt stocate organizat. Vezi ce este o bază de date.
• API: lista cererilor pe care le acceptă backend-ul de la frontend sau de la alte programe.
• Autentificare: verificarea cine este cineva (login). Autorizare: verificarea a ce are voie să facă.
• Deployment: punerea tuturor straturilor pe servere, ca publicul să le poată folosi.
• Monolit vs. servicii: un singur program care face totul, față de mai multe programe mai mici (de exemplu un site și un API separat). Ambele sunt full-stack.

Greșeli frecvente și idei greșite

• „Arată terminat, deci este terminat.” Datele de exemplu și un buton care pare să funcționeze nu înseamnă date salvate. Reîmprospătează pagina, deschide-o într-o fereastră privată și verifică dacă datele mai sunt acolo.
• Punerea regulilor în frontend. Ascunderea unui buton nu este securitate. Dacă backend-ul nu verifică, oricine știe cererea poate să o trimită.
• Punerea cheilor secrete în frontend. O cheie de plată sau de AI în codul din browser poate fi citită de fiecare vizitator. Cheile trebuie să stea în backend, în variabile de mediu — vezi variabilele de mediu și secretele.
• Credința că full-stack înseamnă complicat. O aplicație full-stack mică poate avea câteva ecrane, o mână de rute în backend și trei tabele în baza de date. Descrie straturile, nu dimensiunea.
• Credința că trebuie să alegi singur fiecare tehnologie. Orice stivă sensibilă și larg folosită este bună pentru o primă versiune. Mai important este să ai o descriere clară a datelor și a regulilor.

Ce să ceri constructorului tău AI

Descrie aplicația în termenii celor trei straturi, chiar dacă nu le numești:

• Datele: „Salvează cursurile (nume, oră, capacitate) și rezervările (curs, persoană, ora rezervării) într-o bază de date.”
• Regulile: „Un curs nu poate fi rezervat peste capacitate. O persoană poate rezerva un curs o singură dată. Doar administratorii pot vedea cine a rezervat.”
• Ecranele: „Un orar săptămânal, o confirmare de rezervare, o pagină de administrare cu rezervările pe curs.”
• Verificările: „Aplică aceste reguli pe server, nu doar în pagină. Păstrează cheile API pe server.”

Apoi testează ca un sceptic: reîmprospătează, autentifică-te cu doi oameni diferiți, încearcă să vezi date pe care nu ar trebui să le vezi. Ghidul pentru construirea unei aplicații cu AI parcurge întregul ciclu.

Aplicații full-stack pe Mythex

Mythex construiește aplicații web full-stack dintr-o descriere în chat. Implicit, o aplicație nouă primește un frontend React și TypeScript; când aplicația trebuie să salveze date, Mythex adaugă proiectului o bază de date Postgres dedicată, iar tu poți cere un server API separat (de exemplu în Python, Node, C# sau Java) alături de site. Totul rulează împreună într-o previzualizare live și se publică la o adresă publică. Pagina din documentație despre aplicațiile cu mai multe servicii arată cum sunt previzualizate și publicate împreună un site și un API, iar pagina constructorului de aplicații full-stack oferă puncte de plecare.

Întrebări