Mi az a szerver? Érthető útmutató alkalmazásépítőknek

A szerver olyan számítógép — vagy egy azon futó program —, amely kérésekre vár és válaszol. Amikor megnyitsz egy weboldalt, a böngésződ (a kliens) kérést küld az interneten keresztül, és valahol egy szerver visszaküldi az oldalt, a képeket vagy az adatot. Minden alkalmazás, amelyet használsz, az e-mailtől az online banki szolgáltatásig, ilyen szerverekre támaszkodik, naponta milliószor.

Miért fontosak a szerverek, ha MI-val építesz

Amikor egy MI-építő alkalmazást készít neked, a kód egy része a látogató böngészőjében fut, egy része pedig általában szerveren. A szerveroldali rész olyan dolgokat végez, amelyekre a böngésző nem bízható meg, vagy amelyekre egyedül nem képes:

• Adatok mentése és betöltése egy adatbázisból.
• Titkok megőrzése, például fizetési vagy MI-szolgáltatói API-kulcsoké, amelyek soha nem juthatnak el a böngészőbe.
• Jogosultságok ellenőrzése — annak biztosítása, hogy egy felhasználó csak a saját rekordjait lássa és módosítsa.
• Más szolgáltatásokkal való kommunikáció: kártya terhelése, e-mail küldése, MI-modell hívása.

Az, hogy tudod, mit csinál a szerver, segít megérteni, hol élnek valójában az alkalmazásod szabályai, miért kell néhány változtatáshoz újra közzétenni, és mire költesz, amikor alkalmazást üzemeltetsz. Az alkalmazás két felének szétválasztásáról lásd frontend vs. backend.

Mindennapi hasonlat

A szerver olyan, mint egy postahivatal ügyintézője. Nem megy ki ügyfelet keresni; vár. Egy ügyfél (a kliens) odamegy egy kéréssel — „feladom ezt a csomagot”, „van-e levelem?” —, az ügyintéző elintézi, és eredményt ad vissza. Egy ügyintéző egymás után sok ügyfelet kiszolgálhat, a forgalmas postahivatal pedig több pultot nyit.

A postahivatalnak is vannak szabályai, amelyeket az ügyfél nem írhat felül: igazolvány kell a csomag átvételéhez. Ez a szerver feladata az alkalmazásban is — a böngésző bármit kérhet, de a szerver dönti el, mit kap.

Hogyan jut el egy kérés a szerverhez

Amikor valaki meglátogatja a https://bookings.example.com/schedule címet:

1. DNS-keresés. A böngésző megkérdezi a domain névrendszert, melyik IP-címre mutat a bookings.example.com. Lásd hogyan működnek a domainek és a DNS.
2. Kapcsolat. A böngésző kapcsolódik ahhoz a címhez a 443-as porton, HTTPS-en, és titkosított kapcsolatot épít. Lásd mi a HTTPS és az SSL.
3. Kérés. Elküld egy HTTP-kérést: GET /schedule.
4. Munka. A szerver lefuttatja a /schedule útvonalat kezelő kódot — talán lekéri a mai foglalásokat az adatbázisból.
5. Válasz. Visszaküld egy állapotkódot (200 OK) és a tartalmat — egy HTML-oldalt, vagy JSON adatot, amelyet az oldal megjelenít.

Az egész általában a másodperc töredéke alatt történik.

A szerverek fajtái, amelyekkel találkozhatsz

Vedd észre, hogy a „szerver” gépet és programot is jelent. A „leállt a szerver” mindkettőt jelentheti.

Kidolgozott példa: egy szalon foglalási alkalmazása

Íme, mit csinál a szerver egy kis szalon foglalási alkalmazásban:

• Egy látogató megnyitja az oldalt. A szerver (vagy az elé tett CDN) elküldi az oldal fájljait.
• Az oldal lekéri a szervertől: GET /api/slots?date=2026-10-03. A szerver lekérdezi az adatbázist a szabad időpontokra, és JSON-ként visszaküldi.
• A látogató lefoglalja a 14:00-t. Az oldal elküldi: POST /api/bookings. A szerver ellenőrzi, hogy az időpont még szabad-e — nem bízik a böngésző szavában —, elmenti a foglalást, és 201 Created választ küld.
• A szerver egy e-mail-szolgáltatót hív egy titkos kulccsal, amely a szerveren van tárolva, hogy visszaigazoló e-mailt küldjön.

Ha leállítanád a szervert, az oldal talán még betöltődne a CDN-ről, de időpontokat nem tudna mutatni, és foglalásokat sem tudna menteni.

Mire van szüksége egy szervernek a jó működéshez

• Memória (RAM) és CPU. Túl kevés memória, és az alkalmazás terhelés alatt összeomlik; túl kevés CPU, és lelassul.
• Futás. Egy kikapcsolt szerver nem tud válaszolni. Néhány platform a tétlen alkalmazásokat altatja, és a következő látogatásnál ébreszti őket; ez pénzt takarít meg, de az első kérés lassabb lehet.
• Konfiguráció és titkok, környezeti változókon keresztül megadva.
• Naplók — a szerver feljegyzése arról, mi történt, és ezt nézed meg először, amikor valami elromlik.
• Frissítések és biztonsági javítások, amelyeket a menedzselt tárhely elvégez helyetted.

Gyakori tévhitek

• „A felhő azt jelenti, hogy nincsenek szerverek.” A felhő mások szervereit jelenti, amelyeket óránként vagy használat szerint bérelsz.
• „A szerver egy nagy, különleges számítógép.” Bármelyik számítógép lehet szerver. A laptopod is futtat egyet, amikor fejlesztés közben a localhost címet nyitod meg.
• „Ha a gomb el van rejtve, a felhasználók nem tudják megnyomni.” Bárki küldhet kéréseket közvetlenül a szerveredre. A jogosultsági ellenőrzéseknek a szerveren kell történniük, nem csak az oldalon.
• „Több szerver megoldja a lassúságot.” Gyakran a valódi ok egy lassú adatbázis-lekérdezés vagy egy külső API. Először azt keresd meg.
• „Szervert kell kezelnem ahhoz, hogy legyen alkalmazásom.” A menedzselt platformok futtatják helyetted a szervereket; te a kódot telepíted, ők kezelik a gépeket.

Mit kérj az MI-építődtől

• „Melyik része fut az alkalmazásnak a szerveren, és melyik a böngészőben?”
• „Minden API-kulcs maradjon a szerveren, és környezeti változókból olvasd őket.”
• „Az adatokat olvasó vagy módosító minden kérésnél a szerveren ellenőrizd a jogosultságot.”
• „Hol találom a szerver naplóit, és mit mondanak erről a hibáról?”
• „Szükséges egyáltalán szerver ehhez az alkalmazáshoz, vagy lehet statikus webhely?”
• „Mi történik az első kéréssel, miután az alkalmazás tétlen volt?”

Szerverek a Mythexen

A Mythexen nem kell szervereket beállítanod vagy kezelned. Az építés közben az alkalmazásod egy privát felhős homokozóban fut az élő előnézethez. Publikáláskor a Mythex telepíti: a statikus frontendeket statikus webhelyekként, a backendeket (Node, Python, C#, Java és mások) Dockerfile-ból épített konténerekként, külön beállítás nélkül. A Mythex telepítéskor választja meg a gép méretét: alapesetben 1 CPU és 512 MB memória, további kérésre több is elérhető (Ingyenes csomagban legfeljebb 1 GB, Pro csomagban legfeljebb 2 CPU, 4 GB és 3 gép). A közzétett alkalmazások tétlenül elalszanak, és a következő látogatásnál ébrednek; az alvó alkalmazás számítási erőforrásra nem költ. A részleteket a dokumentáció API-backendekről és tárhelykorlátokról szóló oldalai tartalmazzák, a webtárhelyről szóló útmutatónk pedig a teljesebb képet adja.

Kérdések