Mi az a full-stack alkalmazás? Egyszerű magyarázat

A full-stack alkalmazás olyan alkalmazás, amely minden rétegét tartalmazza, amely a működéséhez kell: a frontendet, amelyet az emberek látnak és használnak, a backendet, amely szerveren fut és érvényesíti a szabályokat, és az adatbázist, amely mindent megőriz. Egy teendőlista, amely elmenti a feladataidat, engedi, hogy bármelyik eszközről bejelentkezz, és senki mást nem enged a listádat látni, full-stack. Egy egyetlen oldal, amely csak a nyitvatartást mutatja, nem az.

A „stack” szó a technológiai rétegek egymásra halmozására utal. A „full” azt jelenti, hogy mind ott van.

Miért fontos ez, ha MI-val építesz

Amikor egy MI-építőnek leírsz egy alkalmazást, a szavak határozzák meg, mely rétegeket építi meg. A „készíts egy oldalt, amely megmutatja az étlapunkat” frontendet eredményez. A „engedd, hogy a vásárlók rendeljenek az étlapunkról, és a konyha lássa az új rendeléseket” mind a három réteget igényli, mert a rendeléseket menteni kell, két felhasználótípus között meg kell osztani, és privátnak kell maradniuk.

A különbség ismerete három módon segít:

• Pontosan azt kéred, amire szükséged van. Ha azt akarod, hogy az adatok mentődjenek, mondd ki. Egy építő, amely csak a frontendet készíti el, késznek fog látszani, de frissítéskor mindent elfelejt.
• Felismered a látszólagos készséget. Egy minta adatokkal készült demó ugyanúgy nézhet ki, mint egy működő alkalmazás. A rétegek ismerete segít ellenőrizni, hogy az adatok tényleg máshová kerülnek-e.
• Érted a futtatási költségeket. Egy önmagában álló frontend statikus fájlként kiszolgálható. A backend és az adatbázis szerveren futó programok, és ott keletkezik a legtöbb tárhelyköltség.

Mindennapi hasonlat: egy étterem

Gondolj egy étteremre.

• Az étkező a frontend. Étlapok, asztalok és a pincér jegyzettömbje. Ezt látják a vendégek, és kellemesnek és könnyen használhatónak kell lennie.
• A konyha a backend. A vendégek nem mennek be. Ide érkezik a rendelés, itt ellenőrzik, hogy az étel elérhető-e, ide készül el, és itt utasítják vissza a furcsa kéréseket. A szabályok itt élnek.
• A kamra és a rendelési napló az adatbázis. Ezekben van, ami létezik és amit rendeltek, így műszakváltáskor sem felejtődik el semmi.

Egy étterem, amelyben csak étkező van, szép étlapot mutathat, de nem lehet enni. Ez egy csak frontendes alkalmazás, amely full-stacknek adja ki magát.

A három réteg részletesen

A rétegek egy rögzített sorrendben beszélnek egymással. A frontend API-n keresztül kér valamit a backendtől — a backend által elfogadott kérések meghatározott halmazán keresztül. A backend ellenőrzi a kérést, olvassa vagy írja az adatbázist, és választ küld vissza. A frontend soha nem beszél közvetlenül az adatbázissal.

Ez a sorrend a teljes verem legfontosabb biztonsági gondolata. A frontend bármit kiolvashat és megváltoztathat a látogató, mert az az ő eszközén fut. Ezért a szabályokat — „csak a tulajdonos láthatja ezt a számlát”, „egy kupon csak egyszer használható fel” — a backendben kell érvényesíteni. A felosztásról bővebben lásd frontend vs. backend.

Kidolgozott példa: egy órafoglaló alkalmazás

Tegyük fel, hogy jógastúdiót vezetsz, és szeretnéd, ha az emberek online foglalhatnának órákat.

Mit csinál a látogató: megnyitja az oldalt, megnézi a heti órarendet, rákattint egyre, bejelentkezik, és lefoglal egy helyet.

Ami a háttérben történik:

1. A frontend megjeleníti az órarendet. Hogy feltöltse, megkérdezi a backendet: „Mely órák vannak ezen a héten, és hány hely szabad?”
2. A backend lekérdezi az órákat az adatbázisból, megszámolja az egyes órákra érkezett foglalásokat, és válaszol.
3. A látogató rákattint a Foglalás gombra. A frontend elküldi: „foglald le a 42-es órát ennek a bejelentkezett személynek”.
4. A backend ellenőrzi: valóban bejelentkezett ez a személy? Tele van az óra? Lefoglalta már? Csak ha minden rendben van, ír az adatbázisba egy új foglalási sort.
5. A backend „lefoglalva” választ küld, a frontend pedig visszaigazolást mutat.
6. Később a stúdió tulajdonosa bejelentkezik, és megnézi az óralistát. A backend ellenőrzi, hogy admin-e, mielőtt bárki nevét megmutatná.

Képzeld el, hogy ezt csak frontenddel építették volna. Az órarend megjelenhetne, a Foglalás gomb szép pipát mutathatna, de a foglalás frissítéskor eltűnne, a „szabad helyek” száma mindenki másnak hibás lenne, és a tulajdonos soha nem látná. A 4. lépés — az ellenőrzések — teljesen hiányozna. Ez a gyakorlati különbség.

Fontos kifejezések

• Frontend (kliensoldal): a böngészőben futó rész.
• Backend (szerveroldal): a szerveren futó rész. API-szervernek is nevezik.
• Adatbázis: ahol az adatok rendezetten tárolódnak. Lásd mi az adatbázis.
• API: a kérések listája, amelyeket a backend elfogad a frontendtől vagy más programoktól.
• Hitelesítés: annak ellenőrzése, ki valaki (bejelentkezés). Jogosultság: annak ellenőrzése, mit tehet.
• Telepítés (deployment): minden réteg szerverekre helyezése, hogy a nyilvánosság használhassa.
• Monolit vs. szolgáltatások: egy program, amely mindent elvégez, szemben több kisebb programmal (például egy weboldal és egy külön API). Mindkettő full-stack.

Gyakori hibák és tévhitek

• „Úgy néz ki, mintha kész lenne, tehát kész.” A minta adatok és egy működőnek látszó gomb nem ugyanaz, mint a mentett adat. Frissítsd az oldalt, nyisd meg privát ablakban, és ellenőrizd, hogy az adatok ott vannak-e.
• A szabályok a frontendbe helyezése. Egy gomb elrejtése nem biztonság. Ha a backend nem ellenőriz, bárki, aki ismeri a kérést, elküldheti.
• Titkos kulcsok a frontendbe tétele. Egy fizetési vagy MI-szolgáltatói kulcs a böngészőkódban minden látogató számára olvasható. A kulcsok a backendre valók, környezeti változókban — lásd környezeti változók és titkok.
• Azt gondolni, hogy a full-stack bonyolultat jelent. Egy kis full-stack alkalmazás lehet néhány képernyő, egy maroknyi backend-útvonal és három adatbázis-tábla. Ez a rétegek leírása, nem a méret.
• Azt gondolni, hogy minden technológiát magadnak kell kiválasztanod. Bármelyik észszerű, széles körben használt verem jó egy első verzióhoz. Fontosabb a világos leírás az adatokról és a szabályokról.

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

Írd le az alkalmazást a három réteg szempontjából, akkor is, ha nem nevezed meg őket:

• Az adatok: „Mentsd az órákat (név, időpont, kapacitás) és a foglalásokat (óra, személy, foglalás ideje) adatbázisba.”
• A szabályok: „Egy órára nem lehet kapacitáson felül foglalni. Egy személy egy órát csak egyszer foglalhat. Csak az adminok láthatják, ki foglalt.”
• A képernyők: „Heti órarend, foglalási visszaigazolás, egy adminoldal, amely órankénti foglalásokat listáz.”
• Az ellenőrzések: „Ezeket a szabályokat a szerveren érvényesítsd, ne csak az oldalon. Az API-kulcsokat a szerveren tartsd.”

Aztán tesztelj szkeptikusan: frissíts, jelentkezz be két különböző személyként, próbálj olyan adatot látni, amelyet nem szabadna. A MI-val alkalmazást építés útmutatója végigvezet ezt a ciklust.

Full-stack alkalmazások a Mythexen

A Mythex csevegésben leírt alapján épít full-stack webalkalmazásokat. Egy új alkalmazás alapesetben React és TypeScript frontendet kap; amikor az alkalmazásnak adatot kell mentenie, a Mythex dedikált Postgres adatbázist ad a projekthez, és kérheted külön API-szerver hozzáadását (például Pythonnal, Node-dal, C#-pal vagy Javával) a weboldal mellé. Minden együtt fut az élő előnézetben, és nyilvános URL-re publikál. A több szolgáltatásos alkalmazások dokumentációs oldala bemutatja, hogyan készül el előnézetben és publikálódik együtt a weboldal és az API, a full-stack alkalmazásépítő oldalon pedig kiindulópontok találhatók.

Kérdések