webbramverk är kraftfulla verktyg. De abstrakt de gemensamma aspekterna av att bygga webbplatser och API: er och tillåter oss att bygga rikare, mer stabila applikationer med mindre ansträngning.
ett brett utbud av webbramar är tillgängligt för oss i Python. Vissa är beprövade favoriter med stora ekosystem och samhällen. Andra utmärker sig i nischanvändningsfall eller för specifika typer av utveckling. Fortfarande, andra är upp-och-uppstickare med tvingande nya skäl att överväga. Läs vidare för att utforska alternativen och hitta vad som fungerar bäst för dig.
om du redan vet vad som intresserar dig, använd länkarna nedan för att hoppa framåt:
- hur man väljer rätt ramverk för dina behov
- Full-Stack Frameworks vs. Microframeworks vs. Asynkrona ramar
- Python Full-Stack ramar
- Microframeworks för Python
- asynkrona ramar för Python
- vilken Python webbramverk är bäst för dig?
om du vill ha hjälp med att bestämma kan du också hoppa direkt till vår rekommendationer översikt.
- hur man väljer rätt ramverk för dina behov
- Full-Stack Frameworks vs. Microframeworks vs. Asynchronous Frameworks
- Full-Stack Python ramar
- Django
- Pyramid
- Web2Py
- TurboGears
- masonit
- Microframeworks för Python
- kolv
- flaska
- H3: CherryPy
- Falk
- asynkrona ramar för python
- Sanic
- FastAPI
- Starlette
- Tornado
- vilket Python-webbramverk är bäst för dig?
hur man väljer rätt ramverk för dina behov
ramar är utformade för att lösa olika problem och göra kompromisser för att bättre tjäna sina avsedda målgrupper. Om alla hade samma mål skulle vi bara behöva en ram! När du utvärderar ramar inkluderar några viktiga överväganden:
- Vad är den troliga eventuella storleken och komplexiteten i det du bygger?
- föredrar du att välja dina egna bibliotek, konfiguration och applikationsstruktur eller vill ha en mer kurerad uppsättning alternativ som valts för dig i förväg?
- hur viktigt är resultatet för ditt projekt?
- hur snabbt vill du kunna utveckla och distribuera din applikation?
- hur länge kommer din ansökan att vara och hur många utvecklare kommer sannolikt att arbeta med det?
tänk dessutom på kvaliteten på tillgänglig dokumentation för potentiella val och storleken på samhället runt ett projekt – detta påverkar både utbudet av befintliga plugins eller integrationer som du kan utnyttja för att göra utvecklingen snabbare och sannolikheten för att kunna få hjälp när du fastnar.
Tänk på dessa aspekter när du utforskar dina alternativ – det finns många av dem! Beroende på projektets livslängd, överväga också om ett ramverk sannolikt kommer att växa med dig. Kommer det att vara en bra passform för din ansökan både nu och i framtiden?
Full-Stack Frameworks vs. Microframeworks vs. Asynchronous Frameworks
Python frameworks kan grovt delas in i tre läger, full-stack frameworks, microframeworks och asynchronous frameworks.
full-stack ramar är i allmänhet inriktade på att bygga större, fullfjädrad applikationer och erbjuder en hel del gemensamma funktioner ur lådan. Om du vill bygga något komplext snabbt eller vill ha rimliga standardvärden för hur du sätter ihop en applikation utan att göra alla val själv, är ett ramverk med full stack ett bra val. Full-stack ramar ger dig i allmänhet förnuftiga standardvärden för att kommunicera med databaser, Mall dina åsikter, hantera köer, bakgrundsjobb och andra vanliga aspekter av större applikationer.
Microframeworks är i allmänhet inriktade på att tillhandahålla en liten kärna av funktionalitet och bjuda in utvecklaren att göra sina egna val om vilka bibliotek och tekniker som ska läggas till för annan funktionalitet. Detta har fördelen att möjliggöra mycket mer kontroll över applikationsdesign och kan resultera i bättre applikationsprestanda. De kräver vanligtvis att utvecklaren väljer sitt eget databasabstraktionslager och andra bibliotek. Microframeworks kan vara ett utmärkt val för mindre, snävare fokuserade applikationer, API-utveckling eller applikationer där prestanda är viktigare.
asynkrona ramar är inriktade på att leverera höga prestanda genom att tillåta ett mycket stort antal samtidiga anslutningar. Medan du kan öka samtidigheten hos de flesta synkrona ramar avsevärt genom att para ihop dem med asynkrona servrar som gevent, går nativt asynkrona ramar ett steg längre med en helt asynkron stack. Generellt kräver asynkrona ramar mer noggrannhet i programmeringsstil och har en mer begränsad uppsättning plugins. Asynkrona ramar är bra när du behöver tillhandahålla en specifik funktionalitet med mycket hög volym.
Full-Stack Python ramar
Django
Django är den mest populära full-stack ram för Python. Det har ett välförtjänt rykte för att vara mycket produktivt när man bygger komplexa webbappar. Dubbat ”webbramen för perfektionister med deadlines”, är dess fokus snabb utveckling med väldokumenterade alternativ för vanliga fall.
Django har funnits i mer än ett decennium (första utgåvan 2006) och den är mogen, omfattande, väldokumenterad och har ett mycket stort samhälle. Det är ett uppfattat ramverk, vilket innebär att det fattar många beslut för utvecklaren. Positiva med detta tillvägagångssätt gör det snabbare att starta utveckling,” välsignade ” integrationer som bara fungerar och mer utrymme för att fokusera på de anpassade behoven i ditt projekt istället för vilka bibliotek som ska användas. Dessutom tenderar Django-projekt att se ganska lika ut, vilket gör det lättare för utvecklare att snabbt rampa upp projekt som är nya för dem och för lag att organisera sina ansträngningar konsekvent.
Django erbjuder mycket ur lådan, inklusive sin egen object-relational mapper (ORM) för att arbeta med databaser, en standardmetod för autentisering och auktorisering, ett automatiskt genererat admingränssnitt (användbart för snabb prototypning), integrerad caching och mer.
bra för projekt små och stora, Django kan skalas väl för rimliga laster och har använts av många hög trafik platser inklusive Instagram, Mozilla, och Washington Post. Django har asynkrona funktioner i version 3.0, med async vyer och middleware kommande i version 3.1.
medan traditionellt fokuserat på full-stack webbapplikationer, Django är också väl lämpad för att utveckla API-bara backend applikationer. Mogna integrationer finns för att snabbt bygga både REST och GraphQL API med Django.
nedersta raden: De facto-standarden av goda skäl, Django är det dominerande fullstackramverket för Python. Utmärkt för att komma igång snabbt och med en beprövad meritlista för skalning, Django är en bra passform för många projekt. Om du föredrar att anpassa mer än Django tillåter, överväga Pyramid och microframeworks. Om du behöver mycket hög samtidighet, utforska de asynkrona ramarna.
Pyramid
Pyramid är en annan populär full-stack ram. Med rötter i Pylons-projektet har det varit under utveckling så länge som Django och är också ett mycket moget alternativ.
i motsats till Django är Pyramid mindre uppfattad. Det ger routing, renderare och kommandoradsverktyg för bootstrapping ett projekt, men ger dig möjlighet att välja ditt eget databaslager, mallsystem och mer via en omfattande uppsättning plugins.
med sin grundläggande flexibilitet, Pyramid är en trevlig medelväg om du försöker att välja mellan en full-stack ram eller en microframework. Pyramid kan du starta mindre än Django och växa komplexiteten i din kodbas som behövs. Denna flexibilitet i biblioteksstöd kan vara viktig när du har specialiserade krav eller samverkar kraftigt med system som Django kanske inte integrerar med well (äldre databaser är ett vanligt exempel).
Pyramid har en dedikerad fanbas och ett aktivt samhälle som uppskattar sin växande natur och grundläggande flexibilitet. Om du går med Pyramid, förvänta dig extra arbete för att välja komponenter på förhand. Detta kan dock vara bra tid på lång sikt om det gör att du permanent kan påskynda utvecklingsaspekter som är kritiska för dig.
Bottom line: en kraftfull blandning av flexibilitet och kontroll gör Pyramid ett övertygande alternativ till Django för vissa projekt.
Web2Py
web2py är ett ramverk med full stack som fokuserar på enkel utveckling, med egna webbaserade IDE -, debugger-och distributionskontroller. Det inspirerades av Ruby on Rails och Django och följer en MVC-design (Model View Controller).
projektet startade som ett undervisningsverktyg och har en betoning på gemensam funktionalitet med förnuftiga standardvärden. Den har en mycket lättare inlärningskurva än de flesta ramar och är extremt lätt att installera och komma igång med. Dokumentationen är stor och massor av funktionalitet kommer inbyggd, inklusive en schemaläggare, 2FA hjälpare, och en trevlig biljettsystem som blir automatiskt befolkas av defekter i produktionen.
web2py har en mindre gemenskap än Django och några andra ramar, men en mycket vänlig. Massor av tutorials och resurser finns tillgängliga.
nedersta raden: Bäst lämpad för nyare programmerare eller utvecklare experimentera med webbutveckling. Inte en bra passform för nya större kommersiella projekt.
TurboGears
faktureras som ”ram som skalar med dig”, TurboGears kan du starta din ansökan så enkelt som en enda fil (som en microframework) eller skala hela vägen upp till en full-stack app med kommandoradsverktyg för att stödja hanteringen. I den meningen liknar det Pyramid, med fördelen av mer kontroll/anpassning på bekostnad av att kräva mer arbete på förhand för att bestämma hur du vill strukturera din app och vilka bibliotek du vill integrera.
standard ORM för TurboGears är den utmärkta SQLAlchemy. TurboGears har intressanta skillnader i hur det hanterar routing och dess standardmall lösning. Till skillnad från de flesta fullstackramverk hanteras routing genom en objekthierarki istället för att mappa reguljära uttryck till styrenheter (mappning är tillgänglig som ett alternativ). Standardmallsystemet för TurboGears är Kajiki, ett XSLT-inspirerat språk.
Bottom line: TurboGears skalar bra med mycket kontroll från små projekt till större. Pyramid erbjuder dock ett liknande utbud av flexibilitet och är förmodligen ett bättre val för de flesta.
masonit
Masonite är ett relativt nytt (2017) ramverk som har en liknande designfilosofi som Django men syftar till att förbättra vissa vanliga smärtpunkter. Det erbjuder förbättrad kod byggnadsställningar, routing middleware, och inbyggt stöd för e-post skicka, S3 uppladdning, och kö.
Masonites arkitektur är mycket utbyggbar och dess integrerade funktioner är imponerande. Dokumentationen är bra och det finns en aktiv Slack-kanal för support. Den använder sin egen ORM, Orator, baserat på ActiveRecord.
som en nyare ram är Masonites samhälle liten men växande. Det är aktivt förbättrat och har mycket att tycka om. Med tanke på dess mindre mindshare är det svårare att hitta utvecklare som är bekanta med Masonite men om de extra out-of-the-box-funktionerna passar bra för dina behov kan det påskynda din utveckling.
Bottom line: en nyare utmanare, Masonite gör vanliga uppgifter som e-posthantering, laddar upp filer till molnet och betalningshantering enkelt ur lådan.
Microframeworks för Python
kolv
Flask är en otroligt populär lösning för både webbappar och mikrotjänster. Ursprungligen inspirerad av Ruby framework Sinatra, Flask fokuserar på att tillhandahålla en kärna uppsättning funktioner (begäran hantering, routing, WSGI efterlevnad, Mall) och erbjuder en modulär design för tillägg av allt annat du behöver.
som ett resultat är det otroligt enkelt att starta en applikation. Du kan bygga en fungerande webbapplikation på bara några rader:
from flask import Flask, escape, requestapp = Flask(__name__)@app.route('/')def hello(): name = request.args.get("name", "World") return f'Hello, {escape(name)}!'
Flask har ett brett utbud av tillgängliga tillägg, så att du kan integrera dina egna val för lagring, databasinteraktion, autentisering och auktorisering, säkerhet och mer. Det tar tid att integrera och ställa in dina val, men appar kan byggas stegvis och innehåller inte bibliotek och kod för saker som din applikation inte använder.
Flask-appar startar vanligtvis i en enda fil, men kan skala för att vara mycket stora. Det finns vanliga mönster för att ordna flask apps och flask erbjuder också ritningar som ett sätt att göra större applikationer mer modulära och hanterbara.
Bottom line: extremt flexibel, Flask är utmärkt för användarvända webbappar, API: er och mikrotjänster. Flask är den mest populära mikroramen för Python.
flaska
Bottle har en liknande syntax som Flask (den föregår den faktiskt med ett år), men distribueras som en enda fil utan beroenden utanför python-standardbiblioteket. Detta gör det enkelt att köra i alla miljöer, inklusive platser där det är svårt att installera bibliotek. Det betyder också att beroendehantering kan vara trivial, vilket kan vara bra för mindre projekt.
from bottle import route, run, template@route('/hello/<name>')def index(name): return template('<b>Hello {{name}}</b>!', name=name)run(host='localhost', port=8080)
funktionsuppsättningen är ganska lik Flask, men det aktiva samhället är mycket mindre. De tillgängliga pluginsna är också mer begränsade. Dessutom finns det färre handledning och det kan vara svårare att hitta kodexempel eller få hjälp.
flaskan är mestadels inriktad på appar med mycket små kodbaser och har inte en tydlig väg för skalningskodorganisation eftersom saker blir komplexa. Enkelhet är fokus. Att ha färre beroenden kan förenkla distributionen mycket (håll bara fast bottle.py i din projektkatalog) och få dig från en prototyp till en produktionsapp snabbare.
nedersta raden: Perfekt för personliga projekt, små appar eller distributionsscenarier där det är svårt att hantera komplexa beroenden.
H3: CherryPy
CherryPy är ett annat moget mikroramverk (runt sedan 2002) med sina egna fans. En stor skillnad från kolv och flaska är att CherryPy är objektorienterad och fokuserar på att vara så ”pythonisk” som möjligt. På ett annat sätt syftar CherryPy till att skriva en webbapp som liknar att skriva allmän python-kod som möjligt. Låt oss titta på ett exempel:
import cherrypyclass HelloWorld(object): @cherrypy.expose def index(self): return "Hello World!"cherrypy.quickstart(HelloWorld())
Du kan se att appen definieras som en klass, i motsats till den funktionsbaserade metoden för Flask. Även själva routingen är objektbaserad; dekoratören ’@cherrypy ’ markerar vilka objektmetoder som ska förvandlas till rutter, där dekoratörerna i Flask definierar själva rutterna. Vissa utvecklare föredrar denna form av implicit routing medan andra tycker att det är utmanande.
en av Cherrypys styrkor är dess webbserver, som är buntad i ramverket. Det är snabbt, produktionsklart, HTTP / 1.1-kompatibel, trådpoolad och kan användas med alla Python WSGI-applikationer. Faktum är att vissa utvecklare använder Cherrypys webbserver för att köra andra (icke-CherryPy) WSGI-appar eftersom det är så enkelt att installera och använda.
CherryPy innehåller också en hel del inbyggd funktionalitet, inklusive sessionshantering, autentisering, statiska innehållshanterare, caching, profilering och mer. Plugins finns tillgängliga som utnyttjar en rik uppsättning förlängningspunkter.
Cherrypys community är mycket mindre än Flask, vilket innebär en mindre grupp av plugins, Färre handledning etc.
nedersta raden: Värt en titt om du föredrar en objektorienterad utvecklingsstil.
Falk
Falcon är ett prestationsfokuserat ramverk för att bygga REST API: er och mikrotjänster. Med tanke på dess fokus på hastighet, Falcon ger en begränsad uppsättning funktioner: routing, middleware, krokar, stark fel/undantag hantering, och WSGI hjälpare att göra enhetstestning lätt.
Falcon tappar något intresse för användarvända appar och fokuserar på att betjäna JSON genom REST endpoints. Notera resten verb (GET) i detta kodexempel:
import falconclass QuoteResource: def on_get(self, req, resp): """Handles GET requests""" quote = { 'quote': ( "I've always been more interested in " "the future than in the past." ), 'author': 'Grace Hopper' } resp.media = quoteapi = falcon.API()api.add_route('/quote', QuoteResource())
Med tanke på dess inställning och singulära fokus är Falcon radikalt snabbare (20-75x!) än Django och kolv i riktmärken för mycket grundläggande förfrågningar. Andra starka aspekter av Falcon är idiomatiska HTTP – felsvar (en vanlig smärtpunkt vid konstruktion av API: er) och enkel undantagshantering. Den körs på PyPy och stöder Cython på CPython, två alternativ att överväga för maximal prestanda.
om du gillar tanken på Falcon men vill ha en mer fullfjädrad lösning, ta en titt på Hug, ett ramverk byggt ovanpå Falcon som lägger till versionshantering, automatisk dokumentation och typdriven automatisk validering.
Bottom line: Om du vill bygga högpresterande REST/JSON API: er kan Falcon vara för dig.
asynkrona ramar för python
Sanic
Sanic är en relativt ny (första utgåvan 2016) asynkron webbramverk och server, ”skriven för att gå snabbt”.
medan de flesta av full-stack och microframeworks på denna lista har funnits i ett decennium eller mer, har tillägget av asyncio i Python 3.5+ öppnat dörrarna till en helt ny generation av högpresterande asynkrona ramar. Sanic är ett av de mest etablerade alternativen i denna nya generation.
Sanics syntax är ganska lik Flask, med tillägg av end-to-end async-stöd:
from sanic import Sanicfrom sanic.response import jsonapp = Sanic()@app.route("/")async def test(request): return json({"hello": "world"})if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)
den har starka routingfunktioner, middleware, streaming, WebSocket-stöd, cookiehantering, ruttversionering, statisk filbetjäning och mer. Sanic är en naturlig passform om du behöver hantera långlivade anslutningar som WebSockets eller behöver en hög nivå av samtidighet ur ditt API.
med en asynkron ram, måste du svepa huvudet runt asynkron programmering i Python, med dess relaterade varningar, komplexitet och felsökning utmaningar. Det är värt att ta sig tid att bedöma om du verkligen behöver prestanda för ett helt async API, men om du gör det är Sanic värt en titt!
nedersta raden: Ett moget, etablerat alternativ för att utveckla högpresterande asynkrona API: er
FastAPI
FastAPI är nyare än Sanic (första utgåvan i början av 2019) men får fart snabbt. Det utmärker sig på att bygga REST eller GraphQL API: er, och kan hantera synkrona förfrågningar, asynkrona förfrågningar, streaming och websockets.
det har också inbyggt stöd för autentisering och auktorisering, datavalidering, JSON-serialisering och har automatisk API-dokumentation enligt OpenAPI-standarden.
from fastapi import FastAPIapp = FastAPI()@app.get("/")def read_root(): return {"Hello": "World"}@app.get("/items/{item_id}")def read_item(item_id: int, q: str = None): return {"item_id": item_id, "q": q}
funktionen för FastAPI är verkligen imponerande och den träffar en söt plats med sin kombination av flexibilitet och enkel utveckling. Det är mycket eftertänksamt utformade och utnyttjar typ antyder och beroende injektion i stort sett för att minska buggar i utvecklingen. Dessutom är Fastapis dokumentation och redaktörsstöd utmärkt.
Fastapis syntax är ganska lik Flask, vilket gör det till ett bra val om du vill migrera befintliga Flask-kodbaser till en helt async-lösning.
nedersta raden: En ram på uppgång, FastAPI är värt att utforska för ditt nästa async-projekt.
Starlette
Starlette är en lätt ASGI-ram och verktygslåda som ger primitiver och modulär integration så att du kan bygga din applikation med vilken grad av kontroll du vill.
ASGI är en efterföljare till WSGI, vilket ger ett standardgränssnitt mellan async-kapabla webbservrar, ramverk och applikationer. Observera att ASGI stöder både synkrona och asynkrona operationer och ASGI innehåller en WSGI bakåtkompatibilitet implementering.
som ett ramverk knyter Starlette samman sina olika funktioner för dig, inklusive WebSocket-stöd, GraphQL-stöd, bakgrundsuppgifter i processen, Sessions-och cookiestöd, CORS, GZip, statiska filer och mer. Du kan också använda varje bit självständigt, plocka och välja specifika delar av verktygslådan.
eftersom Starlette är en verktygslåda först kan användning som ramverk känna sig mer kompositionell, med oro som exponeras separat:
from starlette.applications import Starlettefrom starlette.responses import JSONResponsefrom starlette.routing import Routeasync def homepage(request): return JSONResponse({'hello': 'world'})app = Starlette(debug=True, routes=)
FastAPI är faktiskt byggt ovanpå Starlette, lägger till syntax bekvämlighet och ytterligare funktioner. För de flesta lag är FastAPI förmodligen ett bättre ställe att börja, men Starlette erbjuder maximal kontroll och en kraftfull uppsättning primitiver.
Bottom line: Om du vill arbeta nära metallen på dina egna async-verktyg är Starlette en fantastisk plats att börja.
Tornado
Tornado är ett äldre async-webbramverk, skapat långt innan asyncio-funktioner bakades i Python. Ursprungligen skapad av FriendFeed och släpptes först 2009, är Tornado en beprövad lösning för skalning i tiotusentals öppna anslutningar i Python.
kärnan i Tornado är en mycket anpassningsbar applikationsmodell med starka underliggande nätverksbibliotek. Det inkluderar routing, Mall, session och cookiehantering, inbyggt WebSocket-stöd, säkerhetsfunktioner och har ett moget utbud av alternativ för olika datalager. Det är mindre fullfjädrad än något som Django men har mycket fler funktioner inbyggda än en typisk microframework. Tornado använder verb – stil metoder på begäran hanterare klasser, så det lämpar sig för en mer objektorienterad utveckling stil:
import tornado.ioloopimport tornado.webclass MainHandler(tornado.web.RequestHandler): def get(self): self.write("Hello, world")def make_app(): return tornado.web.Application()if __name__ == "__main__": app = make_app() app.listen(8888) tornado.ioloop.IOLoop.current().start()
Tornado fortsätter att aktivt förbättras och underhållas, med en robust gemenskap. Det används av Facebook, Quora och andra i deras produktionsarkitektur.
Tornado 6 + använder asyncio under huven och kräver Python 3.5+, men Tornado 5 kan användas med Python 2.7 och nyare. Körs på Python 3.5+, Tornado asynkrona coroutines använder den ursprungliga` async ` / ` väntar ’ syntax. För tidigare versioner erbjuder Tornado en generatorsyntax som har liknande funktioner. I synnerhet har Tornado en mogen bro för Twisted, vilket gör att du kan köra både vridna appar och bibliotek ovanpå Tornado.
Bottom line: en beprövad lösning för skalning i massiva antal samtidiga förfrågningar, Tornado är värt att utforska om du vill ha ett etablerat alternativ med en stark gemenskap, är knutna till äldre kodbaser eller måste använda äldre versioner av Python.
vilket Python-webbramverk är bäst för dig?
som det borde vara klart från den här listan finns det många bra alternativ. Faktum är att det finns många andra ramar tillgängliga för Python – vi har avsiktligt begränsat den här artikeln till bara de ramar vi tror är mest värda att överväga 2020.
ett bra ställe att börja är de kriterier som vi nämnde i början av denna artikel. Vilka är dina mål? Vill du experimentera med något nytt, bygga något snabbt med beprövad teknik eller lära dig nya färdigheter? Hur många människor kommer att arbeta på din kodbas och hur länge kommer det att vara runt? Dessa är alla användbara ledtrådar till rätt val.
det finns ingen ram som är perfekt för alla, men här är några allmänna förslag:
- Om du funderar på att komma igång snabbt med en väletablerad lösning där resurser kommer att vara lätt att hitta, använda Django eller kolv
- Om du gillar att starta små och förstå (eller kontrollera) alla delar av din ansökan, utforska Pyramid, kolv eller CherryPy
- Om du bygger ett API eller microservice som måste vara mycket presterande, titta in Falcon, fastapi eller sanic.
- Om du är en början programmerare eller bara lära sig att göra webbutveckling, web2py eller flaska är vänliga, enkla sätt att komma igång
- Om du funderar på att utforska up-and-comings ramar med nya ideer och sätt att göra saker, Kolla in Masonite och FastAPI
hittade du den här artikeln till hjälp eller se något du inte håller med eller tycker bör förbättras. Låt oss veta, vi värdesätter din feedback!