Webudvikling er en af de mest populære use cases til programmering. Python er et af de mest populære programmeringssprog i verden. Så hvorfor kan vi ikke bygge webapps i Python?  Det skal være enkelt at lave en brugergrænseflade, men selv du har gode ingeniører på dit team, var det at lære et nyt sprog og nye værktøjer en enorm barriere. Ofte kan det være sværere at lave en brugergrænseflade end det faktiske arbejde, man udfører! Vi byggede Reflex, en open source Python-webramme for at løse netop dette problem.  TLDR  Under hætten kompilerer Reflex-apps til en   frontend-app og en   backend-app. Kun brugergrænsefladen er kompileret til Javascript; al applogik og tilstandsstyring forbliver i Python og køres på serveren. Reflex bruger   til at sende hændelser fra frontend til backend og til at sende tilstandsopdateringer fra backend til frontend. React- FastAPI- WebSockets  Eksisterende Python-løsninger  Der var allerede et par måder at bygge apps i Python på, men ingen af dem passede til vores behov.  På den ene side er der rammer som   og   , der er gode til at bygge produktions-grade web-apps. Men de håndterer kun backend - du skal stadig bruge JavaScript og en frontend framework, samt skrive en masse boilerplate kode for at forbinde frontend og backend. Django Flask  På den anden side kan rene Python-biblioteker som   og   være gode til små projekter, men de er begrænset til en specifik use case og har ikke funktionerne og ydeevnen til at bygge en fuld webapp. Efterhånden som din app vokser i funktioner og kompleksitet, kan du finde på at ramme rammens grænser, hvorefter du enten skal begrænse din idé, så den passer til rammeværket, eller skrotte dit projekt og genopbygge det ved hjælp af en "rigtig webramme". Dash Streamlit  Vi ønsker at bygge bro over dette hul ved at skabe en ramme, der er nem og intuitiv at komme i gang med, samtidig med at den forbliver fleksibel og kraftfuld til at understøtte enhver app.  Refleks mål    : Brug ét sprog til alt. Pure Python    : Byg nemt dine ideer uden at have brug for erfaring med webudvikling. Let at komme i gang    : Webapps skal matche tilpasningsmulighederne og ydeevnen af traditionelle webrammer. Fuld fleksibilitet    : Håndter den fulde stak fra frontend til backend til implementering. Batterier inkluderet  Lad os nu dykke ned i, hvordan vi byggede Reflex for at nå disse mål.  Refleksarkitekturen  Full-stack webapps består af en frontend og en backend. Frontenden er brugergrænsefladen, og serveres som en webside, der kører på brugerens browser. Backend'en håndterer logikken og tilstandsstyringen (såsom databaser og API'er) og køres på en server. I traditionel webudvikling er disse normalt to separate apps, og de er ofte skrevet i forskellige rammer eller sprog. For eksempel kan du kombinere en Flask-backend med en React-frontend. Med denne tilgang skal du vedligeholde to separate apps og ende med at skrive en masse boilerplate-kode for at forbinde frontend og backend.  Vi ønsker at forenkle denne proces i Reflex ved at definere både frontend og backend i en enkelt kodebase, mens vi bruger Python til alt. Udviklere bør kun bekymre sig om deres apps logik og ikke om implementeringsdetaljerne på lavt niveau.   Frontend  Vi ønsker, at Reflex-apps skal se ud og føles som en traditionel web-app for slutbrugeren, mens de stadig er nemme at bygge og vedligeholde for udvikleren. For at gøre dette byggede vi oven på modne og populære webteknologier.  Når du   din app, kompilerer Reflex frontenden ned til en enkeltsidet   -app og serverer den på en port (som standard   ), som du kan få adgang til i din browser. reflex run Next.js 3000  Frontendens opgave er at afspejle appens tilstand og sende hændelser til backend, når brugeren interagerer med brugergrænsefladen. Der køres ingen egentlig logik på frontend.  Komponenter  Reflex frontends er bygget ved hjælp af komponenter, der kan sammensættes for at skabe komplekse brugergrænseflader. I stedet for at bruge et skabelonsprog, der blander HTML og Python, bruger vi bare Python-funktioner til at definere brugergrænsefladen.  Under hætten samles komponenter ned til React-komponenter. Mange af vores kernekomponenter er baseret på   , et populært React-komponentbibliotek. Vi har også mange andre komponenter til graftegning, datatabeller og meget mere. Vi valgte React, fordi det er et populært bibliotek med et enormt økosystem. Vores mål er ikke at genskabe webøkosystemet, men at gøre det tilgængeligt for Python-udviklere. Radix  Dette lader også vores brugere medbringe deres egne komponenter, hvis vi ikke har en komponent, de har brug for. Brugere kan indpakke deres egne React-komponenter og derefter udgive dem, så andre kan bruge dem. Over tid vil vi bygge vores tredjeparts komponentøkosystem ud, så brugerne nemt kan finde og bruge komponenter, som andre har bygget.  Styling  Vi ønskede at sikre os, at Reflex-apps ser godt ud, mens de stadig giver udviklere fuld kontrol over udseendet af deres app.  Vi har et kernetemasystem, der lader dig indstille stylingmuligheder på højt niveau, såsom mørk tilstand og accentfarve i hele din app for at give den et ensartet udseende og følelse.  Ud over dette kan Reflex-komponenter styles ved hjælp af CSS's fulde kraft. Vi udnytter   biblioteket til at tillade "CSS-in-Python"-styling, så du kan overføre enhver CSS-rekvisit som et nøgleordsargument til en komponent. Dette inkluderer responsive rekvisitter ved at sende en liste over værdier. Emotion-  Backend  I Reflex kompilerer kun frontenden til Javascript og kører på brugerens browser, mens al tilstand og logik forbliver i Python og køres på serveren. Når du   , starter vi en FastAPI-server (som standard på port   ), som frontenden opretter forbindelse til via en websocket. reflex run 8000  Al tilstand og logik er defineret inden for en   . Staten består af   og   . Vars er alle værdier i din app, der kan ændre sig over tid. De er defineret som klasseattributter på din   klasse og kan være en hvilken som helst Python-type, der kan serialiseres til JSON. State vars hændelseshandlere State  Hændelseshandlere er metoder i din   klasse, der kaldes, når brugeren interagerer med brugergrænsefladen. De er den eneste måde, hvorpå vi kan ændre vars i Reflex, og kan kaldes som svar på brugerhandlinger, såsom at klikke på en knap eller skrive i en tekstboks. State  Da hændelseshandlere køres på backend, kan du bruge et hvilket som helst Python-bibliotek i dem.   Begivenhedsbehandling  Normalt, når du skriver webapps, skal du skrive en masse boilerplate-kode for at forbinde frontend og backend. Med Reflex behøver du ikke bekymre dig om det – vi klarer kommunikationen mellem frontend og backend for dig. Udviklere skal bare skrive deres hændelseshåndteringslogik, og når vars er opdateret, opdateres brugergrænsefladen automatisk.  Hændelsesudløsere  Brugeren kan interagere med brugergrænsefladen på mange måder, såsom at klikke på en knap, skrive i en tekstboks eller holde musen over et element. I Reflex kalder vi disse   . hændelsestriggere  Begivenhedskø  På frontenden opretholder vi en begivenhedskø med alle afventende begivenheder. En hændelse består af tre store datastykker:    : Hver klient (browserfane) har et unikt token til at identificere det. Dette lader backend vide, hvilken tilstand der skal opdateres. klienttoken    : Hændelseshandleren, der skal køre på staten. hændelseshandler    : Argumenterne, der skal sendes til hændelseshandleren. arguments  Når en hændelse udløses, tilføjes den til køen. Vi har et   for at sikre, at kun én begivenhed behandles ad gangen. Dette sikrer, at tilstanden altid er konsistent, og at der ikke er nogen løbsforhold med to hændelseshandlere, der ændrer tilstanden på samme tid. Der er undtagelser til dette, såsom baggrundsbegivenheder, som giver dig mulighed for at køre begivenheder i baggrunden uden at blokere brugergrænsefladen. processing  Når begivenheden er klar til at blive behandlet, sendes den til backend via en WebSocket-forbindelse.  Statsleder  Når begivenheden er modtaget, behandles den på backend. Reflex bruger en   , som vedligeholder en kortlægning mellem klienttokens og deres tilstand. Som standard er tilstandsadministratoren kun en ordbog i hukommelsen, men den kan udvides til at bruge en database eller cache. I produktionen bruger vi Redis som vores statschef. tilstandsadministrator  Begivenhedshåndtering  Når vi har brugerens tilstand, er næste trin at køre hændelseshandleren med argumenterne.  Statsopdateringer  Hver gang en hændelseshandler vender tilbage (eller giver efter), gemmer vi tilstanden i tilstandsadministratoren og sender   til frontenden for at opdatere brugergrænsefladen. For at opretholde ydeevnen, efterhånden som din tilstand vokser, holder Reflex internt styr på vars, der blev opdateret under hændelseshåndteringen (   ). tilstandsopdateringerne dirty vars  Når hændelseshandleren er færdig med at behandle, finder vi alle de beskidte vars og opretter en tilstandsopdatering til at sende til frontend.  Vi gemmer den nye tilstand i vores state manager, og sender derefter tilstandsopdateringen til frontend. Frontenden opdaterer derefter brugergrænsefladen for at afspejle den nye tilstand.  Konklusion  Jeg håber dette giver et godt overblik over hvordan Reflex virker under hætten. Vi vil have flere indlæg, der kommer ud for at dele, hvordan vi gjorde Reflex skalerbar og effektiv gennem funktioner såsom state sharding og compiler-optimeringer.

This post provides insights into new product. 

pip install reflex

Denne lyd er produceret på historiens originalsprog!

Design af et rent Python Web Framework

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Surfshark: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Surfshark: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps