Ce este un server? Un ghid simplu pentru cei care construiesc aplicații

Un server este un calculator — sau un program care rulează pe unul — care așteaptă cereri și le răspunde. Când deschizi un site web, browserul tău (clientul) trimite o cerere prin internet, iar un server undeva trimite înapoi pagina, imaginile sau datele. Fiecare aplicație pe care o folosești, de la e-mail la banca online, depinde de servere care fac asta de milioane de ori pe zi.

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

Când un constructor AI îți face o aplicație, o parte din cod rulează în browserul vizitatorului, iar o parte rulează de obicei pe un server. Partea de server face lucrurile în care browserul nu poate fi crezut sau pe care nu le poate face singur:

• Salvarea și încărcarea datelor dintr-o bază de date.
• Păstrarea secretelor, precum cheile API de plată sau de AI, care nu trebuie să ajungă niciodată în browser.
• Verificarea permisiunilor — asigurându-se că un utilizator poate vedea și schimba doar propriile înregistrări.
• Comunicarea cu alte servicii: încasarea unui card, trimiterea unui e-mail, apelarea unui model AI.

Să știi ce face serverul te ajută să înțelegi unde trăiesc de fapt regulile aplicației tale, de ce unele modificări cer republicare și pentru ce plătești când găzduiești o aplicație. Pentru împărțirea între cele două părți, vezi frontend vs. backend.

O analogie din viața de zi cu zi

Un server este ca funcționarii de la ghișeul unui oficiu poștal. Ei nu merg să caute clienți; așteaptă. Un client (clientul) vine cu o cerere — „trimiteți acest colet”, „am corespondență pe numele meu?” — iar funcționarul o tratează și îi întoarce un rezultat. Un singur funcționar poate servi mulți clienți, unul după altul, iar un oficiu aglomerat deschide mai multe ghișee.

Oficiul poștal are și reguli pe care clientul nu le poate ocoli: trebuie să arăți buletinul ca să ridici un colet. Asta este și rolul serverului în aplicație — browserul poate cere orice, dar serverul decide ce primește.

Cum ajunge o cerere la un server

Când cineva vizitează https://bookings.example.com/schedule:

1. Interogare DNS. Browserul întreabă sistemul de nume de domenii ce adresă IP are bookings.example.com. Vezi cum funcționează domeniile și DNS-ul.
2. Conexiune. Browserul se conectează la acea adresă, pe portul 443 pentru HTTPS, și stabilește o conexiune criptată. Vezi ce este HTTPS.
3. Cerere. Trimite o cerere HTTP: GET /schedule.
4. Lucru. Serverul rulează codul care tratează /schedule — poate căutând în baza de date programările de azi.
5. Răspuns. Trimite înapoi un cod de stare (200 OK) și conținutul — o pagină HTML sau date JSON pe care pagina să le afișeze.

Tot acest proces durează de obicei o fracțiune de secundă.

Tipuri de servere despre care vei auzi

Reține că „server” înseamnă atât aparatul, cât și programul. „Serverul s-a blocat” poate însemna oricare dintre ele.

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

Iată ce face serverul într-o aplicație mică de rezervări la salon:

• Un vizitator deschide site-ul. Serverul (sau un CDN din fața lui) trimite fișierele paginii.
• Pagina cere serverului GET /api/slots?date=2026-10-03. Serverul interoghează baza de date pentru intervalele libere și le returnează ca JSON.
• Vizitatorul rezervă ora 14:00. Pagina trimite POST /api/bookings. Serverul verifică dacă intervalul este încă liber — nu crede pe cuvânt browserul — salvează rezervarea și returnează 201 Created.
• Serverul apelează un serviciu de e-mail cu o cheie secretă, păstrată pe server, ca să trimită confirmarea.

Dacă ai opri serverul, pagina s-ar putea încărca în continuare dintr-un CDN, dar nu ar putea afișa intervale sau salva rezervări.

Ce are nevoie un server ca să meargă bine

• Memorie (RAM) și CPU. Prea puțină memorie și aplicația se prăbușește sub sarcină; prea puțin CPU și încetinește.
• Să ruleze. Un server oprit nu poate răspunde. Unele platforme pun aplicațiile inactive în repaus și le trezesc la următoarea vizită, ceea ce economisește bani, dar poate face prima cerere mai lentă.
• Configurație și secrete, furnizate ca variabile de mediu.
• Jurnale — evidența serverului despre ce s-a întâmplat, unde te uiți primul când ceva nu merge.
• Actualizări și plasturi de securitate, pe care le gestionează pentru tine găzduirea administrată.

Concepții greșite frecvente

• „Cloud-ul înseamnă că nu există servere.” Cloud-ul sunt serverele altor companii, închiriate pe oră sau în funcție de utilizare.
• „Un server este un calculator special, mare.” Orice calculator poate fi server. Laptopul tău rulează unul când deschizi localhost în timpul dezvoltării.
• „Dacă butonul este ascuns, utilizatorii nu pot face asta.” Oricine poate trimite cereri direct serverului tău. Verificările de permisiuni trebuie făcute pe server, nu doar în pagină.
• „Mai multe servere rezolvă lentoarea.” Adesea cauza reală este o interogare lentă la baza de date sau un API extern. Găsește mai întâi punctul de blocaj.
• „Trebuie să administrez un server ca să am o aplicație.” Platformele administrate rulează serverele pentru tine; tu publici codul, iar ele se ocupă de aparate.

Ce să ceri constructorului tău AI

• „Ce părți din această aplicație rulează pe server și care rulează în browser?”
• „Păstrează toate cheile API pe server și citește-le din variabile de mediu.”
• „Verifică permisiunile pe server pentru fiecare cerere care citește sau modifică date.”
• „Unde găsesc jurnalele serverului și ce spun despre această eroare?”
• „Are nevoie această aplicație de un server, sau poate fi un site static?”
• „Ce se întâmplă cu prima cerere după ce aplicația a stat inactivă?”

Servere în Mythex

În Mythex nu configurezi și nu administrezi servere. În timpul construirii, aplicația ta rulează într-un sandbox cloud privat pentru previzualizarea live. Când publici, Mythex o implementează: frontend-urile statice ca site-uri statice, iar backend-urile (Node, Python, C#, Java și altele) ca containere construite dintr-un Dockerfile — fără nicio găzduire de configurat manual. Mythex alege dimensiunea mașinii la implementare: implicit 1 CPU și 512 MB de memorie, cu mai multe disponibile la cerere (până la 1 GB pe planul Free și până la 2 CPU-uri, 4 GB și 3 mașini pe Pro). Aplicațiile publicate adorm când nu sunt folosite și se trezesc la următoarea vizită, iar o aplicație adormită nu consumă nimic pentru calcul. Detaliile se găsesc în documentația despre backend-urile API și limitele de găzduire, iar ghidul nostru despre găzduirea web acoperă imaginea de ansamblu.

Întrebări