Az API réteg és a FastAPI

Mi a FastAPI

A FastAPI egy modern, Python nyelvű webes keretrendszer, amellyel API-kat építünk. Az API az a felület, amelyen keresztül a különböző programok egymással beszélnek. Amikor egy mobilalkalmazás, egy weboldal vagy egy másik szolgáltatás adatot kér vagy küld, egy API végponthoz fordul, és onnan kap választ. A FastAPI ezeknek a végpontoknak a megírását teszi gyorssá és áttekinthetővé. A neve két dolgot ígér, gyorsaságot és API-építést, és a gyakorlatban mindkettőt hozza.

A lényege, hogy kevés kóddal működő végpontot kapunk. Megadjuk az útvonalat, a HTTP metódust és egy Python függvényt, a keretrendszer pedig gondoskodik a kérés fogadásáról, az adat kicsomagolásáról és a válasz visszaküldéséről. Ez a kevés fölösleges kód az egyik fő oka annak, hogy annyi AI projekt indul FastAPI-val. A csapat pár óra alatt eljut odáig, hogy egy éles, dokumentált végpont fogad kéréseket, és onnantól a valódi munkára koncentrálhat.

Az sem véletlen, hogy egy Python keretrendszer került ilyen központi helyre. Az AI eszközök túlnyomó része Python nyelven érhető el, a modellhívó könyvtáraktól a szövegfeldolgozáson át az adatbázis kliensekig. Ha a backend is Python nyelven fut, akkor ezek az eszközök közvetlenül, fordítgatás és kerülőút nélkül használhatók ugyanabban a kódban. A FastAPI így nemcsak egy gyors keretrendszer, hanem az a pont is, ahol az AI ökoszisztéma összes eszköze természetesen találkozik.

Miért éppen a FastAPI

Több modern keretrendszer közül azért esik sok csapat választása a FastAPI-ra, mert egyszerre ad teljesítményt és fejlesztői kényelmet. Négy tulajdonság emeli ki a mezőnyből.

Az első az aszinkron működés. A FastAPI async módon képes kezelni a kéréseket, ami azt jelenti, hogy amíg egy kérés egy lassú műveletre vár, például egy modell válaszára, addig a szerver más kéréseket is kiszolgálhat. Az AI backendeknél ez különösen fontos, mert a modellhívás gyakran hosszú másodpercekig tart, és eközben a szervernek nem szabad tétlenül állnia.

A második a Pydantic alapú adatvalidáció. A bejövő és kimenő adatok szerkezetét Python típusokkal írjuk le, a FastAPI pedig ezek alapján automatikusan ellenőrzi, hogy a kérés a megfelelő formátumban érkezett-e. Ha valaki hiányos vagy rossz típusú adatot küld, a keretrendszer még azelőtt visszautasítja, hogy a kód belső logikájához érne. Ez a típusbiztonság rengeteg apró hibát megfog, mielőtt az problémává nőné ki magát.

A harmadik az automatikus dokumentáció. A FastAPI a végpontokból magától legenerálja az OpenAPI leírást, és ehhez egy interaktív Swagger felületet ad. A fejlesztő böngészőből ki tudja próbálni a végpontokat, anélkül hogy külön dokumentációt kellene írni és karbantartani. Egy csapatban ez sok félreértést előz meg, mert mindenki ugyanazt a naprakész leírást látja.

A negyedik a kevés fölösleges kód és a jó fejlesztői élmény. A végpont maga egy egyszerű Python függvény, a típusjelölések pedig egyszerre szolgálják a validációt, a dokumentációt és a szerkesztő automatikus kiegészítését. Ugyanabból a néhány sorból három hasznot kapunk.

Hol áll a stackben

Az előző leckében láttuk, hogy az AI alkalmazás több rétegből áll. A FastAPI ezek közül az a réteg, amely kívülről fogadja a kéréseket. Ő a bejárat. Amikor egy felhasználó vagy egy másik rendszer kérdez valamit, a kérés először a FastAPI végponthoz érkezik, és innen indul a belső munka. Fontos látni, hogy a FastAPI maga nem gondolkodik és nem tud semmit a modellről. A dolga a fogadás, az ellenőrzés és a továbbítás.

A tipikus menet a következő. A végpont fogadja a kérést, a Pydantic validálja az adatot, majd a kód továbbítja a modell felé. A modell lehet egy külső modell API, vagy egy helyben futó inferencia szerver, amelyről a kurzus egy későbbi leckéje szól. Közben gyakran egy adatbázis lekérdezés is történik, hogy a modell a megfelelő kontextussal dolgozzon. Végül a FastAPI a modell válaszát visszaadja a kérőnek. Az alábbi lépéssor ezt a kört bontja szét.

Egy tipikus AI backend

Vegyünk egy fiktív magyar céget, egy közepes méretű webáruházat, amely ügyfélszolgálati asszisztenst épít. A vásárló beír egy kérdést a chat ablakba, például hogy hol tart a csomagja. A kérdés egy FastAPI végponthoz érkezik. A végpont először ellenőrzi, hogy tényleg van szöveg és rendelési azonosító a kérésben, mert enélkül nincs értelme továbbmenni. Ezután a backend lekérdezi az adatbázisból a rendeléshez tartozó adatokat, összeállítja a modellnek szánt üzenetet a kérdéssel és a szállítási állapottal, majd elküldi a modellnek.

A modell megfogalmazza a választ, a FastAPI pedig visszaküldi a vásárlónak, lehetőleg folyamatosan, hogy a felhasználó ne egy üres képernyőre várjon. Ez a teljes kör egyetlen backend mögött fut, és a három fő mozzanat egy szerver, egy modellhívás és egy adatbázis lekérdezés. A legtöbb AI backend ezt a mintát követi, és a FastAPI éppen ezért került annyi projekt középpontjába, mert ezt a három mozzanatot tisztán és gyorsan összeköti.

Érdemes látni, mi az, ami ebből a képből kimarad. A FastAPI nem dönti el, mit válaszoljon a modell, nem tárolja a hosszú távú tudást, és nem futtatja magát a modellt. Ezek a feladatok a stack többi rétegéhez tartoznak, amelyeket a következő leckékben veszünk sorra. Az API réteg dolga csak annyi, hogy a kérést biztonságosan és jó formában eljuttassa a megfelelő helyre, majd a választ visszahozza. Ez a világos munkamegosztás teszi a rendszert átláthatóvá, és ez az, ami miatt az API réteget ritkán kell újragondolni, ha a projekt később bővül.

Mikor mire figyelj

Az API réteg megírása egyszerű, de néhány dolog AI backendnél máshogy viselkedik, mint egy hagyományos alkalmazásnál, ezért érdemes rájuk figyelni. Az időtúllépés az első. A modellválasz lassú lehet, ezért a hívásokhoz észszerű időkorlátot kell állítani, és kezelni kell azt az esetet, amikor a modell nem válaszol időben, hogy a felhasználó ne maradjon végtelen várakozásban.

A streaming a második. A hosszú válaszokat érdemes folyamatosan, kis darabokban visszaküldeni, hogy a felhasználó ne egy üres képernyőt bámuljon, amíg a teljes válasz elkészül. A FastAPI támogatja a streamelt választ, és AI backendnél ez ma már alapelvárás. A harmadik a hitelesítés. A végpontokat védeni kell, hogy csak az arra jogosult kérések jussanak be, különben bárki a saját céljára használhatná a backendet és a mögötte lévő modellt. A negyedik a rate limit. Érdemes korlátozni, hány kérést fogad el a szerver adott idő alatt egy klienstől, hogy egyetlen felhasználó vagy egy hibás szkript ne terhelje túl a rendszert és ne hajtsa fel a modellhasználat költségét.

Vezetői tanulság

Ha egy dolgot érdemes megjegyezni erről a rétegről, akkor az a következő. Az API réteg olcsó, bevett és jól kitaposott. A FastAPI ingyenes, nyílt forrású, és rengeteg csapat használja, így bőven van hozzá tudás és minta. Egy működő API végpontot rövid idő alatt fel lehet állítani, és ez a rész ritkán okoz meglepetést.

Éppen ezért egy AI projekt nehézsége szinte soha nem itt van. A valódi kihívás a modell megbízható válaszaiban, a jó kontextus összeállításában, az adat minőségében és a rendszer üzemeltetésében rejlik. Vezetőként ezt hasznos tudni, mert ha egy csapat azt jelzi, hogy sok időt tölt magával az API réteggel, az általában nem a technológia korlátja. Sokkal inkább jelzés arról, hogy a valódi munkát, a modell körüli logikát és az adatot máshol nem tisztázták le eléggé. A következő leckékben pontosan ezekre a nehezebb rétegekre lépünk tovább, kezdve azzal, hogyan tárolja és keresi vissza egy AI alkalmazás a saját tudását.