Hvis du utvikler en webapplikasjon og har valgt Python som språk å bygge den på, er det et smart trekk. Pythons modenhet i utvikling, robuste biblioteker og bredden av adopsjon fra den virkelige verden har bidratt til å gjøre det til en no-brainer for nettutvikling.
Nå kommer den vanskelige delen: Å velge en av de mange tilgjengelige Python-nettrammene. Det er ikke bare at antallet fortsetter å vokse, men det kan være vanskelig å finne den som passer best for din brukstilfelle. Hvis du konstruerer et raskt og skittent REST-API, trenger du ikke noe rørleggerarbeid og ledninger som kreves for et fullstendig brukervendt program med brukerinnlogginger, skjemavalidering og opplasting.
Relatert video: Opprette en enkel webapp med Python og Flask
I denne sammendraget vil vi undersøke 13 av de mest utbredte Python-nettrammene. Vi vil merke oss hvilke typer webapplikasjoner hver er best egnet til å bygge, og se på hvordan de stabler opp mot hverandre på disse seks områdene:
Installasjon: Hvor enkelt eller greit det er å sette opp rammeverket - prosjekter som ikke krever formell installasjon (det kan ganske enkelt slippes ned i et eksisterende prosjekt som en inkludert modul), krever minimal kjeleplate for å komme i gang, eller kommer med en slags forhåndskonfigurert oppsett får ekstra poeng.
Dokumentasjon: Nesten alle anstendige Python-prosjekter har dokumentasjon som går gjennom oppsett, illustrerer grunnleggende brukssaker og gir detaljer om API-ene. Her gir vi høyere karakterer til rammeverk som viser hvordan du lager en hel app som en del av opplæringen, inkluderer vanlige oppskrifter eller designmønstre, og ellers går utover plikten (for eksempel ved å gi detaljer om hvordan du kjører rammeverk under en Python-variant som PyPy eller IronPython).
Ledelse: Dette er en relativ poengsum som indikerer hvor mye arbeid som kreves for å konfigurere og vedlikeholde rammeverket. Minimale rammer scorer høyere her som standard.
Innfødte evner: Hvor mange batterier er inkludert? Høyere score går til rammeverk som gir innfødt støtte for internasjonalisering, HTML mal og et datatilgangslag. Poeng går også til rammeverk som bruker innfødt bruk av Pythons nylig introduserte innfødte støtte for asynkrone I / O-operasjoner.
Sikkerhet: Rammeverk som gir innebygde sikkerhetstiltak som CSRF-beskyttelse (cross-site request forgery) og øktadministrasjon med krypterte informasjonskapsler, får høyere karakterer.
Skalerbarhet: De fleste Python-rammer kan bruke prosjekter som Gevent eller Gunicorn for å kjøre i målestokk. Her ser vi på funksjoner som er innfødt i rammeverket som fremmer skalerbarhet, som output og sidefragmentbufring.
Hvis du er nysgjerrig på ytelsesverdiene, kan du ta en titt på TechEmpowers pågående prøveversjon, som sammenligner flere nettrammer på tvers av ulike oppgaver, med kode og metoder som er lagt ut på GitHub og blir gjenopptatt. Ikke alle rammene i denne diskusjonen blir analysert der, men det er mulig å få en god følelse av hvilke rammer som fungerer best under hva slags belastning.
Vi ser på 13 rammer i det hele tatt. Fem av disse - CubicWeb, Django, Web2py, Weppy og Zope2 - tar tilnærmingen "kjøkkenvask" og pakker inn de fleste funksjonene du kan tenke deg å ha behov for en webapplikasjon. De resterende åtte rammene - Bottle, CherryPy, Falcon, Flask, Pyramid, Tornado, Web.py og Wheezy.web - tilbyr et mer minimalistisk opptak, som handler bulk og fullstendighet for enkelhet og enkelhet.
La oss starte med tungvekter.
Tungvekt Python-nettrammer
CubicWeb
CubicWeb blir fakturert som "et semantisk rammeverk for webapplikasjoner som favoriserer gjenbruk og objektorientert design." Det er et spennende system - som bemerket av Rick Grehan da han så på det i 2011 - som understreker bruken av abstraksjoner og gjenbrukbare byggesteiner med kode som kalles "kuber", men det kan være for abstrakt eller idiosynkratisk for noen utviklere.
Kuber er programvarekomponenter som har et skjema (datamodell), enheter (programmeringslogikk) og visninger. Ved å samle flere kuber, som hver utfører sin egen oppgave, kan du komponere programvareapplikasjoner ved å bruke din egen kode og andres kode.
I sin kjerne tilbyr CubicWeb grunnleggende stillas som brukes av alle web-apper: et "lager" for datatilkoblinger og lagring; en “nettmotor” for grunnleggende HTTP-forespørsel / respons og CRUD-handlinger; og et skjema for modellering av data. Alt dette er beskrevet i Python-klassedefinisjoner. For å sette opp og administrere forekomster av CubicWeb, jobber du med et kommandolinjeverktøy som ligner det som ble brukt for Django.
CubicWeb ser ikke ut til å bruke Python 3s native async-funksjonalitet. En rundkjøringsmåte å inkludere async ville være å bruke cubicweb.pyramid-modulen til å bruke Pyramid-rammeverket som webserveren, og tegne på en gaffel Pyramid som bruker async-konstruksjoner. Men alt mer greit virker utilgjengelig for nå.
For å hente eller manipulere vedvarende data i en CubicWeb-app, bruker du Relation Query Language (RQL), som bruker vagt SQL-lignende syntaks, men er mønstret etter W3Cs SparQL. CubicWebs begrunnelse for dette er igjen abstraksjon: RQL gir en svært frakoblet rute for å knytte ulike datakilder sammen. Men etter hvert som den implementeres, ved å manuelt lage spørsmål som strenger, vil den sannsynligvis føle seg eldre for utviklere som er vant til ORM.
Det er andre hindringer for å bruke CubicWeb. For en kan oppsett være et problem. Fordi CubicWeb har mange avhengigheter, er det best å bruke det pip install å hente dem alle. Du må kanskje også utføre en viss mengde manuell tilpasning av lokalmiljøet. Dette er i sterk kontrast til andre rammer der du kjører pip install eller å slippe rammekoden i en undermappe til et annet prosjekt er alt som kreves.
Et annet potensielt problem er fraværet av en egen malmotor; generering av HTML overlates til utvikleren. Du kan overvinne dette ved å bruke et tredjeparts maleringssystem som Jinja2 eller velge en kube som gir verktøy for webgrensesnitt, for eksempel det for Boostrap HTML-rammeverket.
Et mangeårig problem med CubicWeb - mangelen på Python 3-støtte - er løst. Per juni 2016 og versjon 3.23 landet Python 3-støtte i CubicWeb, bortsett fra moduler som Twisted som ikke selv er fullstendig portet.
I likhet med Web2py, refererer CubicWeb til den lange dokumentasjonen som "boka". Det tar tid å forklare CubicWebs uvanlige tilnærming, demonstrerer hvordan du bygger noen grunnleggende applikasjoner, inkluderer API-referanser og går generelt ut av veien for å være spesifikk.
Django
I tiåret og endringen siden Django første gang dukket opp, har det blitt et av Pythons mest utbredte rammer for å lage webapplikasjoner. Django kommer med stort sett alle batterier du trenger, så det lener seg mer mot å bygge store applikasjoner enn små.
Relatert video: Opprette et enkelt nettsted med Django
Etter mange år med å sitte på versjon 1.x, gjorde Django nylig en versjonsstøt til venstre for desimaltegnet. Den største endringen i Django 2.0 er at rammeverket nå bare fungerer med Python 3.4 og nyere. Ideelt sett bør du bruke Python 3.x uansett, så den eneste grunnen til å bruke 1.x-grenen av Django er hvis du sitter fast med en gammel versjon av Python.
En sentral del av Djangos appell er distribusjonshastighet. Fordi den inneholder så mange deler du trenger for å utvikle den gjennomsnittlige webapplikasjonen, kan du komme raskt i bevegelse. Routing, URL-parsing, databasetilkobling (inkludert en ORM), skjemavalidering, angrepsbeskyttelse og mal er alt innebygd.
Du finner byggesteiner for de vanligste scenariene for nettapplikasjoner. Brukeradministrasjon finnes for eksempel på de fleste nettsteder, så Django tilbyr det som et standardelement. I stedet for å måtte lage ditt eget system for sporing av brukerkontoer, økter, passord, pålogginger / pålogginger, administratortillatelser og så videre, har Django disse funksjonene naturlig. De kan brukes som de er eller utvides for å omfatte nye brukstilfeller med et minimum av arbeid.
| CubicWeb | Django | Web2py | Weppy | Zope2 | |
|---|---|---|---|---|---|
| Tillatelse | LGPL | BSD | LGPLv3 | BSD / LGPLv3 [1] | Zope Public License |
| Innfødt HTML-malsystem | Ja | Ja | Ja | Ja | Ja |
| Innfødt ORM / dataadministrasjon | Ja | Ja | Ja | Ja | Ja |
| Utvidelsesbibliotek | Ja | Ja | Ja | Ja | Ja |
| Formularvalidering | Ja | Ja | Ja | Ja | Ja [2] |
| Forfalskningsbeskyttelse på tvers av siden | Ja | Ja | Ja | Ja | Ja |
| Brukeradministrasjon / rollebasert tilgang | Ja | Ja | Ja | Ja | Ja |
| Python 3-støtte | Ja | Ja | Nei | Ja | Nei |
| Skjemaoverføring for datamodeller | Ja | Ja | Ja | Ja | Nei |
| Svarbufring | Nei | Ja | Ja | Ja | Ja |
| Internasjonalisering støtte | Ja | Ja | Ja | Ja | Ja |
| Innfødte WebSockets-støtte | Nei | Nei [3] | Ja | Nei | Nei |
| Interaktivt utviklingsmiljø | Ja | Nei | Ja | Nei | Ja |
Django har sunne og trygge standarder som hjelper med å beskytte webapplikasjonen din mot angrep. Når du plasserer en variabel i en sidemal, for eksempel en streng med HTML eller JavaScript, blir ikke innholdet gjengitt bokstavelig med mindre du eksplisitt angir forekomsten av variabelen som sikker. Dette i seg selv reduserer mange vanlige skriptsaker på tvers av nettsteder. Hvis du vil utføre skjemavalidering, kan du bruke alt fra enkel CSRF-beskyttelse til fullstendige felt-for-felt-valideringsmekanismer som returnerer detaljert feilmelding.
En funksjon som er like rik og bred som Django, ville ikke vært mye bra uten robust dokumentasjon som følger med. Djangos dokumentasjonsside går inn i alle aspekter av rammeverket fra flere vinkler. Arbeide med Python 3 eller andre smaker av språket, gjøre sikkerhetsrett, implementere vanlige webapplikasjonskomponenter (som økter eller paginering), generere nettstedskart - de er alle dekket. API-ene for hvert lag i applikasjonen - modell, visning og mal - er også beskrevet i detalj.
Med stor kraft kommer imidlertid stor kompleksitet. Django-applikasjoner har et rykte for å være topptunge, med mange bevegelige deler. Selv en enkel Django-app med bare et par ruter krever ganske mye konfigurasjon for å komme i gang. Hvis jobben din er å gjøre noe mer enn å sette opp et par enkle REST-endepunkter, er Django nesten helt sikkert overkill.
Django har også sine særegenheter. For eksempel kan sidemaler ikke bruke callables. Eksempel: Du kan bestå {{user.name}} som en komponent i en mal, men ikke {{user.get_name ()}}. Det er en av måtene Django sørger for at maler ikke utilsiktet gjør ubehagelige ting, men disse begrensningene kan ødelegge hvis du ikke er forberedt på dem. Mens det er løsninger, har de en tendens til å ta en toll på ytelsen.
Djangos kjerne er synkron. En måte å legge til asynkronisert oppførsel på er imidlertid gjennom Django Channels-prosjektet. Dette prosjektet, et offisielt Django-tillegg, legger til asynkroniseringshåndtering for tilkoblinger og stikkontakter til Django, mens Djangos programmeringsidiomer bevares.
Web2py
I Ruby-verdenen er Ruby on Rails de facto nettrammen. DePaul University datavitenskapsprofessor Massimo Di Pierro ble inspirert av Rails til å lage et nettrammeverk i Python som det var like enkelt å sette opp og jobbe med. Resultatet er Web2py.
Web2pys største attraksjon er det innebygde utviklingsmiljøet. Når du konfigurerer en forekomst av Web2py, får du et webgrensesnitt, i hovedsak en online Python-applikasjonseditor, der du kan konfigurere appens komponenter. Dette betyr vanligvis å lage modeller, visninger og kontrollere, hver beskrevet via Python-moduler eller HTML-maler. Noen få eksempler på apper kommer med Web2py ut av esken. Du kan ta dem fra hverandre for å se hvordan de fungerer, eller utnytte dem som startmaler for å lage dine egne apper.
Utviklere distribuerer vanligvis Web2py ved bare å laste ned kildekoden og bruke den. Men for mindre tekniske brukere på Windows eller MacOS, tilbyr skaperne av Web2py versjoner som egentlig er frittstående servere. Last ned, pakk ut og kjør en av disse versjonene, så får du en lokal webserver med en forhåndskonfigurert kopi av Web2py innebygd. Dette er en fin måte å få et bein på å lage en Web2py-app, som deretter kan distribueres. andre steder etter behov.
Web2pys nettgrensesnitt ble bygget med Bootstrap 2.16.1, så det er lett å se på og lett å navigere. Nettleseredigereren er ingen erstatning for en fullverdig IDE, men den er utstyrt med nyttige hjelpemidler som linjenummerering og Python-syntaksmarkering (inkludert automatisk innrykk). Også inkludert er et raskt webgrensesnitt til Python-skallet, slik at du kan samhandle med Web2py fra kommandolinjen om nødvendig - en fin konsesjon til eksperter.
Dataabstraheringssystemet som brukes i Web2py fungerer litt annerledes enn Djangos ORM og andre ORMer inspirert av det (som Peewee). Disse systemene bruker Python-klasser for å definere modeller, hvor du i Web2py bruker konstruktorfunksjoner som definere_tabell for å instantiere modeller. Det er sannsynlig at de fleste av disse forskjellene bare skramler for folk som allerede har erfaring med den ene og begynner å bruke den andre; de er omtrent like kompliserte for nykommere. Det er ikke sannsynlig at du vil ha noen problemer med å koble Web2py til en dataleverandør, da den snakker med nesten alle større eksisterende databaser.
En virkelig nyttig databaserelatert funksjon er muligheten til å generere et diagram av modellene, jo bedre å visualisere hvordan modellene dine forholder seg til hverandre. Du må imidlertid installere pygraphviz-biblioteket for å aktivere den funksjonen.
Web2py leverer mange andre profesjonelle komponenter: internasjonaliseringsfunksjoner, flere hurtigbufringmetoder, tilgangskontroll og autorisasjon, og til og med fronteffekter (for eksempel en datovelger i skjemaer) via integrert støtte for jQuery og AJAX. Kroker for ekstern og intern mellomvare er også inkludert, selv om du ikke har lov til å bruke mellomvare for å erstatte kjerne Web2py-funksjoner.
En vesentlig begrensning av Web2py er at den bare er kompatibel med Python 2.x. For det første betyr dette at Web2py ikke kan bruke Python 3s async-syntaks. For to, hvis du stoler på eksterne biblioteker som er eksklusive for Python 3, er du heldig. Det arbeides imidlertid med å gjøre Web2py Python 3-kompatibel, og det er veldig fullført i skrivende stund.
Det er ikke rart at Web2pys dokumentasjon blir referert til som "boka". For det første dekker det en svimlende mengde materiale på Web2py, Python og distribusjonsmiljøene som brukes til begge deler. For det andre er den skrevet i en svært tilgjengelig, fortellende stil. For det tredje snakker den grundig om vanlige scenarier for applikasjonsbygging. Det er for eksempel et helt kapittel om bruk av jQuery (pakket med Web2Py) for å bygge AJAX-applikasjoner.
Weppy
Weppy føles som et halvt merke mellom den minimale enkelheten i Flask og fullstendigheten til Django. Mens du utvikler en Weppy-app, har Flash rett, kommer Weppy med mange funksjoner som finnes i Django, som datalag og autentisering. Dermed passer Weppy til apper som spenner fra ekstremt enkle til beskjedent sofistikerte.
Ved første øyekast ser Weppy-kode ut som Flask- eller Flaskekode. Få instruksjoner er nødvendig for å få et grunnleggende nettsted med én rute i gang. Ruter kan beskrives gjennom funksjonsdekoratører (på den enkle måten) eller programmatisk, og syntaksen for å gjøre dette hugger tett på Flask / Bottle. Mal fungerer omtrent det samme, bortsett fra mindre variasjoner i syntaksen.
Weppy står i kontrast til de andre rammene ved å inkludere noen funksjoner de bare inneholder som plugin-moduler eller tillegg. For eksempel har verken Flask eller Bottle et innebygd ORM eller et datastyringssystem. Weppy inkluderer en ORM, om enn en basert på pyDAL-prosjektet i stedet for den langt mer populære SQLAlchemy. Weppy støtter til og med skjemamigrasjoner, som Django støtter som en del av sin ORM (også, Djangos migrasjonssystem er mye mer automatisert). Mens Weppy har en utvidelsesmekanisme, er listen over offisielt godkjente tilleggsprogrammer liten, langt mindre enn katalogen med utvidelser for Flask.
Rammeverk med lettere vekt som Weppy brukes ofte til å bygge RESTful APIer, og Weppy er utstyrt med bekvemmelighetsfunksjoner for det formålet. Sett en @service dekoratør på en rute, og dataene du returnerer blir automatisk formatert etter ditt valg av JSON eller XML.
Weppy inkluderer andre funksjoner som virker mer i tråd med et større rammeverk, men de implementeres uten bulk. Eksempler: Datavalideringsmekanismer, skjemahåndtering, responsbuffering og brukervalidering. I alle disse tilfellene tar Weppy en "akkurat nok" tilnærming. Funksjonene som tilbys er ikke så komplette som du kan finne i et Django-størrelse rammeverk, men en utvikler trenger ikke å investere mye arbeid i å gjøre dem nyttige, og de kan alltid utvides etter hvert.
En annen funksjon som finnes i Weppy vanligvis forbundet med et mer tungtvektig rammeverk er støtte for internasjonalisering. Strenger i maler kan oversettes i henhold til lokale filer som følger med applikasjonen, som er enkle Python-ordbøker. Valg av språk kan også angis ved å analysere nettleserforespørselen (det vil si HTTP-overskriften Godta-språk) eller ved å binde en oversettelse til en bestemt rute.
Weppys dokumentasjon har samme smak som selve rammeverket. Det er rent, lesbart og skrevet for å bli konsumert av mennesker. Bortsett fra det vanlige "Hello World" -eksemplet, inneholder det en fin gjennomgangsveiledning som lar deg lage et mikrobloggingssystem som et startprosjekt.
Langsiktige planer for Weppy inkluderer støtte for asynkronisering og stikkontakter som førsteklasses enheter. Weppys utviklere planlegger å introdusere disse funksjonene i versjon 2.0, og deretter kreve Python 3.7 eller bedre for alle fremtidige versjoner av Weppy.
| Poengkort | Innfødt evne (20%) | Ledelse (20%) | Installasjon (20%) | Dokumentasjon (20%) | Sikkerhet (10%) | Skalerbarhet (10%) | Total poengsum (100%) |
|---|---|---|---|---|---|---|---|
| Flaske 0,12 | 8 | 10 | 10 | 8 | 7 | 7 | 8.6 |
| CherryPy 17.0.0 | 7 | 9 | 9 | 9 | 8 | 8 | 8.4 |
| CubicWeb 3.26.4 | 10 | 8 | 7 | 10 | 9 | 7 | 8.6 |
| Django 2.1 | 10 | 8 | 8 | 10 | 10 | 10 | 9.2 |
| Falcon 1.4.1 | 7 | 10 | 8 | 8 | 7 | 7 | 8.0 |
| Kolbe 1.0.2 | 8 | 9 | 8 | 9 | 8 | 8 | 8.4 |
| Pyramid 1.9.2 | 8 | 8 | 8 | 10 | 9 | 7 | 8.4 |
| Tornado 4.3 | 8 | 9 | 9 | 8 | 8 | 7 | 8.3 |
| Web.py 0,39 | 8 | 8 | 10 | 8 | 9 | 8 | 8.5 |
| Web2py 2.16.1 | 10 | 9 | 7 | 10 | 9 | 8 | 8.9 |
| Weppy 1.2.11 | 10 | 8 | 9 | 9 | 10 | 9 | 9.1 |
| Wheezy.web 0.1.485 | 9 | 9 | 8 | 8 | 8 | 8 | 8.4 |
| Zope2 2.13.24 | 10 | 8 | 7 | 9 | 9 | 9 | 8.6 |
