Hvis du udvikler en webapplikation, og du har valgt Python som det sprog, du skal bygge den på, er det et smart træk. Pythons modenhed med udvikling, robuste biblioteker og bredden af den virkelige adoption har bidraget til at gøre det til en no-brainer til webudvikling.
Nu kommer den hårde del: At vælge en af de mange tilgængelige Python-webrammer. Det er ikke kun, at antallet fortsætter med at vokse, men det kan være svært at finde den, der passer bedst til din brugssag. Hvis du konstruerer en hurtig og snavset REST API, har du ikke brug for nogen steder i nærheden af VVS og ledninger, der kræves for en fuld brugervenlig applikation med brugerlogins, formvalideringer og uploadhåndtering.
Relateret video: Oprettelse af en simpel webapp med Python og Flask
I denne sammenfatning undersøger vi 13 af de mest udbredte Python-webrammer. Vi vil bemærke, hvilke typer webapplikationer hver er bedst egnet til opbygning og se på, hvordan de stabler op mod hinanden inden for disse seks områder:
Installation: Hvor let eller ligetil det er at oprette rammen - projekter, der ikke kræver formel installation (det kan simpelthen slippes ned i et eksisterende projekt som et inkluderet modul), kræver minimal kedelplade for at komme i gang eller komme med en slags forudkonfigureret opsætning få ekstra point.
Dokumentation: Næsten ethvert anstændigt Python-projekt har dokumentation, der gennemgår opsætningen, illustrerer grundlæggende brugssager og giver detaljer om API'erne. Her giver vi højere karakterer til rammer, der viser, hvordan du opretter en hel app som en del af vejledningen, inkluderer almindelige opskrifter eller designmønstre og ellers går ud over pligtopkaldet (f.eks. Ved at give detaljer om, hvordan du kører ramme under en Python-variant som PyPy eller IronPython).
Ledelse: Dette er en relativ score, der angiver, hvor meget arbejde der kræves for at konfigurere og vedligeholde rammen. Minimale rammer scorer højere her som standard.
Native muligheder: Hvor mange batterier er inkluderet? Højere score går til rammer, der giver indbygget support til internationalisering, HTML-skabelonlægning og et dataadgangslag. Punkter går også til rammer, der bruger native Pythons nyligt introducerede native support til asynkrone I / O-operationer.
Sikkerhed: Rammer, der giver indbyggede sikkerhedsforanstaltninger som CSRF-beskyttelse (cross-site request forfalskning) og sessionadministration med krypterede cookies, får højere karakterer.
Skalerbarhed: De fleste Python-rammer kan bruge projekter som Gevent eller Gunicorn til at køre i skala. Her ser vi på funktioner, der er hjemmehørende i rammen, der fremmer skalerbarhed, som output og sidefragmentcaching.
Hvis du er nysgerrig efter præstationsbenchmarks, skal du kigge på TechEmpowers igangværende række forsøg, der sammenligner flere webrammer på tværs af forskellige opgaver med kode og metoder, der er sendt til GitHub og underkastes konstant revurdering. Ikke alle rammerne i denne diskussion analyseres der, men det er muligt at få en god fornemmelse af, hvilke rammer der fungerer bedst under hvilke slags belastninger.
Vi ser i alt 13 rammer. Fem af disse - CubicWeb, Django, Web2py, Weppy og Zope2 - benytter sig af "køkkenvask" -metoden og pakker de fleste af de funktioner, du kan forestille dig, til en webapplikation. De resterende otte rammer - Bottle, CherryPy, Falcon, Flask, Pyramid, Tornado, Web.py og Wheezy.web - tilbyder et mere minimalistisk tag, der handler bulk og fuldstændighed for enkelhed og lethed.
Lad os starte med tungvægtene.
Kraftige Python-webrammer
CubicWeb
CubicWeb faktureres som "en semantisk ramme til webapplikationer, der favoriserer genbrug og objektorienteret design." Det er et spændende system - som bemærket af Rick Grehan, da han kiggede på det tilbage i 2011 - der understreger brugen af abstraktioner og genanvendelige byggesten af kode kaldet "terninger", men det kan være for abstrakt eller idiosynkratisk for nogle udviklere.
Kuber er softwarekomponenter, der har et skema (datamodel), enheder (programmeringslogik) og visninger. Ved at samle flere terninger, der hver udfører sin egen opgave, kan du komponere softwareapplikationer ved at genbruge din egen kode og andres kode.
I sin kerne leverer CubicWeb grundlæggende stilladser, der bruges af enhver webapp: et "lager" til dataforbindelser og lagring; en “webmotor” til grundlæggende HTTP-anmodning / respons og CRUD-handlinger; og et skema til modellering af data. Alt dette er beskrevet i Python-klassedefinitioner. For at opsætte og administrere forekomster af CubicWeb arbejder du med et kommandolinjeværktøj svarende til det, der bruges til Django.
CubicWeb ser ikke ud til at bruge Python 3s native async-funktionalitet. En rundkørsel til at inkludere async ville være at bruge cubicweb.pyramid-modulet til at bruge Pyramid-rammen som webserveren og trække på en gaffel af Pyramid, der bruger async-konstruktioner. Men alt mere ligetil synes utilgængeligt for nu.
For at hente eller manipulere vedvarende data i en CubicWeb-app bruger du Relation Query Language (RQL), som anvender svagt SQL-lignende syntaks, men er mønstret efter W3C's SparQL. CubicWebs begrundelse for dette er igen abstraktion: RQL giver en stærkt afkoblet rute til at forbinde forskellige datakilder. Men når det implementeres, ved manuelt at konstruere forespørgsler som strenge, vil det sandsynligvis føle sig forældet for udviklere, der er vant til ORM'er.
Der er andre hindringer for at bruge CubicWeb. For det første kan opsætning være besværligt. Da CubicWeb har mange afhængigheder, er det bedst at bruge det pip-installation at hente dem alle. Du skal muligvis også udføre en vis mængde manuel tilpasning af det lokale miljø. Dette er i skarp kontrast til andre rammer, hvor der kører pip-installation eller alt det, der kræves, er at slippe rammekoden i en undermappe til et andet projekt.
Et andet potentielt problem er fraværet af en native skabelonmotor; generering af HTML overlades til udvikleren. Du kan overvinde dette ved at bruge et tredjeparts skabelonsystem som Jinja2 eller vælge en terning, der giver værktøjer til web-brugergrænseflader, såsom den til Boostrap HTML-rammen.
Et langvarigt problem med CubicWeb - manglen på Python 3-support - er løst. Fra juni 2016 og version 3.23 landede Python 3-support i CubicWeb, bortset fra moduler som Twisted, der ikke selv er fuldt portede.
Ligesom Web2py henviser CubicWeb til sin lange dokumentation som "bogen". Det tager tid at forklare CubicWebs usædvanlige tilgang, demonstrerer, hvordan man bygger nogle basale applikationer, inkluderer API-referencer og går generelt ud af sin måde at være specifik.
Django
I årtiet og forandringen, siden Django første gang dukkede op, er det blevet en af Pythons mest udbredte rammer til oprettelse af webapplikationer. Django leveres med stort set ethvert batteri, du muligvis har brug for, så det læner sig mere mod at opbygge store applikationer end små.
Relateret video: Oprettelse af et simpelt websted med Django
Efter mange år med at sidde ved version 1.x lavede Django for nylig en version bump til venstre for decimaltegnet. Den største ændring i Django 2.0 er, at rammen nu kun fungerer med Python 3.4 og nyere. Ideelt set skal du bruge Python 3.x alligevel, så den eneste grund til at bruge 1.x-grenen af Django er, hvis du sidder fast med en gammel version af Python.
En vigtig del af Djangos appel er implementeringshastighed. Fordi den indeholder så mange stykker, du har brug for til at udvikle den gennemsnitlige webapplikation, kan du komme i bevægelse hurtigt. Routing, URL-parsing, databaseforbindelse (inklusive en ORM), formvalidering, angrebsbeskyttelse og skabeloner er alle indbygget.
Du finder byggesten til de mest almindelige scenarier for webapplikationer. Brugeradministration findes for eksempel på de fleste websteder, så Django tilbyder det som et standardelement. I stedet for at skulle oprette dit eget system til sporing af brugerkonti, sessioner, adgangskoder, logins / logouts, admin tilladelser og så videre, har Django disse funktioner indbygget. De kan bruges som de er eller udvides til at omfatte nye brugssager med et minimum af arbejde.
| CubicWeb | Django | Web2py | Weppy | Zope2 | |
|---|---|---|---|---|---|
| Licens | LGPL | BSD | LGPLv3 | BSD / LGPLv3 [1] | Zope Public License |
| Native HTML-skabelonsystem | Ja | Ja | Ja | Ja | Ja |
| Native ORM / datastyring | Ja | Ja | Ja | Ja | Ja |
| Udvidelsesbibliotek | Ja | Ja | Ja | Ja | Ja |
| Formularvalidering | Ja | Ja | Ja | Ja | Ja [2] |
| Beskyttelse mod forfalskning på tværs af steder | Ja | Ja | Ja | Ja | Ja |
| Brugeradministration / rollebaseret adgang | Ja | Ja | Ja | Ja | Ja |
| Python 3-understøttelse | Ja | Ja | Ingen | Ja | Ingen |
| Skemaoverførsler til datamodeller | Ja | Ja | Ja | Ja | Ingen |
| Svar caching | Ingen | Ja | Ja | Ja | Ja |
| Internationaliseringsstøtte | Ja | Ja | Ja | Ja | Ja |
| Native WebSockets understøtter | Ingen | Nej [3] | Ja | Ingen | Ingen |
| Interaktivt udviklingsmiljø | Ja | Ingen | Ja | Ingen | Ja |
Django har fornuftige og sikre standardindstillinger, der hjælper med at beskytte din webapplikation mod angreb. Når du placerer en variabel i en sideskabelon, såsom en streng med HTML eller JavaScript, gengives indholdet ikke bogstaveligt, medmindre du eksplicit angiver forekomsten af variablen som sikker. Dette reducerer i sig selv mange almindelige scripting-problemer på tværs af websteder. Hvis du vil udføre formularvalidering, kan du bruge alt fra simpel CSRF-beskyttelse til fuldblæst felt-for-felt-valideringsmekanismer, der returnerer detaljeret fejlfeedback.
En funktion, der er så rig og bred som Django, ville ikke være meget god uden robust dokumentation, der passer til den. Djangos dokumentationsside borer ind i alle aspekter af rammen fra flere vinkler. Arbejde med Python 3 eller andre varianter af sproget, gøre sikkerhed rigtigt, implementere almindelige webapplikationskomponenter (som sessioner eller paginering), generere sitemaps - de er alle dækket. API'erne for hvert lag i applikationen - model, visning og skabelon - er også beskrevet detaljeret.
Med stor kraft kommer der imidlertid stor kompleksitet. Django-applikationer har ry for at være top-tunge med mange bevægelige dele. Selv en simpel Django-app med kun et par ruter kræver en hel del konfiguration for at komme i gang. Hvis dit job ikke er andet end at oprette et par enkle REST-slutpunkter, er Django næsten helt sikkert overkill.
Django har også sine særheder. F.eks. Kan sideskabeloner ikke bruge callables. Eksempel: Du kan bestå {{user.name}} som en komponent i en skabelon, men ikke {{user.get_name ()}}. Det er en af måderne, som Django sikrer, at skabeloner ikke utilsigtet gør ubehagelige ting, men disse begrænsninger kan ødelægge, hvis du ikke er forberedt på dem. Mens der er løsninger, har de en tendens til at tage en vejafgift på ydeevnen.
Djangos kerne er synkron. En måde at tilføje asynkroniseringsadfærd på er dog gennem Django Channels-projektet. Dette projekt, en officiel Django-tilføjelse, tilføjer asynkroniseringshåndtering af forbindelser og stikkontakter til Django, mens Djangos programmeringsidiomer bevares.
Web2py
I Ruby-verdenen er Ruby on Rails de facto-webrammen. DePaul University datalogiprofessor Massimo Di Pierro blev inspireret af Rails til at skabe en webramme i Python, der på samme måde var let at konfigurere og arbejde med. Resultatet er Web2py.
Web2pys største attraktion er dets indbyggede udviklingsmiljø. Når du opretter en forekomst af Web2py, får du en webgrænseflade, i det væsentlige en online Python-applikationseditor, hvor du kan konfigurere appens komponenter. Dette betyder typisk at oprette modeller, visninger og controllere, hver beskrevet via Python-moduler eller HTML-skabeloner. Et par eksempler på apps leveres med Web2py ud af kassen. Du kan tage dem fra hinanden for at se, hvordan de fungerer, eller udnytte dem som startskabeloner til at oprette dine egne apps.
Udviklere implementerer typisk Web2py ved blot at downloade kildekoden og bruge den. Men for mindre tekniske brugere på Windows eller MacOS tilbyder Web2pys skabere versioner, der i det væsentlige er enkeltstående servere. Download, udpak og kør en af disse versioner, og du har en lokal webserver med en forudkonfigureret kopi af Web2py indbygget. Dette er en god måde at få et ben på at oprette en Web2py-app, som derefter kan implementeres andre steder efter behov.
Web2pys webgrænseflade blev bygget med Bootstrap 2.16.1, så det er let at se på og let at navigere. In-browser-editoren er ingen erstatning for en fuldstændig IDE, men den er udstyret med nyttige hjælpemidler som linjenummerering og Python-syntaksfremhævning (inklusive automatisk indrykning). Der er også en hurtig webgrænseflade til Python-skallen, så du kan interagere med Web2py fra kommandolinjen, hvis det er nødvendigt - en god indrømmelse til eksperter.
Dataabstraktionssystemet, der bruges i Web2py, fungerer lidt anderledes end Djangos ORM og andre ORM'er inspireret af det (såsom Peewee). Disse systemer bruger Python-klasser til at definere modeller, hvor du i Web2py bruger konstruktorfunktioner som definere_tabel at instantiere modeller. De fleste af disse forskelle skaber sandsynligvis kun for folk, der allerede har erfaring med den ene og begynder at bruge den anden; de er omtrent lige så komplekse for nybegyndere. Du har sandsynligvis ikke problemer med at tilslutte Web2py til en dataudbyder, da den taler til næsten alle større eksisterende databaser.
En virkelig nyttig database-relateret funktion er evnen til at generere et diagram over modellerne, jo bedre at visualisere, hvordan dine modeller forholder sig til hinanden. Du skal dog installere pygraphviz-biblioteket for at aktivere denne funktion.
Web2py leverer mange andre komponenter af professionel kvalitet: internationaliseringsfunktioner, flere cachemetoder, adgangskontrol og autorisation og endda frontend-effekter (for eksempel en datovælger i formularer) via integreret support til jQuery og AJAX. Kroge til ekstern og intern middleware er også inkluderet, selvom du ikke har tilladelse til at bruge middleware til at erstatte centrale Web2py-funktioner.
En væsentlig begrænsning af Web2py er, at den kun er kompatibel med Python 2.x. For det første betyder det, at Web2py ikke kan bruge Python 3s async-syntaks. For to, hvis du stoler på eksterne biblioteker, der er eksklusive for Python 3, så er du ude af lykke. Der arbejdes imidlertid med at gøre Web2py Python 3-kompatibel, og det er meget tæt på færdiggørelse i skrivende stund.
Det er ikke underligt, at Web2pys dokumentation kaldes "bogen". For det første dækker det en svimlende mængde materiale på Web2py, Python og de installationsmiljøer, der bruges til begge. For det andet er det skrevet i en meget tilgængelig, fortællende stil. For det tredje taler den indgående om almindelige applikationsopbygningsscenarier. Der er for eksempel et helt kapitel om at bruge jQuery (bundtet med Web2Py) til at opbygge AJAX-applikationer.
Weppy
Weppy føles som et halvvejs mærke mellem Flaskens minimale enkelhed og Djangos fuldstændighed. Mens du udvikler en Weppy-app, har Flash ligetil, kommer Weppy med mange funktioner, der findes i Django, som datalag og godkendelse. Således er Weppy velegnet til apps, der spænder fra ekstremt enkle til beskedent sofistikerede.
Ved første øjekast ser Weppy-kode meget ud som Flaske- eller flaskekode. Få instruktioner er nødvendige for at få et grundlæggende websted med en rute i gang. Ruter kan beskrives gennem funktionsdekoratorer (på den nemme måde) eller programmatisk, og syntaksen til dette hugger tæt på Flask / Bottle. Skabeloner fungerer omtrent det samme bortset fra mindre variationer i syntaksen.
Weppy står i kontrast til de andre rammer ved at inkludere nogle funktioner, de kun indeholder som plug-ins eller add-ons. For eksempel har hverken Flask eller Bottle et indbygget ORM eller et datastyringssystem. Weppy inkluderer en ORM, omend en baseret på pyDAL-projektet snarere end den langt mere populære SQLAlchemy. Weppy understøtter endda skemamigrationer, som Django understøtter som en del af sin ORM (også Djangos migrationssystem er meget mere automatiseret). Mens Weppy har en udvidelsesmekanisme, er listen over officielt godkendte tilføjelser lille, langt mindre end kataloget med udvidelser til Flask.
Lysere rammer som Weppy bruges ofte til at opbygge RESTful API'er, og Weppy er udstyret med bekvemmelighedsfunktioner til dette formål. Sæt en @service-dekoratør på en rute, og de data, du returnerer, formateres automatisk efter dit valg af JSON eller XML.
Weppy inkluderer andre funktioner, der synes mere i tråd med en større ramme, men de implementeres uden bulk. Eksempler: Datavalideringsmekanismer, formhåndtering, caching af svar og brugervalidering. I alle disse tilfælde tager Weppy en ”lige nok” tilgang. De leverede funktioner er ikke så komplette som du måske finder i en Django-størrelse ramme, men en udvikler behøver ikke at investere meget arbejde i at gøre dem nyttige, og de kan altid udvides efter det faktum.
En anden funktion, der findes i Weppy, der typisk er forbundet med en mere tungvægtsramme, er support til internationalisering. Strenge i skabeloner kan oversættes i henhold til sprogfiler, der følger med applikationen, som er enkle Python-ordbøger. Valget af sprog kan også indstilles ved at analysere browseranmodningen (dvs. HTTP-overskriften Accept-Language) eller ved at binde en oversættelse til en bestemt rute.
Weppys dokumentation har den samme smag som selve rammen. Det er rent, læsbart og skrevet til at blive fortæret af mennesker. Bortset fra det sædvanlige "hej verden" -eksempel, inkluderer det en god gennemgangsvejledning, der giver dig mulighed for at oprette et mikrobloggingssystem som et startprojekt.
Langsigtede planer for Weppy inkluderer understøttelse af asynkronisering og stikkontakter som førsteklasses enheder på lavt niveau. Weppys udviklere planlægger at introducere disse funktioner i version 2.0 og derefter kræve Python 3.7 eller bedre for alle fremtidige versioner af Weppy.
| Scorecard | Native kapacitet (20%) | Ledelse (20%) | Installation (20%) | Dokumentation (20%) | Sikkerhed (10%) | Skalerbarhed (10%) | Samlet score (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 |
| Pyramide 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 |
