A Python kényelme és sokoldalúsága miatt az informatikai élet szinte minden területén használják szoftverek készítésére. Az egyik fő piaci rés a webes szolgáltatások, ahol a Python fejlesztési sebessége és rugalmas metaforái megkönnyítik a weboldalak gyors létrehozását és üzemeltetését.
És ahogy azt már sejteni lehetett, a Python rengeteg választási lehetőséget és mozgásteret biztosít a webes keretrendszerek terén, kicsik és nagyok egyaránt. Végül is nem minden webes projektnek kell vállalati méretűnek lennie. A legtöbbnek éppen elég nagynak kell lennie ahhoz, hogy elvégezze a munkát, és nem nagyobbnak. Ez a cikk a nyolc legismertebb Python keretrendszert tekinti át, amelyek az egyszerűséget, a könnyű megvalósítást és a szoros fókuszt hangsúlyozzák.
Bottle
A Bottle-t egyfajta mini-Flasknak is tekinthetnénk, mivel még kompaktabb és tömörebb, mint ez a másik “mikro-keretrendszer”. Minimális alapterülete miatt a Bottle ideális más projektekbe való beépítésre vagy kisebb projektek, például REST API-k gyors megvalósítására. (A Flaskot alább tárgyaljuk.)
A Bottle teljes kódbázisa egyetlen fájlban elfér, és egyáltalán nincsenek külső függőségei. Még így is elegendő funkcionalitással van felszerelve a Bottle ahhoz, hogy külső segítség igénybevétele nélkül is elkészíthessük az általános webes alkalmazásokat.
A Bottle útválasztási rendszere, amely az URL-eket függvényekhez képezi le, szinte pontosan ugyanazzal a szintaxissal rendelkezik, mint a Flask. Nem korlátozódik az útvonalak keményen bekötött készletére sem; ezeket dinamikusan is létrehozhatja. A kérés- és válaszadatok, a cookie-k, a lekérdezési változók, a POST-akcióból származó űrlapadatok, a HTTP-fejlécek és a fájlfeltöltések mind elérhetők és kezelhetők a Bottle objektumain keresztül.
Minden képességet jó odafigyeléssel valósítottak meg. A fájlfeltöltésnél például nem kell átnevezni a fájlt, ha annak elnevezési konvenciója ütközik a célfájlrendszerrel (például a Windowson a névben lévő írásjelek). Ezt a Bottle elvégzi ön helyett.
A Bottle saját egyszerű HTML templating motort tartalmaz. Ismétlem, bár minimális, a templating motor minden lényeges dologgal rendelkezik. A sablonban szereplő változók alapértelmezés szerint biztonságos HTML-sel kerülnek megjelenítésre; meg kell jelölni, hogy mely változók biztonságosak a szó szerinti reprodukáláshoz. Ha inkább lecserélné a Bottle sablonkészítő motorját egy másikra, például a Jinja2-re, a Bottle lehetővé teszi, hogy ezt gond nélkül megtehesse. Én jobban kedvelem a Bottle-lal együtt járó egyszerű sablonrendszert; gyors, szintaxisa igénytelen, és lehetővé teszi, hogy a kódot és a sablonszöveget indokolatlan nehézségek nélkül keverjük össze.
A Bottle még több szerver backendet is támogat. A gyors teszteléshez saját beépített miniszerverrel rendelkezik, de szükség esetén támogatja az általános WSGI-t, a WSGI-kompatibilis HTTP-kiszolgálók széles választékát és a sima régi CGI-t is.
A Bottle-nak nincs szüksége annyi dokumentációra, mint más keretrendszereknek, de a dokumentáció korántsem szűkmarkú. Minden lényeges dolog elfér egyetlen (bár hosszú) weboldalon. Ezen túlmenően teljes dokumentációt talál minden egyes API-hoz, példákat a különböző infrastruktúrákon való telepítéshez, a beépített templating nyelv magyarázatát és egy csomó általános receptet.
A Flaskhoz hasonlóan a Bottle funkcionalitását manuálisan vagy bővítményekkel bővítheti. A Bottle bővítményei közel sem olyan számosak, mint a Flaské, de vannak hasznos darabok, például a különböző adatbázisrétegekkel való integráció és az alapvető felhasználói hitelesítés. Az aszinkron támogatáshoz a Bottle használhatja a meglévő szerveradapterek egyikét, amely aszinkron fut, mint például az aiohttp/uvloop, de async/await nem natívan támogatott.
A Bottle minimalizmusának egyik következménye, hogy néhány elem egyszerűen nincs benne. Az űrlapérvényesítés, beleértve az olyan funkciókat, mint a CSRF (cross-site request forgery) védelem, nincs benne. Ha olyan webes alkalmazást szeretne készíteni, amely nagymértékben támogatja a felhasználói interakciót, akkor ezt a támogatást magának kell hozzáadnia.
A Bottle másik problémája, hogy a fejlesztés megrekedt; az utolsó, 0.12-es kiadás 2013-ban érkezett. Ennek ellenére a Bottle-t továbbra is karbantartják, és a fejlesztői kiadásai továbbra is használhatóak a termelésben. A fejlesztők szándékában áll olyan új verziókat szállítani, amelyek levetik a Python régebbi kiadásainak támogatását.
CherryPy
A CherryPy már közel 20 éve létezik valamilyen formában, de nem veszítette el azt a minimalizmust és eleganciát, ami a kezdetektől fogva jellemezte.
A CherryPy célja, amellett, hogy csak a weboldalak kiszolgálásához szükséges csupasz biteket tartalmazza, hogy a lehető legnagyobb mértékben ne úgy érezze magát, mint egy “webes keretrendszer”, hanem mint bármely más Python alkalmazás. Az olyan oldalak, mint a Hulu és a Netflix azért használják a CherryPy-t a termelésben, mert a keretrendszer egy nagyon nem feltűnő alapot biztosít, amelyre építeni lehet. A CherryPy pool szálakat használ a motorháztető alatt, annál jobban támogatva a többszálú szerveradaptereket.
A CherryPy lehetővé teszi, hogy a webes alkalmazásodat elkülönítsd az alaplogikától. Ahhoz, hogy az alkalmazás funkcióit a CherryPy által kiszolgált URL-ekhez vagy útvonalakhoz rendelje, létrehoz egy olyan osztályt, ahol az objektumok névterei közvetlenül a kiszolgálni kívánt URL-ekhez kapcsolódnak. Például a weboldal gyökerét egy “index” nevű függvény szolgáltatja. Az ezeknek a függvényeknek átadott paraméterek a GET vagy POST módszerek által biztosított változók kezelésére szolgálnak.
A CherryPy által tartalmazott bitek alacsony szintű építőelemként hivatottak működni. A munkamenet-azonosítók és a cookie-k kezelése szerepel, de a HTML templating nem. A Bottle-hoz hasonlóan a CherryPy is módot kínál arra, hogy az útvonalakat a lemezen lévő könyvtárakhoz rendeljük a statikus fájlkiszolgáláshoz.
A CherryPy gyakran egy meglévő, harmadik féltől származó könyvtárra támaszkodik egy funkció támogatásához, ahelyett, hogy natívan biztosítaná azt. A WebSocket alkalmazásokat például a CherryPy nem közvetlenül támogatja, hanem a ws4py könyvtáron keresztül.
A CherryPy dokumentációja tartalmaz egy praktikus útmutatót, amely a program különböző aspektusait mutatja be. Ez nem vezet végig egy teljes, végponttól végpontig tartó alkalmazáson, ellentétben néhány más keretrendszer bemutatójával, de így is hasznos. A dokumentáció praktikus megjegyzéseket tartalmaz a virtuális hosztokon való telepítésről, az Apache és Nginx segítségével történő fordított proxyról és sok más forgatókönyvről.
Falcon
Ha REST-alapú API-kat építesz és semmi mást, a Falcon csak neked készült. Karcsú és gyors, a szabványos könyvtáron kívül szinte semmilyen függőséggel, a Falcon mindent biztosít, amire a REST API-khoz szüksége van, és semmi többet. A 2019-ben kiadott Falcon 2.0 megszünteti a Python 2.x támogatását, és legalább Python 3.5-re van szükség.
Az, hogy a Falcon miért érdemli ki a “könnyű és karcsú” címkét, nagyrészt kevés köze van a keretrendszerben található kódsorok számához. Ez azért van, mert a Falcon szinte semmilyen saját struktúrát nem kényszerít az alkalmazásokra. Egy Falcon-alkalmazásnak mindössze annyit kell tennie, hogy megadja, mely függvények milyen API végpontokhoz tartoznak. A JSON visszaküldése egy végpontról alig jelent többet, mint egy útvonal beállítása és az adatok visszaküldése a Python szabványos könyvtárából származó json.dumps függvényen keresztül. Az async támogatása még nem landolt a Falconban, de folyamatban van a munka, hogy ez megtörténjen a Falcon 3.0.
Falcon is használ épeszű out-of-the-box alapértelmezéseket, így kevés bütykölés szükséges a beállításhoz. Például minden olyan útvonalra, amely nincs explicit módon deklarálva, alapértelmezés szerint 404-es üzenetet kapunk. Ha hibákat akarsz visszaadni az ügyfélnek, akkor a keretrendszerrel együtt szállított számos kivétel egyikét (például HTTPBadRequest) vagy egy általános falcon.HTTPError kivételt használhatsz. Ha elő- vagy utófeldolgozásra van szüksége egy útvonalhoz, a Falcon ezekhez is biztosít horgokat.
A Falcon API-kra való összpontosítása azt jelenti, hogy a hagyományos HTML felhasználói felülettel rendelkező webes alkalmazások építéséhez kevés itt a hely. Ne számítson például sok űrlapfeldolgozó funkcióra és CSRF-védelmi eszközökre. Ennek ellenére a Falcon elegáns lehetőségeket biztosít a funkcionalitás bővítésére, így kifinomultabb elemek is építhetők. A fent említett hooking mechanizmustól eltekintve talál egy interfészt a middleware létrehozásához, amely a Falcon összes API-jának csomagolására használható.
A Falcon dokumentációja más keretrendszerekhez képest karcsú, de csak azért, mert kevesebb a lefednivaló. A felhasználói kézikönyv tartalmaz egy formális, lépésről lépésre történő ismertetést az összes főbb funkcióról, valamint egy gyorsindító részt, amely lehetővé teszi a mintakód megtekintését megjegyzésekkel vagy azok nélkül.
FastAPI
A FastAPI neve jól összefoglalja, hogy mit csinál. Az API végpontok gyors létrehozására készült, és gyorsan is fut.
A FastAPI a Starlette projektet használja a nagysebességű hálózati maghoz, de a FastAPI használatához nem kell ismerned a Starlette belsejét. A végpontokat nagyjából ugyanúgy definiálod, mint egy Flask vagy Bottle alkalmazásban – dekorátorokkal jelzed, hogy mely függvények milyen útvonalakat kezelnek -, majd szótárakat adsz vissza, amelyeket automatikusan JSON-ra fordítanak.
Egyszerűen felülbírálhatod, hogyan adódnak vissza a dolgok. Ha például HTML/XML-t szeretne visszaküldeni néhány végpontról, akkor ezt egyszerűen egy egyéni Response objektum visszaküldésével teheti meg. Ha egyéni middleware-t szeretne hozzáadni, akkor bármit beilleszthet, ami követi az ASGI szabványt.
A FastAPI kihasználja a Python type hintingjét, hogy korlátokat adjon az útvonalak által elfogadott adattípusokra vonatkozóan. Ha például van egy Optional típusú útvonalunk, a FastAPI az egész számok kivételével minden beérkező adatot elutasít. Nem kell adatérvényesítési kódot hozzáadnia a végpontjaihoz; egyszerűen használhatja a típusjavaslatokat, és hagyhatja, hogy a FastAPI elvégezze a munkát.
Naturális, hogy néhány dolog kimarad. Nincs például natív HTML sablonmotor, de nincs hiány a harmadik féltől származó megoldásokból, amelyek ezt a hiányt pótolják. Ugyanez a helyzet az adatbázis-kapcsolattal, de a dokumentáció tartalmaz részleteket arról, hogyan lehet bizonyos ORM-eket (pl. Peewee) rávenni, hogy működjenek együtt a FastAPI aszinkron viselkedésével.
Flask
A Python webes keretrendszerekről szóló sok vita a Flaskkal kezdődik, és jó okkal. A Flask egy jól bevált, jól érthető keretrendszer, amely könnyen használható és meglehetősen stabil. Szinte lehetetlen elrontani a Flask használatát egy könnyű webes projekthez vagy egy alapvető REST API-hoz, de nehéz dolgunk lesz, ha megpróbálunk valami nagyobbat építeni.
A Flask központi vonzereje az alacsony belépési korlát. Egy alapvető “hello world” alkalmazás kevesebb, mint 10 Python sorból összeállítható. A Flask tartalmaz egy széles körben használt HTML sablonkészítő rendszert, a Jinja2-t, amely megkönnyíti a szöveg megjelenítését, de a Jinja2 bármely más sablonmotorra (például Mustache-ra) cserélhető, vagy akár sajátot is készíthetünk.
A Flask az egyszerűség nevében elhagyja az olyan finomságokat, mint az adatréteg vagy az ORM, és nem rendelkezik az űrlapok érvényesítéséről. A Flask azonban bővíthető bővítményekkel, amelyekből több tucat van, és számos gyakori felhasználási esetet lefednek, például a gyorsítótárazást, az űrlapkezelést és -érvényesítést, valamint az adatbázis-kapcsolhatóságot. Ez a lean-by-default kialakítás lehetővé teszi, hogy a Flask-alkalmazás tervezését az abszolút minimális funkcionalitással kezdje, majd csak a szükséges darabokat építse be, amikor szüksége van rájuk.
A Flask dokumentációja zseniális és könnyen olvasható. A gyorsindító dokumentum kiváló munkát végez a kezdésben, miközben elmagyarázza az alapértelmezett választások jelentőségét egy egyszerű Flask-alkalmazás esetében, az API-dokumentumok pedig tele vannak jó példákkal. Szintén kiváló a Flask snippetek gyűjteménye, amelyek gyors és piszkos példák arra, hogyan lehet konkrét feladatokat elvégezni, például hogyan kell visszaadni egy objektumot, ha létezik, vagy 404-es hibát, ha nem.
A Flask 2018-ban érte el az 1.0-s mérföldkőnek számító kiadását, a Python 2.6 és Python 3.3 a minimálisan támogatott verziók, és számos viselkedése végre kőbe vésődött. A Flask nem támogatja kifejezetten a Python aszinkron szintaxisát, de a Flasknak egy Quart nevű API-kompatibilis változata lett kihajtva, hogy kielégítse ezt az igényt.
Pyramid
A Pyramid kicsi és könnyű, jól alkalmazható olyan feladatokra, mint a meglévő Python kód REST API-ként való közzététele, vagy egy olyan webes projekt magjának biztosítása, ahol a fejlesztő végzi a nehéz munka nagy részét.
“A Pyramid lehetővé teszi, hogy gyorsan produktívvá váljon, és együtt fog növekedni Önnel” – áll a dokumentációban. “Nem fog visszatartani, amikor az alkalmazásod kicsi, és nem lesz az utadban, amikor az alkalmazásod nagy lesz.”
A Pyramid minimalizmusát jól jellemzi a “politikamentes” kifejezés, amelyet a dokumentációnak abban a részében használnak, amely azt tárgyalja, hogy a Pyramid hogyan viszonyul más webes keretrendszerekhez. Alapvetően a “policy-mentesség” azt jelenti, hogy a Pyramidnak nincs köze ahhoz, hogy milyen adatbázist vagy milyen templating nyelvet választunk.
Egy alapvető Pyramid-alkalmazás elkészítéséhez nagyon kevés munkára van szükség. Ahogy a Bottle és a Flask esetében, egy Pyramid alkalmazás egyetlen Python fájlból állhat, eltekintve magának a keretrendszernek a fájljaitól. Egy egyszerű, egy útvonalú API nem igényel több mint egy tucatnyi sornyi kódot. Ennek nagy része boilerplate, például from … import utasítások és a WSGI-kiszolgáló beállítása.
A Pyramid alapértelmezés szerint számos olyan elemet tartalmaz, amelyek gyakoriak a webes alkalmazásokban, de ezek összeilleszthető komponensek, nem pedig teljes értékű megoldások. A felhasználói munkamenetek támogatása például még CSRF-védelemmel is jár. A felhasználói fiókok, például a bejelentkezések vagy a fiókkezelés támogatása azonban nem része az ajánlatnak. Ezt magának kell megvalósítania, vagy egy beépülő modulon keresztül hozzáadni. Ugyanez vonatkozik az űrlapkezelésre és az adatbázis-kapcsolatokra is.
A Pyramid még arra is módot ad, hogy korábbi Pyramid-projektekből sablonokat hozzon létre a korábbi munka újrafelhasználásához. Ezek a “scaffolds”-nak nevezett sablonok egyszerű útválasztással és néhány kezdő HTML/CSS-sablonnal létrehoznak egy Pyramid-alkalmazást. A csomagban szereplő scaffolds tartalmaz egy minta indító projektet és egy olyan projektet, amely a népszerű Python SQLAlchemy könyvtáron keresztül csatlakozik az adatbázisokhoz.
A Pyramid karcsú tesztelési és hibakeresési eszközei megteszik a magukét. Csatlakoztassa a debugtoolbar bővítményt egy Pyramid alkalmazáshoz, és minden weboldalon egy kattintható ikont kap, amely részleteket generál az alkalmazás végrehajtásáról, beleértve a részletes visszakövetést hiba esetén. A naplózás és az egységtesztelés is jelen van.
A Pyramid dokumentációja kiváló. Az alapok gyors bemutatásán és egy oktató jellegű sétán kívül találunk egy sor közösség által készített oktatóanyagot és egy gyakori recepteket tartalmazó szakácskönyvet is. Ez utóbbi számos célkörnyezethez tartalmaz telepítési technikákat, a Google App Engine-től az Nginxig.
A Pyramid támogatja a Python 2 és a Python 3-at is, de nem használja a Python 3 aszinkron szintaxisát. Ha szeretné kihasználni az aszinkronizációt a Pyramidban, nézze meg az aiopyramid projektet, amely egy aszinkronizált “hello world” alkalmazást tartalmaz.
Sanic
A gyorsaságra és egyszerűségre tervezett Sanic a Python 3.6 vagy újabb Python 3.6-os verziójával működik, és a Python async/await szintaxisát használja (a Python 3.5-től elérhető), hogy hatékony webes alkalmazásokat készíthessünk.
A Flaskhoz vagy a Bottle-hoz hasonlóan egy alapvető Sanic “hello world” körülbelül 10 sornyi kódot tartalmaz, amelynek nagy része import és egyéb boilerplate. A legfontosabb különbség az, hogy az alkalmazási útvonalakat async def függvényként kell deklarálni, és az aszinkron kódban a await használatával kell meghívni ezeket a függvényeket. Ha írtál már korábban aszinkronizált alkalmazásokat, akkor a legnehezebb rész már a hátad mögött van.
A Sanic által a kapcsolatok és válaszok kezelésére használt mechanizmusok közül sok ismerős lesz. A kérések és válaszok csak objektumok, ismerősnek tűnő tulajdonságokkal, mint például feltöltött fájlok, űrlapok, JSON objektumok, fejlécek és így tovább.
A sok útvonalat tartalmazó alkalmazások kezelése nehézkessé válik. A Sanic ezt “tervrajzokkal” kezeli, olyan objektumokkal, amelyek útvonalak csoportjait írhatják le, és lehetővé teszik, hogy magas szintű felületen keresztül kezeljük őket. Ahelyett, hogy minden egyes útvonalat explicit módon írna meg, vagy változókkal ellátott útvonalak sokaságát használná, írhat néhány blueprintet, amelyek általánosan leírják, hogyan működnek az útvonalak az alkalmazásban (pl. /object/object_id/action). A bleprintek rendelkezhetnek közös middleware-rel, ami hasznos, ha egyes útvonalakra menedzsmentfunkciókat szeretne alkalmazni, másokra viszont nem.
A Sanic a HTTP-n kívül más protokollokkal is működik. A WebSocket végpontok csak egy másik dekorátort és egy kicsit több belső logikát igényelnek (pl. válaszok várása és kezelése). Az egyedi hálózati protokollok a asyncio.protocol alosztályozásával támogathatók.
A Sanic szándékosan kihagyja az olyan funkciókat, mint az adatbázis-kapcsolat és a HTML templating, miközben megtartja azokat a funkciókat, amelyeket az ilyen képességek beépítéséhez használnánk: middleware, központosított alkalmazáskonfiguráció és így tovább.
Tornado
A Tornado egy másik apró keretrendszer, amely egy speciális felhasználási esetre irányul: aszinkron hálózati alkalmazások. A Tornado jól alkalmazható olyan szolgáltatások létrehozására, amelyek nagyszámú hálózati kapcsolatot nyitnak meg és tartanak életben – vagyis bármi, ami WebSockets vagy hosszú pollinggal jár. A Tornado 6.0-hoz Python 3.5 vagy újabb Python 3.5 szükséges, és teljesen elhagyja a Python 2 támogatást.
A Tornado, akárcsak a Bottle vagy a Falcon, elhagyja a központi céljához nem szükséges funkciókat. A Tornado beépített templating rendszerrel rendelkezik a HTML és egyéb kimenetek generálásához, és mechanizmusokat biztosít a nemzetköziesítéshez, űrlapkezeléshez, cookie-k beállításához, felhasználói hitelesítéshez és CSRF-védelemhez. De kihagyja az olyan funkciókat, mint az űrlap-érvényesítés és az ORM, amelyek elsősorban a felhasználóval szembenéző webes alkalmazások számára készültek.
A Tornado kiválóan alkalmas infrastruktúra biztosítására olyan alkalmazások számára, amelyeknek szoros ellenőrzésre van szükségük az aszinkron hálózatok felett. A Tornado például nemcsak beépített aszinkron HTTP-kiszolgálót, hanem aszinkron HTTP-klienst is biztosít. Így a Tornado kiválóan alkalmas olyan alkalmazások, például webkaparók vagy botok készítésére, amelyek párhuzamosan kérdeznek le más webhelyeket, és a visszaküldött adatokra reagálnak.
Ha olyan alkalmazást szeretne létrehozni, amely a HTTP protokolltól eltérő protokollokat használ, a Tornado gondoskodik róla. A Tornado hozzáférést biztosít az alacsony szintű TCP-kapcsolatokhoz és aljzatokhoz az olyan segédprogramokhoz, mint a DNS-feloldók, valamint harmadik fél hitelesítési szolgáltatásaihoz, és a WSGI-szabványon keresztül támogatja az együttműködést más keretrendszerekkel. A dokumentáció, amely kicsi, de nem szűkös, bőséges példákat tartalmaz mindezek megvalósítására.
A Tornado kihasználja és kiegészíti a Python natív funkcionalitását az aszinkron viselkedésre. Ha Python 3.5-öt használsz, a Tornado támogatja a beépített async és await kulcsszavakat, amelyek az alkalmazások sebességének növelését ígérik. Az eseményekre adott válaszok kezelésére futures vagy callbackek is használhatók.
A Tornado szinkronizációs primitívek könyvtárát – szemaphorokat, zárakat és így tovább – biztosítja az aszinkron koroutinok közötti események koordinálásához. Vegye figyelembe, hogy a Tornado általában egyszálasan fut, így ezek a primitívek nem ugyanazok, mint a szálkezelt névrokonaik. Ha azonban a Tornadót párhuzamos folyamatokban szeretné futtatni, hogy kihasználja a több aljzatot és magot, ehhez rendelkezésre állnak eszközök.
A Tornado dokumentációja a keretrendszer minden fontosabb koncepcióját és a modell összes fontosabb API-ját lefedi. Bár tartalmaz egy mintaalkalmazást (egy webkúszót), ez elsősorban a Tornado sorbanállási moduljának bemutatására szolgál.