Site static, frontend și backend

Două site-uri pe ecran. Primul este o pagină cu un joc: tabla de joc, scor, buton "din nou". Al doilea este pagina unui atelier cu un formular "plasează o comandă". Ambele se deschid în browser, ambele sunt construite din HTML, CSS și JavaScript, ambele arată gata de folosit. Primul se publică într-un minut: folderul ajunge pe un hosting, linkul e gata. La al doilea, agentul, cel mai probabil, se va opri și va întreba unde va fi serverul și unde se salvează comenzile.

Diferența nu ține de complexitate și nici de aspect. Ține de cine trebuie să facă ceva atunci când vizitatorul apasă un buton și unde trebuie să ajungă datele după aceea. Lămurim trei termeni - site static, frontend și backend -, urmărim unde trăiesc datele și de ce de asta depinde modul de publicare. La final vedem ce întreabă agentul singur înainte să spuneți "publică-l" și ce merită să-l întrebați chiar dumneavoastră.

1. Site static

Un site static este un site din fișiere gata făcute: index.html, style.css, scripturi, imagini, fonturi. Serverul le păstrează și le trimite fiecărui vizitator la fel, fără să calculeze nimic și fără să rețină nimic despre vizitatori. Toată munca - afișare, calcul, reacție la un clic - o face browserul vizitatorului pe propriul calculator.

Luăm un portofoliu de o pagină. În folder stau index.html cu câteva rânduri despre dumneavoastră și o listă de lucrări, style.css, o duzină de imagini și un script mic. Vizitatorul deschide linkul, browserul descarcă fișierele și construiește pagina din ele. Un clic pe o lucrare deschide imaginea mărită, comutatorul de temă întunecată schimbă culorile: asta face scriptul din browser. După ce a trimis fișierele, serverul nu mai participă la nimic: îi este indiferent cine a venit și ce a apăsat. A apărut o lucrare nouă - editați index.html, puneți imaginea alături și publicați folderul din nou; altă cale de a schimba ceva aici nu există, iar site-ul îl schimbați dumneavoastră, nu vizitatorul.

După același principiu funcționează:

• afișul unui concert sau al unei întâlniri: dată, loc, program, hartă de acces; butonul "cumpără bilet" duce la site-ul vânzătorului de bilete, afișul în sine nu vinde nimic;
• o pagină de prezentare pentru un produs sau un serviciu, dacă în loc de formular are un număr de telefon și o adresă de e-mail;
• documentația unui proiect: zeci de pagini cu meniu și linkuri între ele, și tot fișiere rămân;
• un blog fără comentarii: fiecare articol e un fișier, iar unul nou se publică la fel ca restul;
• un joc în browser. Da, și jocul: mutările, scorul și animația se calculează în browser, serverului nu-i pasă de ele.

Unde se termină site-ul static se vede dacă împărțim munca site-ului în două jumătăți: cea făcută de browser și cea făcută de server. Aceste jumătăți au nume.

2. Frontend-ul rulează în browser

Frontend-ul este tot ce rulează pe calculatorul vizitatorului: marcajul, stilurile și scripturile pe care browserul le-a primit și le-a pornit local. "Partea din față", cea vizibilă. (E numit adesea "doar aspect grafic", dar reprezintă întreaga parte a site-ului cu care omul are de-a face, iar la un site static e chiar tot site-ul.)

Frontend-ul poate face multe:afișează pagina, calculează mutările dintr-un joc, verifică înainte de trimitere dacă un câmp din formular nu e gol, ține minte ceva până la vizita următoare - pentru asta browserul are propriul spațiu de stocare, agentul îl va numi localStorage. Ce nu poate face este să împartă ceva cu alții. Spațiul de stocare trăiește în acest browser, pe acest dispozitiv, și nicăieri altundeva. Unde această graniță deranjează și unde nu, se vede din două exemple.

Cel mai bun scor dintr-un joc. Partida s-a terminat, scriptul a comparat rezultatul cu recordul anterior și l-a scris pe cel nou în spațiul de stocare al browserului. Mâine jucătorul deschide pagina în același browser, pe același laptop - recordul e acolo. O deschide pe telefon - e gol, telefonul are propriul spațiu de stocare. Dumneavoastră, autorul jocului, nu veți vedea niciodată acest record. Și nu-i nimic grav: contează doar pentru jucător, iar site-ul rămâne static.

Comanda unui atelier. Clientul a descris ce trebuie făcut, a lăsat un număr de telefon, a apăsat "trimite". Scriptul poate verifica dacă sunt completate câmpurile, dar mai departe nu are unde s-o trimită: dacă scrie comanda în spațiul de stocare al browserului, ea rămâne pe telefonul clientului, iar meșterul nu află de ea. Comanda trebuie citită de altcineva, pe alt dispozitiv, deci datele trebuie să plece de pe calculatorul clientului, iar la celălalt capăt cineva trebuie să le primească și să le salveze. Un site format doar din fișiere nu are acest "cineva".

Tot ce ține de un singur vizitator pe un singur dispozitiv, frontend-ul face singur. Restul e treaba celeilalte jumătăți.

3. Backend-ul rulează pe server

Backend-ul este un program care rulează pe server și răspunde la cererile browserelor. Preia o comandă și o salvează. Verifică un login și o parolă. Trimite lista de produse. Continuă să lucreze după ce vizitatorul a închis deja tab-ul și trebuie să fie mereu pornit, la fel ca serverul însuși - un calculator care nu se oprește niciodată.

Diagrama arată două trasee cu aceeași formă: clic, muncă, rezultat. Diferă prin caseta din mijloc - cine face munca și ce anume. Sus, după o mutare în joc, JavaScript din browser calculează scorul, salvează recordul și redesenează tabla, și toate acestea pe calculatorul vizitatorului. Jos, un clic pe "trimite" se transformă într-o cerere, cererea pleacă la server, programul o primește, salvează comanda pe propriul server și răspunde browserului, și abia răspunsul lui ajunge pe ecran. Unde anume pe server stă comanda - despre asta e secțiunea următoare. Întrebarea "cine face munca" este chiar granița dintre cele două tipuri de site-uri.

Trei semne recognoscibile că nu vă puteți lipsi de backend:

• autentificare cu parolă: cineva trebuie să păstreze parolele și să le verifice, și nu poate fi browserul vizitatorului;
• date pe care trebuie să le vadă alții: comentarii, comenzi, o listă comună;
• o acțiune făcută în numele dumneavoastră: trimiterea unui e-mail, procesarea unei plăți, scrierea a ceva într-un serviciu extern folosind cheia dumneavoastră.

Limbajul pentru backend poate fi oricare: JavaScript (caz în care e Node.js), Python, Java, încă o duzină. Pentru acest articol nu asta contează, ci faptul că programul trebuie să ruleze undeva tot timpul, iar acel "undeva" nu e un browser. Adresa site-ului duce către un loc pe server, la fel ca la un site static, doar că în acel loc acum nu mai stă un fișier, ci un program care construiește răspunsul pe loc.

4. Unde trăiesc datele

Cine trebuie să facă munca după un clic o decid datele: unde stau și cine trebuie să le vadă. Nu aspectul site-ului și nu complexitatea lui. Sunt trei locuri.

În fișierele proiectului. Textul paginii, imaginile, regulile jocului. La fel pentru toți vizitatorii și se schimbă doar printr-un nou deploy: corectați fișierul, îl publicați din nou.

În browserul vizitatorului. Setări, cel mai bun scor, ciorna unui formular pe care nu vreți s-o pierdeți la reîncărcare. Le vede doar acest vizitator, pe acest dispozitiv. Dispar la ștergerea datelor site-ului, nu există într-o fereastră privată, nici în alt browser sau pe alt dispozitiv, și dumneavoastră nu știți nimic despre ele.

Într-o bază de date pe server. Comenzi, comentarii, conturi. Le văd toți cei care trebuie, dumneavoastră inclusiv. Rămân acolo indiferent dacă cineva are un tab deschis. Ca să ajungă ceva acolo, e nevoie de un program pe server care să primească datele și să le scrie.

Diagrama arată aceleași două lumi ca cea de mai sus, doar că acum arată unde stau datele, nu cine face munca. Fișierele site-ului pleacă la fiecare vizitator ca o copie, de aceea pagina e aceeași pentru toată lumea. Spațiul de stocare al browserului este singura casetă fără săgeți: datele sunt acolo, dar nu părăsesc dispozitivul, și dumneavoastră nu le veți vedea. În baza de date, datele ajung doar prin program, dar de acolo le văd toți cei care trebuie.

În loc de teorie, puneți o singură întrebare: trebuie ca altcineva să vadă ce a introdus persoana asta? "Ține minte cel mai bun scor" - nu, deci spațiul de stocare al browserului, iar site-ul rămâne static. "Salvează comanda" - da, deci o bază de date și un program care scrie în ea. Întrebarea are o singură excepție, și nu ține de date: o cheie pentru un serviciu extern. Dacă există o cheie, răspunsul "nu" nu vă salvează: locul ei nu e în fișiere, deci e nevoie fie de un program pe server care apelează acel serviciu în numele dumneavoastră, fie de un serviciu intermediar extern care face asta pentru dumneavoastră.

Există și o cale de mijloc. Formularul de comandă poate fi preluat pentru dumneavoastră de un serviciu extern: vizitatorul apasă "trimite", datele pleacă nu la serverul dumneavoastră, ci la acel serviciu, iar de acolo vă ajung printr-un e-mail. Tot un backend este, doar că nu al dumneavoastră. Agentul va numi unul, dacă îl întrebați; acum contează să înțelegeți că un formular nu funcționează fără programul de pe serverul cuiva.

5. De ce modurile de deploy diferă

Fișierele statice se publică prin copiere: folderul ajunge pe un hosting (serverul altcuiva, care trimite fișierele dumneavoastră oricui le cere), linkul e gata, iar pentru actualizare copiați folderul din nou. Atât.

Cu backend e altfel. Pe server trebuie să fie instalat mediul pentru limbajul programului - Python sau Node.js propriu-zis, fără de care codul n-are cu ce să ruleze. Programul trebuie să fie pornit și să repornească dacă a picat. Alături trebuie să funcționeze o bază de date. Cheile pentru baza de date și pentru serviciile externe trebuie să stea astfel încât programul să le citească, iar vizitatorii nu. Fiecare dintre aceste părți se actualizează separat și se strică în felul ei.

De aici și un hosting diferit: unul care pornește programe, nu doar trimite fișiere. Acolo, de obicei, plătiți pentru timpul cât rulează programul și pentru spațiul bazei de date. Există și variante gratuite, dar cu condiții care se schimbă mai des decât acest articol.

O precizare la rândul despre secrete. Cheia pentru hosting, dacă ați creat-o ca să aveți un link permanent, există și la un site static, dar trăiește separat de folderul site-ului și nu ajunge în el.

"Pornim un server" sună banal în răspunsul agentului, ca "creăm un fișier". În spatele acestei fraze stă toată coloana din dreapta a tabelului, iar aproape fiecare rând va trebui întreținut mai târziu.

6. Unde publicați un site static

Din moment ce fișierele statice se publică prin copiere, hostinguri pentru ele sunt multe, iar majoritatea sunt gratuite pentru o pagină mică. Iată cinci dintre cele mai întâlnite. În tabel apare cuvântul "repository": deocamdată e suficient să-l citiți ca folderul proiectului aflat sub control de versiuni, mai multe altă dată.

Cum alegeți. Pentru a arăta și discuta - cel la care linkul apare fără înregistrare. Pentru a-l păstra mult timp - oricare unde v-ați făcut cont. Proiectul stă deja într-un repository - cel care se conectează la repository și se actualizează singur la fiecare modificare. Alegerea nu influențează cum arată pagina publicată: fișierele sunt aceleași.

Dacă site-ul are backend

Programul are nevoie de un hosting care știe nu doar să trimită fișiere, ci să pornească codul dumneavoastră și să-l țină pornit: la intrare nu are un folder, ci un program, iar mediul pentru el îl instalează singur. O parte din serviciile din tabelul de mai sus au și acest mod, dar de obicei se începe cu două făcute special pentru programe:

Un backend gratuit are mereu propriul preț: la un serviciu programul adoarme, iar primul vizitator după o pauză așteaptă să se trezească, la altul se termină creditul. Când vizitatorii devin mulți, ajungeți să plătiți pentru funcționarea continuă. Un site static nu are această problemă: fișierele nu dorm.

Condițiile și limitele se schimbă la toate serviciile, iar produsele sunt redenumite și unite: Cloudflare, de exemplu, recomandă deja ca proiectele noi să fie începute nu în Pages, ci în Workers, unde fișierele statice se publică la fel. Cifrele au fost lăsate intenționat în afara ambelor tabele: înainte de a alege, verificați pagina de prețuri.

7. Ce să întrebați agentul înainte de publicare

Agentul se uită la folder și de obicei numește singur tipul proiectului. Fișiere fără program - va propune un hosting pentru fișiere statice, chiar dacă printre fișiere există un formular care nu are unde să trimită datele: nu observă mereu asta. Există un server.js sau un app.py - va spune că e nevoie de un server și va întreba unde va fi. Dacă n-a spus, sau a spus prea repede, întrebați-l dumneavoastră:

Uită-te la proiect și spune-mi dacă e un site static sau are nevoie de server.
Enumeră punct cu punct exact ce anume cere un server.
Pentru fiecare punct, spune dacă se poate face fără server sau poate fi amânat.

Răspunsul depinde de proiect, așa că nu apare aici. În schimb, sunt câteva lucruri la care merită să vă uitați în orice răspuns.

• Nu fiți de acord cu "e nevoie de server" fără să verificați. Întrebați ce anume îl cere și dacă se poate face în browser sau măcar amâna - de exemplu, lansați prima versiune fără formular. Agentul construiește cu plăcere un backend acolo unde ar fi fost de ajuns spațiul de stocare al browserului.
• Și invers: dacă datele trebuie să fie comune, agentul, cel mai probabil, va spune că fișierele statice nu sunt suficiente. Nu e o complicație în plus, ci pur și simplu a spune lucrurilor pe nume. n-aveți ce contesta aici.
• Despre o cheie pentru un serviciu extern, agentul va întreba unde s-o pună. Răspunsul "într-un fișier al site-ului" e greșit, și un agent bun va spune asta singur. Astfel de chei au un loc în afara fișierelor site-ului, iar agentul trebuie să-l numească singur, nu să propună scrierea cheii în pagină.
• Pentru deploy-ul unui site static, agentul are nevoie de un folder. Pentru deploy-ul unui backend - și de răspunsuri despre baza de date, mediu și secrete. Dacă n-au fost întrebări și serverul "a pornit" oricum, uitați-vă exact ce a făcut și unde.

Cuvintele "static" și "backend" nu descriu complexitatea, ci un loc: unde se întâmplă munca și unde trăiesc datele. Odată ce locul e cunoscut, modul de publicare se alege de la sine.

Condițiile hostingurilor se schimbă în timp, verificați paginile de prețuri.